标签:架构

揭秘:盛大游戏混合云架构_架构盛大揭秘混合

盛大游戏与时代“共舞”

提及游戏,你是否还记得当年省下早餐钱去玩“传奇世界”?是否还记得“泡泡堂”中好友逗趣时的狂轰乱炸?是否还记得“冒险岛”几乎被毁时的集体愤怒?是否还记得“永恒之塔”抵制外挂时的万众一心?这些盛大游戏的“经典款”都承载着80后90后玩家们如初恋般无法撼动的地位及热血记忆。

时至今日,盛大游戏在业务上依旧保持着高速发展的态势,在产品研发及发行上持续取得众多亮眼表现。2017年盛大游戏在“精品研发、全球发行、IP管理和新文化产业生态”四大战略的推动下,推出《龙之谷手游》、《传奇世界手游》、《热血传奇手机版》、《神无月》等收入主力产品,营收、净利润再创新高。3000余名盛大游戏人正在为21亿玩家用户续写传奇经典。

盛大游戏一直通过采用先进云计算技术助推游戏产业的发展,打造出国内一流的私有云平台G云1.0。随着游戏运营环境的急剧变化,游戏在线峰值的高度集中,手游开发更加短平快。为承载纷繁复杂的业务体系及线上游戏运营系统,盛大游戏希望能紧跟行业技术发展态势,迅速创新和升级IT基础架构,为游戏业务发展保驾护航。有鉴于此,盛大游戏需要一个具有如下特点的技术栈:

• 能够通过扩展满足爆炸性的游戏业务需求;

• 能够提高资源复用和重置的速度,更即时的监控、更好的弹性、更高的自动化程度;

• 足够的大数据智慧,对玩家进行多角度分析和挖掘,并对玩家行为进行预测以促进运营;

• 利用云的分布式架构提供更高程度的弹性和可靠性。

据此,盛大游戏决定构建一个弹性云,对原有的G云1.0进行全面升级改版,打造G云2.0,进一步支持开拓新业务领域,实施创新布局。经过多番研究和测试,他们最终选择了将思华科技超融合IT架构引入G云2.0。

盛大游戏董事长王佶说,“选择思华科技,除了其长期为各大运营商提供IT基础设施和应用软件,在业界有着良好的口碑之外,思华科技能够在其超融合云计算和云存储产品的基础上,为我们提供定制化的迭代开发,既满足了我们的业务需求,又促进了他们产品功能的不断升级和完善,实现了双赢,为盛大游戏实现业绩飞跃提供了坚实的IT基础保障,是盛大值得信赖,可以共同成长的长期战略合作伙伴。”

思华助力盛大游戏构建G云2.0,实现全能型行业混合云平台

盛大游戏基于思华科技云计算产品XOS混合云管理平台、ExpressVM超融合云平台、MegaBric分布式存储以及ExpressNET软件定义网络,构建了新一代的G云2.0平台,整体平台建设可以支持上千台物理服务器,能够同时运行虚拟机规模高达上万台。

◇XOS混合云管理平台:采用弹性混合云平台方案,定制化设计贴合盛大游戏G云2.0各项业务需求。建立多层级的租户模型,覆盖SP、工作室、项目组、游戏等,对资源集中管控、运维、调度,租户获取资源池后自服务分配资源,私有云、公有云资源统一分配、管理,由系统屏蔽其差异性,提供一致的业务体验。

G云2.0多层级的租户模型图

◇ExpressVM超融合云平台:构建混合、开放、可拓展的资源池,同时支持多种“开放计算”资源。大部分游戏组件均可运行于虚拟机之中,发生系统故障时能快速恢复。可自定义开服模板,一次性开出所需虚机规模,并保证存储、网络符合业务需求,快速实现资源的弹性扩张和收缩。

G云2.0混合云平台逻辑架构示意图

◇MegaBric分布式存储:为G云2.0平台提供超融合存储资源池以及独立存储资源池,全分布式架构,无单点故障、支持灵活的在线扩容和升级,很好的满足游戏领域对块存储、文件存储、对象存储的不同要求;同时保障大规模集群环境下业务开展、数据迁移、数据备份时的数据安全,真正做到从根源处满足用户对存储的各种需求。

G云2.0分布式存储示意图

