精华内容
下载资源
问答
  • 架构构架

    万次阅读 2018-03-30 00:37:35
    打的是我的语文学的不好,容易把这俩个词语记得不大清楚,但是唯一可以确认的是,我的理解是没有什么问题的,因为没有人会听我的话,我说的所有大概只是自己会听的,所以说我不管你说它是构架还是架构,我都只会理解...

    架构和构架?

    一直分不清楚社么是架构还是构架,打的是我的语文学的不好,容易把这俩个词语记得不大清楚,但是唯一可以确认的是,我的理解是没有什么问题的,因为没有人会听我的话,我说的所有大概只是自己会听的,所以说我不管你说它是构架还是架构,我都只会理解成那一种,如何搭建一种框架,可以让我的软件功能实现,也不是软件功能,那就是一个小程序。或者叫做小系统,就是这个样子。

    在思考构架的时候,你必须要了解的一个的问题。把变量设置为全局变量还是局部变量,是一个值得的思考的问题。通常我不会使用太多的花里胡哨的东西架构系统,而只会使用全局变量来监测,是否要执行下一步,嗯,就像是一个锁的存在吧,这是最基本的,最烂的架构吧。嗯,

    但我最喜欢的就是吹牛逼了,你用催眠的方式来解释一下价格的事,关于全球局势的问题,嗯,当然要选择的就是中国,不,不是中国,我们伟大的祖国是战无不胜的,要说的就是美国和俄罗斯的掐架吧,那么美国和俄罗斯的掐架,那么朝鲜可能会充当一个全局变量的问题,那么我们就可以把朝鲜当作一个监测全局的所,如果朝鲜对吧,还是金将军执政的话,这样的话那么就打不起来,如果一旦金将军暴毙,说不定他们就打起来了,这样我们就可以理解, 全局变量在架构中的作用,作为一个监测的key来确定是否执行下一步。

    我们把这个锁放到哪里呢?当然就是放到发动战争之前,把这个锁放上去,阴谋美帝时刻要发动战争,而主线程就是发动战争,而发动战争的前提是这个key是标志是否为true。这样一个基本的架构就完成了。
     
    然后再说一下数据传输的架构。我喜欢用java语言说这个,利用java语言与JDBC链接MySQL数据库。嗯,先说到前台吧,算是前台吧,就是用户界面那一块接收到数据,将数据验证之后存入数据库,然后再打开另一个程序,我们就可以通过访问数据库来获取数据,在把数据传输到用户面前,在做增删改查,嗯,就相当于从程序到文本,在从文本到程序。这也是一种简单的数据在程序之间的架构,
     

    到底什么算是架构呢?在没有计算机软件工程之前,大概是没有这样的词语的,后来就有了,那么,我就无理取闹的说,

    我有对它的定义权:

    我们为了实现某个系统的功能,把函数,把程序中的函数,函数体或者面向对象中,对于类的设计与数据之间的交换其中理解为一种搭建房屋,一种房屋架构,就是如何把这些数据,全局变量,局部变量管道进行良好的连接


    展开全文
  • 至少我在看完这个定义之后还是依然不是很理解它。在阅读过王概凯的架构漫谈之后,我的认知就比较清晰了。他对于架构举了一个例子,就是把一个整体切分成不同的部分,然后让不同的角色来完成这些分工,并通过建立不.....

      在我们这个软件行业,基本可以说得上是每个人都有着自己不同的理解与看法。那我们就要清楚架构这个东西到底是怎么来的。

      架构,网上的专业的定义也是存在的,但是这对于我们来说也并不是很清晰。至少我在看完这个定义之后还是依然不是很理解它。在阅读过王概凯的架构漫谈之后,我的认知就比较清晰了。他对于架构举了一个例子,就是把一个整体切分成不同的部分,然后让不同的角色来完成这些分工,并通过建立不同部分相互沟通的机制,使得这些部分能够有机的结合为一个整体,并完成这个整体所需要的所有活动,这就是架构。

      软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。那么我们接下来就要了解软件架构的目标了。它要达到的目标也不在少数:1.可靠性。软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。2.安全性。软件系统所承担的交易的商业价值极高,系统的安全性非常重要。3.可伸缩性。软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。只有这样,才能适应用户的市场扩展得可能性。4.可定制化。同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。5.可扩展性。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展。6.可维护性。软件系统的维护包括两方面,一是排除现有的错误,二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。7.客户体验。软件系统必须易于使用。8.市场时机。软件用户要面临同业竞争,软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

      在理解了架构的基础上,我们就可以开始了解软件架构师了。软件架构师的工作职责是在一个软件项目开发过程中,将客户的需求转换为规范的开发计划及文本,并制定这个项目的总体架构,指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的。这个职位的要求是很高的,作为一个软件架构师,不仅编程能力要有,突出的沟通能力以及领导素质也是必不可少的。

      软件架构师在项目的开发过程中,要注意和分析人员交流,来确保能够理解到客户的实际需求。否则就算项目做的再好,对不上客户的需求也是不行的。然后,架构师在脑海中大概确定程序的大体部分,将这个复杂的系统分解成一个个小的系统。然后分配任务。软件分解是非常重要的。对复杂的系统,特别是前人没有做过的新系统,通常难以一下子设计出合适的架构。在架构设计的初期,通常都要经历一个不断探索的阶段。软件构架师通常根据业务主题,将系统分解为多个子系统,每个子系统聚焦于一个独立的业务主题,子系统间具有清晰的边界。如果没有丰富的经验是做不好这项工作的。此外,软件架构师还需做很多的文档工作,这些文档并不是交付给开发团队的说明性文档。而是某种向上级证明某某方案可行,某某架构有效的证明性文档。这个职位像是一个千面人:需要与上下前后左右的不同角色打交道;多面手:需要了解甚至掌握诸多不同的知识和技能。

    转载于:https://www.cnblogs.com/qq1499632156/p/8530481.html

    展开全文
  • 这篇blog题目涉及的范围真大!以至于在这里需要先写一篇前言把范围缩小。选择写这样一个系列的文章,主要是想给工作了两年的自己一个交代,...不知道是一种悲哀、还是一种悲哀、还是一种悲哀....... 庆幸的是梦还在继续

        这篇blog题目涉及的范围真大!以至于在这里需要先写一篇前言把范围缩小。选择写这样一个系列的文章,主要是想给工作了两年的自己一个交代,或者说是一个阶段性的总结。两年时间里,房价依然再涨,工资依然跑不赢CPI,某人依然在仰望星空。期间很多梦碎了,很多还在坚持着,生活过得波澜不惊。而我也从刚毕业是的青涩逐步蜕变为“老油条”。不知道是一种悲哀、还是一种悲哀、还是一种悲哀....... 庆幸的是梦还在继续,一颗倔强的心还在坚持。希望明天的明天被束缚的心能回到梦开始的地方!

     

    ==========================我只是条分割线========================

        作为本系列blog的开篇前言,本文主要明确网络游戏服务器构架的设计目标,并作出一些限定。因为本系列所讨论的服务器端构架只适用于部分网游,并不是一个通用的网游服务器构架。

     

    设计目标:

    1. 支持的游戏类型:大型MMORPG游戏,类似魔兽世界(有大世界,不是开房间式)。
    2. 连接方式:以TCP长连接为主。动作类游戏并不在本文讨论范围内(因为本人并没有参与开发过动作类游戏),如果有时间可以研究一下龙之谷(部分使用UDP传输)、天下贰(全部使用UDP传输),类似的逆向工程网上已经有人做了。
    3. 在线人数:保证最大1w人左右在线还能比较流畅的运行。如果在线人数大于1w对客户端的同学和策划的同学都是很大的挑战。
    4. 服务器可以以多进程的形式布置在不同的物理主机上,也可以布置在同一主机上,考虑效率的同时兼顾可扩展性。
    5. 能在普通配置的服务器上流程运行,物理主机配置:按照DELL 1950、DELL R610上32G内存的标准来部署主机,一般公司是用不起WOW的小霸王的.......
    6. 内存不用过多的考虑,因为现在服务器的内存已经很大了。减少内存使用会放到模块设计、详细设计里。不在构架分析的讨论范围内。
    7. 偏格斗的游戏会对CPU和带宽要求比较高,设计时需要进行讨论。

     

        设计目标就这些多说无益,核心就是设计出能够支持类似魔兽世界的大型MMORPG游戏的网游服务器端。具体的设计以及设计时的取舍、需要解决的问题等,会在后续的文章进行详细的介绍。


        本文并没有涉及什么逆向工程,只是拜读刀剑Online服务器端主程的文章后[1],想结合自己的经验谈一谈。

    PS:由于题目范围太大,本系列的前言做了一些限制。

     

    一、网络游戏服务器

        要想设计好网络游戏服务器的构架,首先需要知道网络游戏服务器在玩家游戏过程中发挥什么作用。就我个人的理解:网游服务器在玩家游戏过程中扮演上帝的角色。玩家在服务器制定的规则下进行游戏,服务器负责同步在线玩家之间的属性、操作、状态等等,最终在多个不同的客户端呈现一个“统一”的游戏世界。

        所谓的服务器构架在本系列blog中,主要是指如何将服务器各部分合理的安排,以实现最初的功能需求。好的结构不是一蹴而就的,是通过需求的推动一步步的完善。而且每个设计者心中的标准不尽相同,所以我认为并没有绝对优秀服务器构架。本系列文章中所谓的优秀构架是指各方面达到一种平衡(包括成本等的非技术因素)。

        下面先介绍刀剑Online的服务器构架(后续还可能有WOW、天龙等):

     

    二、刀剑Online

    image    

    图1 刀剑Online服务器构架

     

        看了像素的技术总监魏华的文章[1],感觉有点意思。文章中所介绍的服务器构架并不复杂,但满足一般MMORPG网游要求应该是绰绰有余了。按照魏华自己的话,这样的服务器构架主要满足能够接受以下几条限制的网络游戏:

    1. 游戏同时在线人数在1w人以下。
    2. 服务器为多进程程序,可部署在一台或者多台机器上。
    3. 服务器内存足够大,一般一个进程1~2G的内存需求还是应该满足的,64位系统能支持更大的内存需求。内存这块主要看游戏的设计需求。
    4. 刀剑属于格斗性质的网游,对CPU和带宽有一定的要求。(这篇文章写于2005年,当时刀剑可能是按照256k、512k或1M ADSL的网速进行设计的。现在已经开始普及10M网,带宽和网速应该可以满足),网络延迟的问题本文后面再做展开。对CPU的要求主要影响可承载人数。
    5. 地图采用独立小场景的管理模式,各个场景之间通过传送点来连接。每个场景服务器程序分管一部分地图。

        服务器包括游戏中和游戏外两大部分,这里主要讨论游戏中的服务器构架,类似客户端自动更新等的游戏外服务器不在本文的讨论范围。

        接下来对刀剑Online的服务器构架的各个部分进行详细的分析,其中包含很多我自己的想法,很多内容都是我猜测的,因此不能“信以为真”。

     

    2.1 连接负载服务器(Connection Load Server,CLS)

        游戏客户端在游戏过程中实际上是和连接负载服务器(简称CLS)进行连接并做数据交互的。如文中[1]所诉,CLS主要的作用是:

    • 把网络连接和真正的游戏逻辑隔离开,降低游戏逻辑服务器处理网络交互的负担,同时提高游戏的安全性。有了CLS,刀剑Online的服务器对于玩家来说就是一个黑盒,如下图:

    image 图2

    • 使场景服务器(Zone Server)更为独立——客户端连接CLS而不是直接连接Zone Server的好处是:用户切换场景服务器时,并不会导致原来的TCP连接断开,从而使设计更为简单和独立。
    • 提高发送广播消息的效率,比如需要全服广播时,游戏逻辑服务器只需要对CLS发送一条广播指令,而向每个用户的广播工作由CLS完成。
    • 完成客户端数据交互的加密解密过程。

    连接服务器的主要工作正如上述魏华谈到的,但有几点并没有做出强调,下面本人结合平时的实际工作给出一些补充(不一定正确):

    根据经验:

        CLS作为与client建立连接、进行数据交互的“Gate”,从程序角度来看CLS的代码应该是最简洁高效的。因为CLS主要负责与客户端交互数据是的加密解密、以及数据搬运。而使用流加密算法RC4对整个数据流进行加密解密是很耗CPU的,因此代码的高效在这个模块是十分的重要。

        为了提高程序的运行效率,CLS程序往往会使用-O3的选项进行编译,这无形中又对代码的编写有更高的要求。CLS一般会有自己的打包机制(控制发送频率),因此常会使用TCP_NODELAY选项禁用Nagle算法。

        CLS常会被分配到不同的物理机器上,因为操作系统在处理TCP包时,需要通过软中断来通知进程或者唤醒system call,在服务器十分繁忙的时候CPU可能处理不过来。解决办法是:使用多核的服务器,然后把TCP的软中断平均分配到多个CPU。(一些操作系统默认只使用0号CPU来处理,Fedora Core release 2默认就是只使用0号CPU,较新的版本我没有做研究)

        CLS在做数据流的解密后,往往需要把数据包构造成内部服务器进程间通讯使用的protocol,这种protocol模块要独立,序列化和反序列化的接口要稳定,这样以后需要更换协议模块也不至于伤筋动骨。可以使用像google的protobuf这样的开源协议,减少开发难度。

        CLS负责建立和client的连接,多会使用多个CLS进程才能支撑1w的在线人数,因此在CLS前端一般会有负载均衡的程序,负责把建立连接的请求均匀的提交到各个CLS。

       有一个需要讨论的问题:作为服务器端的“Gate”,只负责数据转发的CLS是否需要对client发过来的数据进行完全的解密?或者只解密包头,知道转发的目的地即可?(RC4并没有增加流的长度,因此可以只做部分解密)

      CLS只做部分解密:

    好处:将耗费CPU资源的解密功能分摊到别的进程;各进程各服务可以在解密后用不同的方案来构造自己的protocol。

      CLS做完全解密:

    好处:可以提前过滤部分无效的消息,只做部分解密也可以做提前过滤,但是这样太过于依赖协议的设计;在CLS处做完全解密,则往后服务器端的之间的消息传递都是明文,利于抓包查错;由于CLS的功能比较简单,很容易通过加机器来进行扩展,因此计算放在CLS上是比较明智的选择。

     

    总结

        CLS是一个功能相对简单但要求代码简洁高效的程序,在设计实现的时应该注重效率及代码编写规范。经过对比在CLS程序对数据流进行完全解密是利大于弊的,推荐使用这种方案。

        上一篇《网络游戏服务器构架设计(二)》介绍了刀剑Online的连接负载服务器CLS,博友提出质疑“说得不够详细,比如你怎么,场景服务器怎么才算一个场景服务器,场景服务器切换怎么处理不断线后连接另一个场景的,还有很多细节问题没有说到”,本篇就来介绍游戏服务器最为核心的部分:游戏逻辑服务器,同时也回答了这位博友的问题。

    PS:本篇的文章结构主要分两个部分,前半部分(2.2节)介绍刀剑Online如何实现游戏逻辑服务器,后半部分(2.3节)为本人结合实际工作对这套服务器构架做出的一些展开解释及补充,主要对设计思想进行分析。精彩在后面哦!

     

    -------------------------------------------我只是条分割线--------------------------------------------

     

    先来回顾一下刀剑Online的总体构架图:

     

     

     

    2.2 游戏逻辑服务器

        顾名思义,就是和游戏具体逻辑相关的服务器(这应是一个统称)。这块是网游服务器端的核心部分,不同的游戏差别会很大。在刀剑中,游戏逻辑服务器分为两部分:总控服务器和场景服务器。

     

     

    2.2.1 总控服务器(Master Server,MS)

        关于总控服务器的作用,刀剑Online的主程是这么解释的:

        总控服务器(以下简称MS)的作用之一是负责玩家在具体游戏内容之外的操作(即.玩家进入场景服务器之前地操作)。如:登录、注销、各种角色操作(创建、删除、选择)等等。

        MS和所有地场景服务器都保持连接,这样它就成为各个场景服务器间的枢纽,当需要一些跨场景服务器的操作或者需要访问别的场景服务器数据的时候,指令都先发给MS,然后MS根据需要再转发给相应地场景服务器或者直接发给相应的用户,并进行后续地协调工作。

        比如:在场景服务器1上的用户A希望向游戏中的用户B发出一条添加好友的请求,则场景服务器1向MS发送添加好友指令并附带了用户B的名字,MS查找发现有B这样的用户,则直接把指令发给CLS,然后由CLS转发给B用户;如果没有发现B用户则直接通知A未发现B。

        又比如:在场景服务器1上的用户A点中了传送点,将要传到场景X,场景服务器1发现X场景并不在自己的管辖范围内,于是发送转移指令给MS,MS查找发现场景X在场景服务器2上,于是先发送用户A的离开指令给场景服务器1,让用户退回到MS上,然后再发送用户A的进入指令给场景服务器2,并说明用户将要进入的场景为X,这样一次跨服务器的场景转移就完成了。[1]

     

    2.2.2 场景服务器(Zone Server,ZS)

        关于场景服务器的作用,刀剑Online的主程是这么解释的:

        场景服务器(以下简称ZS)就是具体负责游戏场景的服务器。玩家选择人物开始游戏之后就进入了这种服务器(即开始游戏之后CLS把所有玩家的操作指令都转给ZS)。

        玩家的各种操作的逻辑都是由ZS完成的,同时,ZS也要负责各个场景以及场景中的NPC和场景中各个物品的逻辑运行。

        每款游戏的真正游戏性的核心就是这些ZS。它的具体细节我就不过多的讲述了,各个游戏的具体内容应该都不相同。不过有几个原则是共同的:

        一、是要高效。如果ZS对游戏逻辑的处理效率低,会直接影响玩家同时在线的数量,并导致游戏中的玩家感觉很“卡”,这是除了网络延时之外第二个会造成游戏 “卡”的地方。提高效率的方法除了对代码进行优化外,就是要使用高效的脚本系统,直接把脚本转化为程序代码编译到程序中去也不失为一个办法。

        二、是要有灾难恢复机制,就是当ZS发生非法操作时(只要不停电)能够恢复出非法操作时各个用户的数据。这个在游戏运营初期服务器尚不稳定的时候非常重要。虽然我们也可以通过加快用户存盘间隔的方式(比如把每10分钟存一次盘改为每1分钟存一次盘),但是这会成倍加重数据库负担,同时也不能避免由于用户刚好在存盘间隔的时候获得了重要的金钱或道具而导致丢失的情况。刀剑采取的方法是在申请用户关键数据对象的时候通过包装的函数从共享内存中申请,这样即便ZS非法操作了,共享内存并不会消失,在重新启动的时候就可以从共享内存中恢复出程序非法时的用户数据。当然恢复的时候也需要对用户数据进行一些校验,以免把已经被破坏的数据存入数据库。[1]

     

     

    2.3 设计思想分析

        游戏逻辑服务器主要负责汇总所有在线的client发来的各种操作、状态等数据包,经过一系列的处理后有选择的广播给需要的client,从而给所有在线的玩家呈现一个“统一”的世界。

        优秀的逻辑服务器架构需要优秀的设计思想,而优秀的设计思想又源于对游戏虚拟世界的适度抽象。抽象可以看作一个工程问题,同时也可以看作一个哲学问题,这正是游戏开发的魅力所在。本系列blog将围绕这种抽象一步步展开,结合不同的项目来诠释网络游戏服务器端的设计思想(希望能做到....)。

        站在服务器端的角度对游戏虚拟世界进行抽象,首先要弄清楚构造虚拟世界需要些什么?让我们来想象一下吧(以下内容参照了《盗梦空间》-“Inception”),先来看一段视频:

        Inception是我非常喜欢的影片,第一次看到这一段的时候,就感觉非常像游戏设计。今天能把它写下来也算没浪费几十块的电影票钱。

        影片中饰演the architect(造梦师)的艾伦·佩姬(女),正在接受莱昂纳多(饰演the extractor-盗梦者)的训练。莱昂纳多说道:“Remember you are the dreamer you built this world。”,“I'm the subject my mind populates it”。值得关注的两个名词:world,subject。这就是我们要讨论的主题。那么构造网络游戏的虚拟世界需要些什么呢?其实莱昂纳多已经替我回答了这个问题:“We create and perceive out world simultaneously. You create the world of the dream, We bring the subject into that dream, and they fill it with their subconscious.”。world就相当于游戏里的场景,而subject就是一个个在线的玩家(player)。

        游戏世界(world,这里的world泛指游戏世界及地图,见2.3.2)及游戏对象(object,包括player)是构造网络游戏服务器端时,需要关注的两个重点。如何处理好world和object的关系和地位直接影响到服务器端的构架。

     

    2.3.1 游戏对象(object)

        先来看游戏里一般会有那些object,以Mangos为例:

    class_diagram

    图2 mangos游戏对象的class diagram[2]

         对于上面的类层次结构图这里不做展开(留到本系列后面的文章中展开),这里引用mangos的游戏对象是想给读者一个直观的印象,游戏中的object在服务器端是个什么摸样。类的层次是对游戏世界中的对象抽象后得到的结果,抽象需要“适度”:如果类的层次过深,维护起来困难,而且后期往往会导致基类过于臃肿、不堪重负;如果类的层次过浅,一些object的共性不能体现,很多代码会重复出现在各个子类里,复用性差。

     

    2.3.2 游戏世界(world)

        游戏世界在本文是泛指游戏对象所在的场景,以及附加在场景之上的地图管理和对象管理,这里统称游戏世界管理。

        如何进行游戏世界的管理是一个复杂的工程问题,网络游戏常常会把整个游戏世界分为若干张地图,每张地图又会分为若干个区域进行管理。这若干张地图能无缝的过渡就称为无缝大地图模式(类似WOW),如果像刀剑Online那样只能通过传送服务在两张不同地图之间穿梭的,称为有缝地图。而相对来说服务器端会比客户端简单一些,例:如果在客户端看到的场景是下面这个样子:

    yy4

    服务器端根据划分区域的不同可能看到的地图是这个样子:

    yy5

        这里服务器端用到了tile-based的方式来管理地图,这种tile的方式在2d游戏中十分的常见(打格子),而很多3d网游的服务器端为了减少运算量也采用这种tile模式划分区域进行管理。如果对地图管理有兴趣请阅读云风的blog《用四叉树管理散布在平面上的对象》、《碰撞检测》,本文先不做详细的展开。

     

     

    2.3.3 游戏对象和游戏世界的关系

        如何处理游戏对象和游戏世界的关系和地位,是影响服务器端架构的最直接因素。为了体会到这点,下面将以刀剑Online为例,分析玩家对象(player,游戏对象中最为重要的部分)和游戏世界的关系对整个服务器构架设计的影响。

     

    1. 玩家对象player的构建

        刀剑Online把游戏逻辑服务器分为总控服务器(Master Server,MS)和场景服务器(Zone Server,ZS,本文提到的游戏世界多指ZS),那么在client成功登陆server后,服务器端应该在哪构建player对象呢?在MS上?还是在ZS上?这是个工程问题,同时也是个哲学问题.......

    1. 如果把player(以及其他的游戏对象)放在Master Server上:也就是说所有登陆的玩家的数据都会在MS的内存中有一份映像,MS将保存着player最新的数据。这么做的好处是player的数据统一,从而使同服玩家的一些交互变得十分方便,比如同服玩家组队、交友等不需要知道玩家在那个ZS里。切换场景服务器时也不需要把player数据从一个ZS拷贝到另一个ZS,只需要把player身上记的ZS信息修改一下;player在MS上构建的缺点也是显而易见的,所有中心节点式的系统都会遇到单点不可靠的问题,player的信息都保存在MS上,假如有1w人在线,内存占用就是一个很大的问题(毕竟单个进程的内存使用还是有限制的,实际开发中曾经遇到占用十几G内存的进程......相当可怕),而如果一个player借住外挂发送一些非法消息给MS,错误处理不当时很有可能会core进程,这样一来整个服务器的玩家都会掉线。还有一些和地图相关的逻辑会很难操作,比如player与场景中怪物进行PK时,由于player的数据保存在MS,因此ZS需要做一个Attach操作告知MS某个player和某个monster进行战斗,MS进行完伤害计算后发AttachResult给ZS,最后由ZS再广播给相关的客户端,如图:image 如图中标注的(1)~(4)的步骤,展示了这个过程,编程操作起来还是挺麻烦的。
    2. 如果把player放在Zone Server上:这是一种比较常见的方式,player和其他游戏对象在场景服务器中构造,隶属于Zone Server。由ZS来掌管player从编程角度讲好处多多:可以直接获得player的信息,对于场景内交互十分便利,场景内的操作不需要多余的数据传输。而在需要跨场景操作时只需用MS中转一下即可;但是这种方式缺点同样是很致命的,player在Zone Server上构造就失去数据放在中心节点的简洁,player的信息常常需要在ZS、MS和DB上进行同步,这种“三体同步”的痛苦只有做过的人才能体会。比如:几个独立的服务器之上需要增加一个跨服服务器,这几个普通服务器的玩家可以进入这个跨服服务器进行pk。那么就需要将player先从普通服务器ZS退到MS,由普通服务器的MS把player的数据发给跨服MS,最后再由跨服MS发送到跨服的ZS。如果还涉及DB则会更加的复杂。ZS、MS、DB相互独立,如果没有强制规定,这种同步往往是没有方向的:player的最新的数据一般在ZS上,但是有些交互不能在ZS上完成,那么可以有两种选择:(1)ZS把player数据发给MS,由MS进行操作,操作过程中ZS不能修改player的相关数据。(2)把player的最新数据存盘,然后由MS读盘取player的数据然后进行操作,操作过程中ZS还不能改变player的相关数据。不管哪种方法开发的逻辑多了以后都不好维护,从此维护人员都变成怨妇.......

        刀剑Online应该采用的是第2中方式,把player放在Zone Server上。

     

    2. 玩家对象player和world的关系

        如何处理玩家对象player和world的关系集中体现了服务器端的哲学,值得细细品味。处理两者的关系在本人看来有两种主要的模式:一种是以player的中心的“自我”模式;另一种是以游戏世界为中心的“上帝之手”模式。这两种模式的哲学主要体现在加锁模式上,接下来进行详细介绍:

    (一)player的“自我”模式

        “自我”模式顾名思义,就是player以自我为中心,什么事都要亲历亲为。以player使用物品为例:

    image

        如上图是一个完整的player使用物品的流程。“自我”模式体现在上图的(1)位置,在(1)中首先取到服务器中对应的player,加锁后用player调用自己的处理函数进行处理。由于(1)相当于处理客户端发来的请求的入口处,因此在这里进行加锁和解锁操作是十分合适的,此后的(2)~(5)player在调用自己的处理函数时,编程人员完全不需要考虑加锁的问题。

        所谓的“自我”模式,其实就是指在服务器端对player的操作其实都是player自己去完成的,“”自己去把事情做完。处理逻辑时“”(自己的player实例)不会主动去锁住对方的player实例,因此一个player不能修改另一个player的数据,world也不能修改player的数据。world和player的关系是“独立”的,player身上记着world的信息(相当于“我属于哪个世界”),world里存放着player的实例,但是它们直接不能直接修改对方的数据。这么做是为了避免死锁,使得加锁解锁变得简单而统一(如上图)。

        “自我”模式有加锁解锁的便利,但是一个网络游戏怎么可能player和player、player和world直接没有交互呢?交互就需要获得或修改对方的数据,遇到这样的问题“自我”模式怎么处理呢?请看下图:

    image

        如上图:client A向服务器发送“向玩家B发起攻击”的消息,服务器端client A对应的实例Player A收到消息后,发现需要与player B进行交互,根据“自我”模型的限定,player A不能直接修改player B的血量等信息,这时player A需要做的是将自己的信息打包成一个msg结构然后push_back到消息队列message queue并指定player B作为接收者。在message queue上将这个msg转发给player B前,会先调用lock(playerB)将B锁住,接着把msg传给player B进行处理,在处理完毕后再调用unlock(playerB)。lock和unlock都在统一的地方调用,加锁解锁十分简洁,playerB处理msg消息时不用关心任何加锁问题。在上图的(2)中,player B进行伤害计算后将伤害消息广播给周围的玩家。

        注意:“自我”模式下,伤害计算是在受攻击方进行的。player之间、player和world之间都是通过消息传递进行交互的。

    总结:

    优点:“自我”模式的优点集中体现在加锁上,编程人员在编写具体逻辑时不用担心加锁问题,也不用费尽心思来避免死锁,因为加锁都在消息入口处统一做了,同时不会主动去对别的player实例进行加锁操作。使用这种模式时,最好把移动的相关逻辑独立出来使用不同的锁,以免照成过多的加锁冲突和等待。

    缺点:“自我”模式的缺点也是十分明显的,每个player实例作为不同的“我”独立存在,需要交互时只能通过消息队列来传递信息,极大的增加了交流的成本(内存、CPU占用率都会增加)。一个player往往不能即时的取到别的player的数据,这样一来很多的计算都只能做延后处理,比如伤害计算就只能放在被攻击者的player上,使得很多需要做先验判断的技能实现起来变得复杂,这类技能只能靠释放技能的player,发送请求消息给其他player,然后再由其他player把自己的信息通过msg queue发给释放技能的player。异步处理方式往往会但来更多的烦恼——需要增加很多错误判断、错误处理以及超时处理等等。在线人数高的时候,message queue的容量以及所占用的内存也是需要考虑的问题。

        引用狄更斯的:“It was the best of times, it was the worst of times”。本人依葫芦画瓢:“自我”模式是一种nb的设计,也是一种sb的设计.......

     

    (二)world的“上帝之手”模式

        “上帝之手”模式是以world为中心(类似war3),以地图为单位进行划分,player、NPC、monster等游戏对象都隶属于world。在world的掌控之下,就像有一只上帝之手在拨弄着这些小玩意。以client A向服务器发送“向玩家B发起攻击”消息为例,服务器端的处理流程如下:

    image

        从上图中可以看出“上帝之手”模式的核心是world去完成这项任务:找到playerA和B,把他们都锁住,然后交给技能模块来进行伤害计算,最后把结果广播出去。整个过程就像在玩war3这样的RTS游戏,服务器就像一个神,以斜45度的上帝视角来观察所有的玩家。

        “上帝之手”模式的设计难点在于加锁策略,因为需要对多个对象进行加锁,加解锁的顺序不当容易产生死锁。加锁策略有很多种,这里不做具体的展开。只介绍一种最常用的方法,即对加锁对象进行排序。游戏对象在产生时都会有一个唯一的id做标识,当lock ()函数能按照一种稳定的算法对这些id进行排序时,就可以避免死锁。比如对游戏对象进行分类:player、npc、monster等,先对分类进行排序,再对对象的id进行排序。需要注意的是MMORPG游戏经常需要进行合服操作,为了保证合服后player的id不会重复,需要对player_id进行一些规划。

    总结:

    优点:服务器程序扮演上帝的角色,可以获得几乎所有的信息,这对逻辑编写带来极大的便利。和“自我”模式一样,最好把移动的相关逻辑独立出来使用不同的锁,以免照成过多的加锁冲突和等待。“上帝之手”模式更容易进行整体规划,更容易实现模块化设计,降低程序的耦合度。

    缺点:上帝也不是这么好演的,“上帝之手”模式对整体框架、接口设计、加锁策略等有更高的要求,同时对编程人员的要求也会更高。


    展开全文
  • 系统构架演变

    千次阅读 2018-12-12 11:34:29
    1.系统构架演变 随着互联网的发展,网站应用的规模不断扩大。需求的激增,带来的是技术上的压力。系统架构也因此也不断的演进、升级、迭代。从单一应用,到垂直拆分,到分布式服务,到SOA,以及现在火热的微服务架构...

    1.系统构架演变

    随着互联网的发展,网站应用的规模不断扩大。需求的激增,带来的是技术上的压力。系统架构也因此也不断的演进、升级、迭代。从单一应用,到垂直拆分,到分布式服务,到SOA,以及现在火热的微服务架构,还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方,还是偏安一隅得过且过?

    2.集中式架构/单体应用

    当网站流量很小时,只需要一个应用,将所有的功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
    在这里插入图片描述
    存在的问题:

    • 代码耦合,开发维护困难
    • 单点容错率低,并发能力差

    2.垂直拆分

    当访问量逐渐增大,单一应用无法满足需求,此时为了应对更高的并发和业务需求,我们根据业务功能对系统进行拆分:在这里插入图片描述
    优点:

    • 系统拆分实现了流量分担,一定程度上解决了并发问题
    • 系统间相互独立
    • 方便水平扩展,负载均衡,容错率提高

    缺点:

    • 服务之间相互调用,如果某个服务的端口或者ip地址发生改变,调用的系统得手动改变
    • 搭建集群之后,实现负载均衡比较复杂

    3.分布式服务

    什么是分布式:将一个大的系统拆分成多个子系统

    当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式调用是关键。
    在这里插入图片描述

    优点:

    • 将基础服务/公共接口 进行了抽取,系统间相互调用,提高了代码复用和开发效率

    缺点:

    • 系统间耦合度变高,调用关系错综复杂,难以维护
    • 搭建集群之后,负载均衡比较难实现

    4.服务治理(SOA)

    OOP:面向对象编程
    AOP:面向切面编程
    SOA:面向服务编程

    当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键在这里插入图片描述
    以前出现了什么问题?

    • 服务越来越多,需要管理每个服务的地址
    • 调用关系错综复杂,难以理清依赖关系
    • 服务过多,服务状态难以管理,无法根据服务情况动态管理

    服务治理要做什么?

    • 服务注册中心,实现服务自动注册和服务自动发现(无需人为记录服务地址)
    • 服务自动订阅,服务列表自动推送,服务调用透明化(无需关心依赖关系)
    • 自动监控服务状态(人为控制服务状态)

    缺点:

    • 服务间会有依赖关系,一旦某个环节出错会影响较大
    • 服务关系复杂,运维、测试部署困难,不符合DevOps思想(docker)

    5.微服务

    OOP:面向对象
    AOP:面向切面
    SOA:面向服务
    前面说的SOA,英文翻译过来是面向服务的编程。微服务,似乎也是服务,都是对系统进行拆分。因此两者非常容易混淆,但其实却有一些差别:在这里插入图片描述
    微服务的特点:

    • 单一职责:微服务中每一个服务都对应唯一的业务能力,做到单一职责
    • 微:微服务的服务拆分粒度很小,例如一个用户管理就可以作为一个服务。每个服务虽小,但“五脏俱全”。
    • 独立:自治是说服务间互相独立,互不干扰
      • 团队独立:每个服务都是一个独立的开发团队,人数不能过多。
      • 技术独立:因为是面向服务,提供Rest接口,使用什么技术没有别人干涉
      • 前后端分离:采用前后端分离开发,提供统一Rest接口,后端不用再为PC、移动端开发不同接口
      • 数据库分离:每个服务都使用自己的数据源
      • 部署独立,服务间虽然有调用,但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件,可复用,可替换,降低耦合,易维护 Docker部署服务

    微服务结构图:在这里插入图片描述

    展开全文
  • 提到“构架”一词,脑海...说到这,还是对“构架”理解不深。那么带着问题去《软件构架实践》这本书中寻找答案。 第一章的《构架商业周期》让我了解了构架的产生,什么是好的构架以及构架商业周期。构架是若干商业...
  • CXF架构

    2017-01-13 14:28:57
    想对CXF有点了解,看了一些资料后,感觉还是需要CXF的整体构架后,再看CXF会更好一些。把看的架构资料总结一下。 正文 Apache CXF 框架结构和基本原理:内容不是很多,但很简单,先看这个。 [译]CXF 架构:这个比较...
  • 三层构架

    2017-12-08 15:42:33
    三层架构已经学了一段时间,一直想做一个比较完整、比较完美的总结。但是左思右想,不知道如何下笔。都说万事开头难嘛,今天整理了一下凌乱的思路,哎,还是没整理好,想到哪就说到哪吧。   初学者很不理解: 1,...
  • 构架漫谈》读后感

    2016-04-28 19:58:00
    其实,早就听说过,也接触过,但是我对架构还是缺乏一定的认识,今天读了老师介绍的博客,才有了一定的理解。博客比较权威,但是并不是很晦涩难懂,作者通过一系列的例子,向我们讲述了有关构建的知识。博客叫《构建...
  • 辛星漫谈构架师之魂

    2014-09-17 23:39:32
    架构还是蛮重要的,往往他们的高度决定了公司的技术高度,特别是中小型公司,而他们的决策也往往会直接决定了团队的开发模式和工作量的大小。  如果把职场必做战场,那么构架师就可以理解为“将军”或者“元帅”...
  • 再上一章,我提到了软件架构的设计,在这一章,我认为最重要的还是对于软件构架的概念。 软件构架概念的澄清对于什么是软件构架非常的重要,在数中,使用了图文并茂的方法使得概念更加的成功解释。但是,我们从中...
  • 7层是框架还是架构? 框架: 1、定义: 框架(framework)是整个或部分系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法,另一种定义为,框架是可被应用开发者定制的应用骨架,前者是从应用方面而...
  • 公司组织构架的三大类型

    千次阅读 2018-07-20 22:13:00
    这一篇主要是和同事瞎侃的时候想到的,对于管理学,我只是了解一点点组织架构的理论知识,可以在这里简单分享一下: 公司组织构架的三大类型 如果要严格的区分,公司的组织结构远不止三大类型,但抽象出来的话其实...
  • 一、前言 当今互联网时代中,B/S(Browser/Server , 浏览器/服务器)以及C/S(Client/...但是B/S以及C/S架构软件都会有Server,也就是B/S或者C/S中的S,无论是Browser还是Client都必须与Server进行数据交互、传输,...
  • 本文讲的是云计算对IT构架的变革 开放式VS封闭式,开放式云计算好,还是封闭式云计算平台好”的话题业内一直没有停止过争论,毕竟在这种新型的商业模式中开放构架与否并不决定着云计算落地和用户的体验。开放架构和...
  • 构架之美读后感1

    2017-02-19 21:32:00
    但在看了《架构之美》这本书之后,对架构有了一个大致的认识(总觉得那些东西有些抽象,没有真正做过很多项目,积累过一定经验的人要想理解透彻还是有难度的)。下面就说说我读了这本书之后的一些感想吧。书中提到了...
  • 但是其实据我们所知,无论是从技术角度还是从管理角度,目前针对实际软件开发组织的、有关如何管理软件构架的实用指导文献还十分地缺乏。所以,这本书的主旨就是基于如何把软件构架和行业或组织的实际情况结合起来的...
  • 简单了解 前端构架模式MVC与MVVM

    千次阅读 2021-03-03 05:06:40
    MVC不是框架,不是设计模式,也不是软件架构,而是一种架构模式。MVC的出现是为了让应用的业务逻辑、数据和界面显示分离的方法来组织代码。 Model-View-ViewModel的缩写,而本质上还是MVC的改进版。其设计思想是...
  • 本课程基于CSS开发中的痛点问题,通过高仿蘑菇街项目,带你从0到1构架自己的CSS代码,形成一套成熟的易维护、易扩展、易复用的架构思想。不管是架构还是技巧层面,都能玩转CSS! 用 JS 分割文本 还有一种经常用到...
  • 年初的时候,写过一篇名为“国内EAI正...SOA已经不再是概念,而是一个实实在在的构架了。    在写完那篇帖子之后,我一直在反思SOA到底是什么,是一种什么样的架构。因为在在TIBCO中国研发中心工作的原因,可...
  • 架构和框架的区别

    千次阅读 热门讨论 2016-05-11 09:56:40
    7层是框架还是架构?  框架:    1、定义:  框架(framework)是整个或部分系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法,另一种定义为,框架是可被应用开发者定制的应用骨架,前者是从应用...
  • 三层架构之登录

    2019-10-06 15:34:07
    一:三层构架的基础知识 在项目开发的过程中,有时把整个项目分为三层架构,其中包括:表示层(UI)、业务逻辑层(BLL)和数据访 问层(DAL)。三层的作用分别如下: 表示层: 为用户提供交互操作界面,这一点不论是...
  • 在互联网时代不论BAT这样的大厂团队还是创业型中小团队都不约而同的选择了MySQL,所以在应用之余有必要了解其内部架构和内在逻辑的。 网传的这张Mysql的构架图很经典但也很复杂,不知道准备发奋拿下MySQL的小伙伴被...
  • 动静分离:分析用户请求的资源后缀名决定交由后端的静态还是动态服务器,后端的静态或动态服务器也可以做负载均衡3.固态硬盘组合成raid 0做缓存,前端缓存如果挂了,用户请求直接压到后端会产生整个架构崩溃,产生...
  • 本文不是从理论的角度来探讨三层架构,而是用一个示例来介绍如何建设一个三层架构的项目,并说明项目中各个文件所处的层次与作用。...导致看了之后,理论上又学习了一遍,但还是不知道代码怎么写。所以想从这...
  • @Author : By Runsen @Date : 2020/6/21 作者介绍:Runsen目前大三下学期,专业化学工程与工艺,大学沉迷日语,Python, Java和一系列...文章目录9.5 Sqoop和Flume9.5.3 Flume基本架构和安装(1) Flume基本架构(2)
  • 这是我国第一家具有独立法人代表的直销银行,也是一家纯粹将业务构架在云上的互联网公司,还是一家正在利用AI构建智慧大脑的金融机构。尽管云计算谈论多年,并在行业中逐步落地。但在金融机构中,真正全部用分布式...
  • winform三层架构之登录

    2018-11-28 22:56:51
    一:三层构架的基础知识 在项目开发的过程中,有时把整个项目分为三层架构,其中包括:表示层(UI)、业务逻辑层(BLL)和数据访  问层(DAL)。三层的作用分别如下:    表示层: 为用户提供交互操作界面,这一点...
  • 这是我国第一家具有独立法人代表的直销银行,也是一家纯粹将业务构架在云上的互联网公司,还是一家正在利用AI构建智慧大脑的金融机构。尽管云计算谈论多年,并在行业中逐步落地。但在金融机构中,真正全部用分布式...

空空如也

空空如也

1 2 3 4 5 ... 7
收藏数 121
精华内容 48
关键字:

构架还是架构