◇ExpressNET软件定义网络:同时兼顾游戏场景对于组网和性能尤其是低延时的要求,为盛大G云2.0打造了新一代的网络架构。Underlay网络采用可编程标准硬件设备组成IP Fabric,具有运维简单、等价多路径(ECMP)、水平扩容、和可编程化等特点;Overlay网络采用VxLAN 隧道封装技术以及隧道Offloading等全新的设计理念,采用全分布式控制器,软硬件均可被控制。为租户VPC提供了高可用、高性能和高弹性的虚拟化网络。同时在业界率先实现了同一VPC内虚机和物理机二层直通、VPC与线下IDC网络直通等游戏运营所必须的网络场景。

G云2.0私有云数据中心架构图

重新构建的G云2.0平台四大显著成效:

• 超融合分布式架构:根据游戏特性,分布式部署,能够实现同一类型服务器组水平弹性伸缩,在线热升级;

• 安全防护:通过高防服务器、DDoS和应用防火墙WAF/CC,实现一体化的安全防护;

• 虚实结合:对于资源依赖性较强的关系型数据库,建议采用裸机部署;

• 融合设计:采用超融合的设计理念,充分整合本机计算和存储资源。

领先的云计算和大视频解决方案专家

未来,以用户为中心正成为云世界的新典范,企业将成为云化主角。企业对云服务的需求与日剧增,并呈现多样化、定制化、全面化等特点。“聚焦用户需求,重塑企业变革”,早从2010年起,思华便投入到了云计算产品的研发,逐步搭建起“定制化,更安全”的生态体系,拥有丰富的云计算产品线。

• 2011年,发布全自主研发的分布式存储系统,获得公安三所源代码安全认证。成功部署容量达到百PB,至今稳定运营;

• 2013年,成立云计算事业部发布超融合产品,发布了新一代超融合私有云产品;

• 2015年,推出国内首家基于流协议的虚拟桌面,并成为国内唯一通过可信云认证的私有云桌面解决方案厂商;

• 2017年,帮助盛大游戏搭建G云2.0平台,成功完成中国游戏行业最大规模的混合云部署。

作为领先的云计算产品和大视频解决方案专家,基于长期深耕行业的技术积累及客户经验,从企业的差异化需求出发,思华科技此次为盛大游戏提供的弹性混合云平台解决方案,力求最大程度贴合盛大游戏定制化业务需求。

谈及此番与盛大游戏的合作,思华科技董事长孙逸浪表示,“盛大游戏选择思华科技作为长期战略合作伙伴,既是对我们超融合云计算和云存储产品技术的认可,更是对我们发展方向和服务能力的肯定。未来,我们将依托云计算、人工智能的生态环境,不断提高我们产品的竞争优势,努力服务好盛大游戏这样的领先企业,继续成为云计算技术的践行者和行业的领先者。”

↓↓↓ 点击”” 【加入云技术社区】

相关阅读:

高端私有云项目交流群,欢迎加入!

使用混合云需要考虑的三方面问题

云计算趋势:RightScale 2018 年云状况调查报告「附下载」

RightScale:2017年云计算调查报告|附下载

Forrester:混合云评测报告

Gartner:2018年基础设施和运营的十大技术趋势

云管理平台实践指南

“爆款”游戏吃鸡是如何诞生的?聊聊游戏服务器的架构演进_游戏演进架构聊聊

近日的游戏圈只有一个主题——「吃鸡」。长期被 MOBA 多人在线战术竞技游戏,如《英雄联盟》、《王者荣耀》游戏把持的国内游戏市场在“吃鸡”的刺激下出现了松动。作为技术人让我们一起看看目前游戏服务器的演化进程。

本文阅读预计需要 10 分钟,主要技术点如下:

    游戏服务器特征。

    短连接游戏服务器架构。

    长连接游戏服务器架构。

    分区分服服务器架构。

    MMOARPG 服务器架构。

    房间服务器架构。

    游戏服务器特征

    游戏服务器端,是一个会长期运行的程序,并且它还要服务于多个不定时,不定点的网络请求,所以这类软件的特点是要非常关注稳定性和性能。

    这类程序如果需要多个协作来提高承载能力,则还要关注部署和扩容的便利性;同时,还需要考虑如何实现某种程度的容灾需求。由于多进程协同工作,也带来了开发的复杂度,这也是需要关注的问题。

    功能约束,是架构设计的决定性因素。基于游戏领域的功能特征,服务器端系统有以下几个特殊的需求:

      对于游戏数据和玩家数据的存储。

      对玩家数据进行数据广播和同步。

      把一部分游戏逻辑在服务器上运算,做好验证,防止外挂。

      针对以上的需求特征,在服务器端,我们往往会关注对电脑内存和 CPU 的使用,以求在特定业务代码下,能尽量满足承载量和响应延迟的需求。

      最基本的做法就是“空间换时间”,用各种缓存的方式求得 CPU 和内存空间上的平衡。

      在 CPU 和内存之上,是另外一个约束因素:网卡。网络带宽直接限制了服务器的处理能力,所以游戏服务器架构也必定要考虑这个因素。

      游戏服务器架构要素

      对于游戏服务端架构,最重要的三个部分就是,如何使用 CPU、内存、网卡的设计。

      内存架构:主要决定服务器如何使用内存,以最大化利用服务器端内存来提高承载量,降低服务延迟。

      逻辑架构:设计如何使用进程、线程、协程这些进行 CPU 调度的方案。选择同步、异步等不同的编程模型,以提高服务器的稳定性和承载量。

      可以分区分服,也可以采用世界服的方式,将相同功能模块划分到不同的服务器来处理。

      通信模式:决定使用何种方式通讯。基于游戏类型不同采用不同的通信模式,比如 http、tcp、udp 等。

      服务器演化进程

      卡牌等休闲游戏弱交互游戏

      服务器基于游戏类型不同,所采用的架构也有所不同,我们先讲一下简单的模型,采用 http 通信模式架构的服务器:

      这种服务器架构和我们常用的 Web 服务器架构差不多,也是采用 Nginx 负载集群支持服务器的水平扩展,memcache 做缓存。

      唯一不同的点在于通信层需要对协议再加工和加密,一般每个公司都有自己的一套基于 http 的协议层框架,很少采用开源框架。

      长连接游戏服务器

      长连接游戏和弱联网游戏不同的地方在于,长连接中,玩家是有状态的,服务器可以时时和 client 交互;数据的传送,不像弱联网一般每次都需要重新创建一个连接,消息传送的频率以及速度上都快于弱联网游戏。

      第一代网游服务器(单线程无阻塞)

      最早的游戏服务器是 1978 年,英国著名的财经学校 University of Essex 的学生 Roy Trubshaw 编写了世界上第一个 MUD 程序,叫做《MUD1》。

      《MUD1》程序的源代码在 ARPANET 共享之后,在全世界广泛流行起来。不断完善 MUD1 的基础上产生了开源的 MudOS(1991),成为众多网游的鼻祖。

      MUD1 是一款纯文字的世界,没有任何图片,但是不同计算机前的玩家可以在游戏里共同冒险、交流。

      与以往具有网络联机功能的游戏相比,MUD1 是第一款真正意义上的实时多人交互的网络游戏,它最大的特色是能够保证整个虚拟世界和玩家角色的持续发展。

      无论是玩家退出后重新登录还是服务器重启,游戏中的场景、宝箱、怪物和谜题仍保持不变,玩家的角色也依然是上次的状态。

      MUDOS 使用单线程无阻塞套接字来服务所有玩家,所有玩家的请求都发到同一个线程去处理,主线程每隔 1 秒钟更新一次所有对象(网络收发,对象状态,刷新地图,刷新 NPC)。

      用户使用 Telnet 之类的客户端用 TCP 协议连接到 MUDOS 上,使用纯文字进行游戏,每条指令用回车进行分割。

      这样的系统在当时每台服务器承载过 4000 人同时游戏。从1991 年的 MUDOS 发布后,全球各地都在为它改进、扩充、推出新版本。

      MUDOS 中游戏内容通过 LPC 脚本进行定制,逻辑处理采用单线程 tick 轮询,这也是第一款服务端架构模型,后来被应用到不同游戏上。

      后续很多游戏都是跟《UO》一样,直接在 MUDOS 上进行二次开发,直到如今,一些回合制游戏,以及对运算量要求小的游戏,依然采用这种服务器架构。

      第一代服务器架构图:

      线程模型:

      第二代网游服务器(分区分服)

      2000 年左右,随着图形界面的出现,游戏更多的采用图形界面与用户交互。此时随着在线人数的增加和游戏数据的增加,服务器变得不堪重负。于是,服务器就有了分服模型。

      分服模型结构如下:

      分服模型是游戏服务器中最典型,也是历史最悠久的模型。在早期服务器的承载量达到上限的时候,游戏开发者就通过架设更多的服务器来解决。

      这样提供了很多个游戏的“平行世界”,让游戏中的人与人之间的比较,产生了更多的空间。

      其特征是游戏服务器是一个个单独的世界,每个服务器的帐号是独立的,每台服务器用户的状态都是不一样的,一个服就是一个世界,大家各不牵扯。

      后来游戏玩家呼吁要跨服打架,于是出现了跨服战,再加上随着游戏的运行,单个服务器的游戏活跃玩家越来越少。

      所以后期就有了服务器的合并以及迁移,慢慢随着服务器的开放、合并形成了一套成熟的运营手段。

      目前多数游戏还采用分服的结构来架设服务器,比如多数页游。

      线程调度

      分服虽然可以解决服务器扩展的瓶颈,但单台服务器在以前单线程的方式来运行,没办法充分利用服务器资源。

      于是又演变出了以下 2 种线程模型:

        异步-多线程,基于每个场景(或者房间),分配一个线程。每个场景的玩家同属于一个线程。游戏的场景是固定的,不会很多,如此保证线程的数量不会不断增大。

        每个场景线程,同样采用 tick 轮询的方式,来定时更新该场景内的(对象状态,刷新地图,刷新 NPC)数据状态。玩家如果跨场景的话,就采用投递和通知的方式,告知两个场景线程,以此更新两个场景的玩家数据。

        多进程,由于单进程架构下,总会存在承载量的极限,越是复杂的游戏,其单进程承载量就越低,因此一定要突破进程的限制,才能支撑更复杂的游戏。多进程系统的其他一些好处:能够利用上多核 CPU 能力、更容易进行容灾处理。

        多进程系统比较经典的模型是“三层架构”,比如基于之前的场景线程再做改进,把网络部分和数据库部分分离为单独的进程来处理,逻辑进程专心处理逻辑任务,不合 IO 打交道,网络 IO 和磁盘 IO 分别交由网路进程和 DB 进程处理。

        第三代网游服务器

        之前的网游服务器都是分区分服,玩家都被划分在不同的服务器上,每台服务器运行的逻辑相同,玩家不能在不同服务器之间交互。

        想要更多的玩家在同一世界,保持玩家的活跃度,于是就有了世界服模型了。

        世界服类型也有以下 3 种演化:

        一类型(三层架构)

        网关部分分离成单端的 gate 服务器,DB 部分分离为 DB 服务器,把网络功能单独提取出来,让用户统一去连接一个网关服务器,再用网关服务器转发数据到后端游戏服务器。

        而游戏服务器之间的数据交换也统一连接到网关进行交换。所有有 DB 交互的,都连接到 DB 服务器来代理处理。

        二类型(cluster)

        有了一类型的经验,后续肯定是拆分的越细,性能越好,就类似现在的微服务,每个相同的模块分布到一台服务器处理,多组服务器集群共同组成一个游戏服务端。

        一般地,我们可以将一个组内的服务器简单地分成两类:场景相关的(如:行走、战斗等)以及场景不相关的(如:公会聊天、不受区域限制的贸易等)。

        经常可以见到的一种方案是:gate 服务器、场景服务器、非场景服务器、聊天管理器、AI 服务器以及数据库代理服务器。如下模型所示:

        以上图为例,我们简单的讲下服务器的三种类型功能:

          场景服务器:它负责完成主要的游戏逻辑,这些逻辑包括:角色在游戏场景中的进入与退出、角色的行走与跑动、角色战斗(包括打怪)、任务的认领等。

          场景服务器设计的好坏是整个游戏世界服务器性能差异的主要体现,它的设计难度不仅仅在于通信模型方面,更主要的是整个服务器的体系架构和同步机制的设计。

          非场景服务器:它主要负责完成与游戏场景不相关的游戏逻辑,这些逻辑不依靠游戏的地图系统也能正常进行。

          比如公会聊天或世界聊天,之所以把它从场景服务器中独立出来,是为了节省场景服务器的 CPU 和带宽资源,让场景服务器能够尽可能快地处理那些对游戏流畅性影响较大的游戏逻辑。

          网关服务器:在类型一种的架构中,玩家在多个地图跳转或者场景切换的时候采用跳转的模式,以此跳转不同的服务器。

          还有一种方式是把这些服务器的节点都通过网关服务器管理,玩家和网关服务器交互,每个场景或者服务器切换的时候,也由网关服务器统一来交换数据,如此玩家操作会比较流畅。

          通过这种类型服务器架构,因为压力分散了,性能会有明显提升,负载也更大了,包括目前一些大型的 MMORPG 游戏就是采用此架构。

          不过每增加一级服务器,状态机复杂度可能会翻倍,导致研发和找 Bug 的成本上升,这个对开发组挑战比较大,没有经验,很容易出错。

          三类型(无缝地图)

          魔兽世界的中无缝地图,想必大家印象深刻,整个世界的移动没有像以往的游戏一样,在切换场景的时候需要 loading 等待,而是直接行走过去,体验流畅。

          现在采用无缝地图的游戏大地图多数采用的是 9 宫格的样式来处理,由于地图没有魔兽世界那么大,所以采用单台服务器多进程处理即可。

          不过类似魔兽世界这种大世界地图,必须考虑 2 个问题:

            多个地图节点如何无缝拼接,特别是当地图节点比较多的时候,如何保证无缝拼接。

            如何支持动态分布,有些区域人多,有些区域人少,保证服务器资源利用的最大化。

            为了解决这个问题,比较以往按照地图来切割游戏而言,无缝世界并不存在一块地图上面的人有且只由一台服务器处理了。

            此时需要一组服务器来处理,每台 Node 服务器用来管理一块地图区域,由 NodeMaster(NM)来为他们提供总体管理,更高层次的 World 则提供大陆级别的管理服务。

            一个 Node 所负责的区域,地理上没必要连接在一起,可以统一交给一个 Node 去管理,而这些区块在地理上并没有联系在一起的必要性。

            一个 Node 到底管理哪些区块,可以根据游戏实时运行的负载情况,定时维护的时候进行更改 NodeMaster 上面的配置。

            对象的无缝迁移

            玩家 A、B、C 分别代表 3 种不同的状态,以及不同的迁移方式。

            我们分别来看:

              玩家 A:玩家 A 在 Node1 地图服务器上,由 Node1 控制,如果迁移到 node2 上,需要将其数据复制到 Node2 上,然后从 Node1 移除。

              玩家 B:玩家 B 在 Node1 和 Node2 中间,此时由 Node1 和 Node2 维护,若是从 Node1 行走到 Node2 的过程中,会向 1 请求,同时向 2 请求,待全部移动过去了再移除。

              玩家 C:玩家 C 在 Node2 地图服务器上,由 Node2 控制,如果迁移到 Node1 上,需要将其数据复制到 Node1 上,然后从 Node2 移除。

              具体魔兽世界服务器的分析,篇幅过多,我们以后再聊。

              房间服务器(游戏大厅)

              房间类玩法和 MMORPG 有很大的不同,在于其在线广播单元的不确定性和广播数量很小。而且需要匹配一台房间服务器让少数人进入一个服务器。

              这一类游戏最重要的是其“游戏大厅”的承载量,每个“游戏房间”受逻辑所限,需要维持和广播的玩家数据是有限的,但是“游戏大厅”需要维持相当高的在线用户数。

              所以一般来说,这种游戏还是需要做“分服”的。典型的游戏就是《英雄联盟》这一类游戏了。

              而“游戏大厅”里面最有挑战性的任务,就是“自动匹配”玩家进入一个“游戏房间”,这需要对所有在线玩家做搜索和过滤。

              玩家先登录“大厅服务器”,然后选择组队游戏的功能,服务器会通知参与的所有游戏客户端,新开一条连接到房间服务器上,这样所有参与的用户就能在房间服务器里进行游戏交互了。

              以上就是目前游戏服务器的演化进程,由于所涉及的内容太多,关于服务器的相关网络 IO 以及内存模型都没有介绍,以后有机会再具体讲讲这一部分。

              作者:wier

              编辑:陶家龙、孙淑娟

              来源:转载自大码猴(ID:cool_wier)公众号

              wier,乐元素 leader 软件工程师,从 2010 年起从事游戏开发,经历过页游和手游两个游戏发展期,期间曾带领团队开发过山寨机上第一款偷菜游戏,如今专注于二次元游戏领域及服务器技术研究,运维了一个游戏公众号(大码侯ID:cool_wier),期待用自己的一点努力和贡献,推进游戏社区的前进。

              精彩文章推荐:

              你的解耦战术,决定了架构高度!

              嫁给程序员老公,我“后悔”了!

              《王者荣耀》打团不掉帧、不卡顿的架构方式和实现原理