1）1946-1954年，第一代电子管计算机时代 1946年，第一台电子计算机ENIAC研制成功；1951年，IBM生产出第一台用于科学计算的大型机IBM 701；1953年，IBM推出了第一台用于数据处理的大型机IBM702和第一台小型机IBM650，为第一代商用计算机描绘出了一个丰满而生动的形象。
2）1954-1964年，晶体管造就了第二代计算机 1954年，第一台使用晶体管的第二代计算机TRADIC诞生于美国贝尔实验室,采用了浮点运算，实现计算能力的飞跃；1958年，大型科学计算机IBM 7090诞生，实现了晶体化；1961年，第一台流水线计算机IBM7030研制成功，其成为了超级计算机的雏形
3）1964-1970年，集成电路使第三代计算机脱胎换骨 1964年，第一台通用计算机IBM/360研制成功，其采用了集成电路技术，实现了通用性（集科学计算、数据处理和实时控制功能于一身）、系列化（区分了小型机、大型机和超级计算机，统一了指令格式、数据格式、字符编码、I\O接口和中断系统，实现了不同型号兼容）和可扩展性（具有开发价值），成为了计算机发展史上的一个重要里程碑；
4）1970年至今，第四代计算机 1970年，IBM S/370问世，单晶硅电路技术、虚拟存储器技术、多处理技术相继应用其中，到1976年，S/370已发展成为具有17种型号的庞大家族。 1981年，S/370系列的地址线位数被增加到了31位，大大增强了其寻址能力，并且在存储方面还增加了扩展存储器，与主存分离，改善了系统性能。 80代年上半叶以前，服务器主要是面向高端用户。80年代下半叶，大型机系统体系机构更新步伐加快。1986年，IBM 9370系列发布，标志着S/370开始向低端方向延伸，目标是服务于中小型企业。
所谓刀片服务器是指在标准高度的机架式机箱内可插装多个卡式的服务器单元，实现高可用和高密度。每一块"刀片"实际上就是一块系统主板。它们可以通过"板载"硬盘启动自己的操作系统，如Windows NT/2000、Linux等，类似于一个个独立的服务器，在这种模式下，每一块母板运行自己的系统，服务于指定的不同用户群，相互之间没有关联。不过，管理员可以使用系统软件将这些母板集合成一个服务器集群。在集群模式下，所有的母板可以连接起来提供高速的网络环境，并同时共享资源，为相同的用户群服务。在集群中插入新的"刀片"，就可以提高整体性能。而由于每块"刀片"都是热插拔的，所以，系统可以轻松地进行替换，并且将维护时间减少到最小。
这些刀片服务器在设计之初都具有低功耗、空间小、单机售价低等特点，同时它还继承发扬了传统服务器的一些技术指标，比如把热插拔和冗余运用到刀片服务器之中，这些设计满足了密集计算环境对服务器性能的需求；有的还通过内置的负载均衡技术，有效地提高了服务器的稳定性和核心网络性能。而从外表看，与传统的机架/塔式服务器相比，刀片服务器能够最大限度地节约服务器的使用空间和费用，并为用户提供灵活、便捷的扩展升级手段。
刀片服务器的特点
刀片服务器公认的特点有两个，一是克服了芯片服务器集群的缺点，被成为集群的终结者；另一个是实现了机柜优化。
集群终结者
众所周知，作为一种负载均衡技术，服务器集群已经在有效提高系统的稳定性和核心网络服务的性能方面被广泛采用，在集群系统中，若要提供更高端的运算和服务性能，只需增加更多的单元就可以获得更高的性能。更为重要的是，服务器集群还可以为任何一台单独的服务器提供冗余和容错功能。
目前IT行业正在大力发展适应宽带网络、功能强大可靠的计算机。在过去的几年里，宽带技术极大地丰富了信息高速公路的传输内容。服务器集群和RAID技术的诞生为计算机和数据池的互联网应用提供了一个新的解决方案，而其成本却远远低于传统的高端专用服务器和大型机。但是，服务器集群的集成能力低，管理这样的集群使很多管理员非常头疼。尤其是集群扩展的需求越来越大，维护这些服务器的工作量简直不可想像，包括服务器之间的内部连接和摆放空间的要求。这些物理因素都限制了集群的扩展。刀片服务器的出现适时地解决了这些问题。在集群模式下，刀片服务器所有的主板可以连接起来提供高速的网络环境，共享资源。同时每个刀片都可内置监视器和管理工具软件， 配置一台高密度服务器就可以解决一台到一百台服务器的管理问题，如果需要增加或者删除集群中的服务器，只要插入或拔出一块板即可，将维护时间减少到最小。就这个意义上来说，Blade Server从根本上克服了服务器集群的缺点。
实现机柜优化
从某一角度而言，刀片服务器实现了机柜优化的自然飞跃。刀片服务器将机柜式服务器所占用的空间密度再一次提高了50%。资料显示，在机柜系统配置好的前提下，将1U机架优化服务器系统移植到刀片服务器上，所占用的空间只是原来的1/3～1/2。而在一个标准的机柜式环境里，刀片服务器的处理密度要提高四到五倍。比如在处理1024节点的高密度计算服务器环境里，1U配置需要24个机柜，其中不包括以太网交换集线器所占用的机柜空间，而采用插有8个"刀片"的刀片服务器，只需要9个机柜，却包括了以太网交换机的空间。在相同的面积内，数据中心可以通过部署刀片服务器获得8倍于机架式服务器的服务器租赁收益。
另外，刀片服务器采用集中管理的方式，可以简化服务器的管理工作。在IT人员日益匮乏的今天，采用刀片服务器的企业可以减少雇佣工资高昂的服务器管理和维护人员，从而降低维护费用。还有，刀片服务器的低功耗设计也会显著减少能耗，节约能源的同时减少了费用。
作为一种新兴的服务器产品，读者可能还缺乏对它的直观认识。每台刀片服务器一般由机柜和刀片组成，因此刀片服务器的标识由机柜的型号和刀片的型号共同构成，而不像以往的服务器那样由一个单一的服务器型号所代表。刀片通过机柜背板上的CompacPCI接口与之相连接。服务器机柜一般可以容纳8片至数十片刀片。刀片以服务器刀片为主，而每个服务器刀片都是一个功能完整的服务器。
在此，我们以一款常见的一种刀片服务器向大家介绍一下，以了解其基本构成。
根据所需要承担的服务器功能，刀片服务器被分成服务器刀片、网络刀片、存储刀片、管理刀片、光纤通道SAN刀片、扩展I/O刀片等等不同功能的相应刀片服务器。
目前最为常见的服务器刀片一般采用1颗为的Intel Pentium Ⅲ处理器，并采用ServerWorks LC-E芯片组、Intel 815芯片组、Via Pro266芯片组，支持的内存容量和类型由芯片组决定，内存类型一般为具有ECC功能的SDRAM或DDR。由于刀片服务器的散热问题较为严重，在设计中也有厂商采用了低功耗的Transmeta 5600处理器。目前，HP、Sun也正致力于把它们的RISC处理器制作成服务器刀片，只是尚未面世。
除连接机柜背板的接口外，服务器刀片上一般还具有一个PMC扩展接口，可以连接PMC接口的扩展卡，如SCSI卡、光纤存储卡等，其功能相当于PCI扩展槽，只是相应接口的扩展卡价格略贵。 服务器刀片采用与笔记本电脑相同规格的65mm(2.5英寸)硬盘，一般只安装操作系统和简单的应用软件，性能较低。
网络刀片
网络刀片的功能相当于局域网交换机，从而提供良好的网络监控和管理功能。网络刀片普遍提供10/100Mbps端口，以双绞线的方式连接服务器刀片，对外提供高速上连通道(千兆端口)。采用NAS存储方式的刀片服务器经常会配备2个网络刀片，其中一个专门用于连接NAS设备。每个刀片支持10/100/1000M以太网连接，并且可以在背板上安装10/100/1000M的2-4层交换机，这样就可以把系统中每个槽位上安装的刀片与交换机连接起来，提供一个基于IP的交换网络。通过集成这种总线，刀片服务器系统可以很好地集成IP业务和语音业务，提供各种不同的电信增值服务。
存储刀片
存储刀片可以被视为一个硬盘模块，通过背板总线或者硬盘接口线向服务器刀片提供存储功能。存储刀片上一般配备2块性能较高90mm(3.5英寸)硬盘，接口类型有IDE、SCSI和光纤通道(Fiber Channel)接口。
管理刀片
第一代刀片服务器的KVM(Keyboard、VGA、Mouse)刀片可以说是功能最为简单的管理刀片，提供对所有服务器刀片的管理控制。KVM刀片，提供键盘、鼠标、显示器接口，KVM刀片经常还包括软驱和光驱，便于使用者直接操作服务器刀片。KVM刀片上提供切换开关，用于在机柜上的不同刀片之间或者不同机柜之间进行切换。第二代刀片服务器具备更加强大的管理功能，但是各家产品各不相同。管理刀片往往通过服务器刀片上集成的监控管理芯片进行1台或多台刀片服务器的集中监控和管理。管理刀片向服务器机柜内的其他刀片提供必要的配置信息，并在某些刀片发生故障时接收报警信息，并向监控程序发出报警。
CompactPCI ：刀片服务器的标准
CompactPCI开放式标准架构很好地平衡了业界标准，包括硬件、操作系统、应用开发工具、能快速有效开发高利润的电信增值服务，同时使传统上以专有软硬件架构为主的电信建设转型，能享受开放系统带来成本大幅降低及大众化业界标准操作系统的好处。这一转变让设备及服务供应商找到了数以百万计的开发者，并开始采用具高可靠性、高扩展性和高性能的CompactPCI宽频通讯平台。
CompactPCI总线标准是建立刀片服务器的基础。它是惟一的标准，同时也是标准纷争的起源。CompactPCI目前有2个主要的版本，即 1.0版和2.0版，它们在接口定义的完善程度上不尽相同。早期的刀片服务器全部采用CompactPCI 1.0的标准，背板带宽也限定在32位PCI之内，这些产品属于第一代刀片服务器。2002年最新推出的刀片服务器部分采用CompactPCI 2.0标准，背板支持64位PCI通信，称之为第二代刀片服务器。由于标准的版本不同，两代刀片服务器之间不能完全兼容。
目前为止，只有HP一家声称完全按照CompactPCI标准设计刀片服务器，而其他服务器厂商只是在总线和接口标准方面遵循CompactPCI，在刀片的尺寸上没有完全按照该标准去执行。
应用模式指南
刀片服务器的应用很广泛，尤其是对于计算密集型应用，比如天气预报建模、数据采集、数据仿真、数字影象设计、空气动力学建模等等。而对于行业应用，如电信、金融、 IDC/ASP/ISP应用、移动电话基站、视频点播、Web主机操作及实验室系统等，刀片服务器依然能大显身手。刀片服务器的出现使其在2001年底的服务器市场上占据一块相对于机架式服务器来说不算小的市场份额。而随着2002年技术的发展尤其是InfiniBand技术开始扮演重要角色，刀片服务器将逐渐成为主流服务器并占据较大的市场份额。
刀片服务器的使用范围相当广泛。下面我们列出两个典型的应用模式进行简单的介绍。
应用模式1：网站Web服务器
这种方式可充分发挥刀片服务器密度高、可群集以及可远程管理的优势。网站可以用刀片服务器组成高密度的群集，用来实现高访问量的Web服务器，后端再连接中高端的服务器或群集系统作为数据库服务器。存储服务提供商可以采用同样的前端方案，后端配合NAS设备来提供存储服务。与普通机架服务器相比，刀片服务器在这类应用中的优势在于占用机位少，可有效节省托管费用。
应用模式2：中小企业网络服务器
当前的企业网络需求是多方面的，需要类型多样的服务，其中有些服务可以安装在一台机器上，而有些则需要使用至少一台备份机器或者群集。与之相对应，任何一个刀片系统既可以独立运行，也可以与其他服务器组成群集或互为备份。根据企业的实际需要进行搭配。这种方式可充分发挥刀片服务器易管理、配置灵活和可扩展性好的优势。 使用刀片服务器进行群集并与存域网相结合，这可以胜任大数据量吞吐的数据库并行处理。对于企业来说，这种高密度不仅节约了宝贵的机柜空间，还节约了布线成本，并可节电，从而降低对UPS的要求。
塔式服务器应该是大家见得最多，也最容易理解的一种服务器结构类型，因为它的外形以及结构都跟我们平时使用的立式PC差不多，当然，由于服务器的主板扩展性较强、插槽也多出一堆，所以个头比普通主板大一些，因此塔式服务器的主机机箱也比标准的ATX机箱要大，一般都会预留足够的内部空间以便日后进行硬盘和电源的冗余扩展。
由于塔式服务器的机箱比较大，服务器的配置也可以很高，冗余扩展更可以很齐备，所以它的应用范围非常广，应该说目前使用率最高的一种服务器就是塔式服务器。我们平时常说的通用服务器一般都是塔式服务器，它可以集多种常见的服务应用于一身，不管是速度应用还是存储应用都可以使用塔式服务器来解决。
就使用对象或者使用级别来说，目前常见的入门级和工作组级服务器基本上都采用这一服务器结构类型，一些部门级应用也会采用，不过由于只有一台主机，即使进行升级扩张也有个限度，所以在一些应用需求较高的企业中，单机服务器就无法满足要求了，需要多机协同工作，而塔式服务器个头太大，独立性太强，协同工作在空间占用和系统管理上都不方便，这也是塔式服务器的局限性。不过，总的来说，这类服务器的功能、性能基本上能满足大部分企业用户的要求，其成本通常也比较低，因此这类服务器还是拥有非常广泛的应用支持。
机架式服务器的外形看来不像计算机，而像交换机，有1U（1U=1.75英寸）、2U、4U等规格。机架式服务器安装在标准的19英寸机柜里面。这种结构的多为功能型服务器。
对于信息服务企业（如ISP/ICP/ISV/IDC）而言，选择服务器时首先要考虑服务器的体积、功耗、发热量等物理参数，因为信息服务企业通常使用大型专用机房统一部署和管理大量的服务器资源，机房通常设有严密的保安措施、良好的冷却系统、多重备份的供电系统，其机房的造价相当昂贵。如何在有限的空间内部署更多的服务器直接关系到企业的服务成本，通常选用机械尺寸符合19英寸工业标准的机架式服务器。机架式服务器也有多种规格，例如1U（4.45cm高）、2U、4U、6U、8U等。通常1U的机架式服务器最节省空间，但性能和可扩展性较差，适合一些业务相对固定的使用领域。4U以上的产品性能较高，可扩展性好，一般支持4个以上的高性能处理器和大量的标准热插拔部件。管理也十分方便，厂商通常提供人相应的管理和监控工具，适合大访问量的关键应用，但体积较大，空间利用率不高。
端游、手游服务端常用的架构是什么样的？类型1：卡牌、跑酷等弱交互服务端卡牌跑酷类
因为交互弱，玩家和玩家之间不需要实时面对面PK，打一下对方的离线数据，计算下排行榜，买卖下道具即可，所以实现往往使用简单的 HTTP服务器：
登录时可以使用非对称加密（RSA, DH），服务器根据客户端uid，当前时间戳还有服务端私钥，计算哈希得到的加密 key 并发送给客户端。之后双方都用 HTTP通信，并用那个key进行RC4加密。客户端收到key和时间戳后保存在内存，用于之后通信，服务端不需要保存 key，因为每次都可以根据客户端传上来的 uid 和 时间戳 以及服务端自己的私钥计算得到。用模仿 TLS的行为，来保证多次 HTTP请求间的客户端身份，并通过时间戳保证同一人两次登录密钥不同。
每局开始时，访问一下，请求一下关卡数据，玩完了又提交一下，验算一下是否合法，获得什么奖励，数据库用单台 MySQL或者 MongoDB即可，后端的 Redis做缓存（可选）。如果要实现通知，那么让客户端定时15秒轮询一下服务器，如果有消息就取下来，如果没消息可以逐步放长轮询时间，比如30秒；如果有消息，就缩短轮询时间到10秒，5秒，即便两人聊天，延迟也能自适应。
此类服务器用来实现一款三国类策略或者卡牌及酷跑的游戏已经绰绰有余，这类游戏因为逻辑简单，玩家之间交互不强，使用 HTTP来开发的话，开发速度快，调试只需要一个浏览器就可以把逻辑调试清楚了。
类型2：第一代游戏服务器 1978
1978年，英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个MUD程序《MUD1》，在University of Essex于1980年接入 ARPANET之后加入了不少外部的玩家，甚至包括国外的玩家。《MUD1》程序的源代码在 ARPANET共享之后出现了众多的改编版本，至此MUD才在全世界广泛流行起来。不断完善的 MUD1的基础上产生了开源的 MudOS（1991），成为众多网游的鼻祖：
MUDOS采用 C语言开发，因为玩家和玩家之间有比较强的交互（聊天，交易，PK），MUDOS使用单线程无阻塞套接字来服务所有玩家，所有玩家的请求都发到同一个线程去处理，主线程每隔1秒钟更新一次所有对象（网络收发，更新对象状态机，处理超时，刷新地图，刷新NPC）。
游戏世界采用房间的形式组织起来，每个房间有东南西北四个方向可以移动到下一个房间，由于欧美最早的网游都是地牢迷宫形式的，因此场景的基本单位被成为 “房间”。MUDOS使用一门称为LPC的脚本语言来描述整个世界（包括房间拓扑，配置，NPC，以及各种剧情）。游戏里面的高级玩家（巫师），可以不断的通过修改脚本来为游戏添加房间以及增加剧情。早年 MUD1上线时只有17个房间，Roy Trubshaw毕业以后交给他的师弟 Richard Battle，在 Richard Battle手上，不断的添加各种玩法到一百多个房间，终于让 MUD发扬光大。
用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上，使用纯文字进行游戏，每条指令用回车进行分割。比如 1995年国内第一款 MUD游戏《侠客行》，你敲入：”go east”，游戏就会提示你：“后花园 - 这里是归云庄的后花园，种满了花草，几个庄丁正在浇花。此地乃是含羞草生长之地。这里唯一的出口是 north。这里有：花待 阿牧（A mu），还有二位庄丁（Zhuang Ding）”，然后你继续用文字操作，查看阿牧的信息：“look a mu”，系统提示：“花待 阿牧（A mu）他是陆乘风的弟子，受命在此看管含羞草。他看起来三十多岁，生得眉清目秀，端正大方，一表人才。他的武艺看上去【不是很高】，出手似乎【极轻】”。然后你可以选择击败他获得含羞草，但是你吃了含羞草却又可能会中毒死亡。在早期网上资源贫乏的时候，这样的游戏有很强的代入感。
用户数据保存在文件中，每个用户登录时，从文本文件里把用户的数据全部加载进来，操作全部在内存里面进行，无需马上刷回磁盘。用户退出了，或者每隔5分钟检查到数据改动了，都会保存会磁盘。这样的系统在当时每台服务器承载个4000人同时游戏，不是特别大的问题。从1991年的 MUDOS发布后，全球各地都在为他改进，扩充，退出新版本，随着 Windows图形机能的增强。1997游戏《UO》在 MUDOS的基础上为角色增加的x,y坐标，为每个房间增加了地图，并且为每个角色增加了动画，形成了第一代的图形网络游戏。
因为游戏内容基本可以通过 LPC脚本进行定制，所以MUDOS也成为名副其实的第一款服务端引擎，引擎一次性开发出来，然后制作不同游戏内容。后续国内的《万王之王》等游戏，很多都是跟《UO》一样，直接在 MUDOS上进行二次开发，加入房间的地图还有角色的坐标等要素，该架构一直为国内的第一代 MMORPG提供了稳固的支持，直到 2003年，还有游戏基于 MUDOS开发。虽然后面图形化增加了很多东西，但是这些MMORPG后端的本质还是 MUDOS。随着游戏内容的越来越复杂，架构变得越来越吃不消了，各种负载问题慢慢浮上水面，于是有了我们的第二代游戏服务器。
类型3：第二代游戏服务器 2003
2000年后，网游已经脱离最初的文字MUD，进入全面图形化年代。最先承受不住的其实是很多小文件，用户上下线，频繁的读取写入用户数据，导致负载越来越大。随着在线人数的增加和游戏数据的增加，服务器变得不抗重负。同时早期 EXT磁盘分区比较脆弱，稍微停电，容易发生大面积数据丢失。因此第一步就是拆分文件存储到数据库去。
此时游戏服务端已经脱离陈旧的 MUDOS体系，各个公司在参考 MUDOS结构的情况下，开始自己用 C在重新开发自己的游戏服务端。并且脚本也抛弃了 LPC，采用扩展性更好的 Python或者 Lua来代替。由于主逻辑使用单线程模型，随着游戏内容的增加，传统单服务器的结构进一步成为瓶颈。于是有人开始拆分游戏世界，变为下面的模型：
游戏服务器压力拆分后得意缓解，但是两台游戏服务器同时访问数据库，大量重复访问，大量数据交换，使得数据库成为下一个瓶颈。于是形成了数据库前端代理（DB Proxy），游戏服务器不直接访问数据库而是访问代理，再有代理访问数据库，同时提供内存级别的cache。早年 MySQL4之前没有提供存储过程，这个前端代理一般和 MySQL跑在同一台上，它转化游戏服务器发过来的高级数据操作指令，拆分成具体的数据库操作，一定程度上代替了存储过程：
但是这样的结构并没有持续太长时间，因为玩家切换场景经常要切换连接，中间的状态容易错乱。而且游戏服务器多了以后，相互之间数据交互又会变得比较麻烦，于是人们拆分了网络功能，独立出一个网关服务 Gate（有的地方叫 Session，有的地方叫 LinkSvr之类的，名字不同而已）：
把网络功能单独提取出来，让用户统一去连接一个网关服务器，再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网管进行交换。这样类型的服务器基本能稳定的为玩家提供游戏服务，一台网关服务1-2万人，后面的游戏服务器每台服务5k-1w，依游戏类型和复杂度不同而已，图中隐藏了很多不重要的服务器，如登录和管理。这是目前应用最广的一个模型，到今天任然很多新项目会才用这样的结构来搭建。
人都是有惯性的，按照先前的经验，似乎把 MUDOS拆分的越开性能越好。于是大家继续想，网关可以拆分呀，基础服务如聊天交易，可以拆分呀，还可以提供web接口，数据库可以拆分呀，于是有了下面的模型：
这样的模型好用么？确实有成功游戏使用类似这样的架构，并且发挥了它的性能优势，比如一些大型 MMORPG。但是有两个挑战：每增加一级服务器，状态机复杂度可能会翻倍，导致研发和找bug的成本上升；并且对开发组挑战比较大，一旦项目时间吃紧，开发人员经验不足，很容易弄挂。
比如我见过某上海一线游戏公司的一个 RPG上来就要上这样的架构，我看了下他们团队成员的经验，问了下他们的上线日期，劝他们用前面稍微简单一点的模型。人家自信得很，认为有成功项目是这么做的，他们也要这么做，自己很想实现一套。于是他们义无反顾的开始编码，项目做了一年多，然后，就没有然后了。
现今在游戏成功率不高的情况下，一开始上一套比较复杂的架构需要考虑投资回报率，比如你的游戏上线半年内 PCU会去到多少？如果一个 APRG游戏，每组服务器5千人都到不了的话，那么选择一套更为贴近实际情况的结构更为经济。即使后面你的项目真的超过5千人朝着1万人目标奔的话，相信那个时候你的项目已经挣大钱了 ，你数着钱加着班去逐步迭代，一次次拆分它，相信心里也是乐开花的。
上面这些类型基本都是从拆分 MUDOS开始，将 MUDOS中的各个部件从单机一步步拆成分布式。虽然今天任然很多新项目在用上面某一种类似的结构，或者自己又做了其他热点模块的拆分。因为他们本质上都是对 MUDOS的分解，故将他们归纳为第二代游戏服务器。
类型4：第三代游戏服务器
2007从魔兽世界开始无缝世界地图已经深入人心，比较以往游戏玩家走个几步还需要切换场景，每次切换就要等待 LOADING个几十秒是一件十分破坏游戏体验的事情。于是对于 2005年以后的大型 MMORPG来说，无缝地图已成为一个标准配置。比较以往按照地图来切割游戏而言，无缝世界并不存在一块地图上面的人有且只由一台服务器处理了：
每台 Node服务器用来管理一块地图区域，由 NodeMaster（NM）来为他们提供总体管理。更高层次的 World则提供大陆级别的管理服务。这里省略若干细节服务器，比如传统数据库前端，登录服务器，日志和监控等，统统用 ADMIN概括。在这样的结构下，玩家从一块区域走向另外一块区域需要简单处理一下：
玩家1完全由节点A控制，玩家3完全由节点B控制。而处在两个节点边缘的2号玩家，则同时由A和B提供服务。玩家2从A移动到B的过程中，会同时向A请求左边的情况，并向B请求右边的情况。但是此时玩家2还是属于A管理。直到玩家2彻底离开AB边界很远，才彻底交由B管理。按照这样的逻辑将世界地图分割为一块一块的区域，交由不同的 Node去管理。
对于一个 Node所负责的区域，地理上没必要连接在一起，比如大陆的四周边缘部分和高山部分的区块人比较少，可以统一交给一个Node去管理，而这些区块在地理上并没有联系在一起的必要性。一个 Node到底管理哪些区块，可以根据游戏实时运行的负载情况，定时维护的时候进行更改 NodeMaster 上面的配置。于是碰到第一个问题是很多 Node服务器需要和玩家进行通信，需要问管理服务器特定UID为多少的玩家到底在哪台 Gate上，以前按场景切割的服务器这个问题不大，问了一次以后就可以缓存起来了，但是现在服务器种类增加不少，玩家又会飘来飘去，按UID查找玩家比较麻烦；另外一方面 GATE需要动态根据坐标计算和哪些 Node通信，导致逻辑越来越厚，于是把：“用户对象”从负责连接管理的 GATE中切割出来势在必行于是有了下面的模型：
网关服务器再次退回到精简的网络转发功能，而用户逻辑则由按照 UID划分的 OBJ服务器来承担，GATE是按照网络接入时的负载来分布，而 OBJ则是按照资源的编号（UID）来分布，这样和一个用户通信直接根据 UID计算出 OBJ服务器编号发送数据即可。而新独立出来的 OBJ则提供了更多高层次的服务：
对象移动：管理具体玩家在不同的 Node所管辖的区域之间的移动，并同需要的 Node进行沟通。
数据广播：Node可以给每个用户设置若干 TAG，然后通知 Object Master 按照TAG广播。
对象消息：通用消息推送，给某个用户发送数据，直接告诉 OBJ，不需要直接和 GATE打交道。
好友聊天：角色之间聊天直接走 OBJ/OBJ MASTER。整个服务器主体分为三层以后，NODE专注场景，OBJ专注玩家对象，
GATE专注网络。这样的模型在无缝场景服务器中得到广泛的应用。但是随着时间的推移，负载问题也越来越明显，做个活动，远来不活跃的区域变得十分活跃，靠每周维护来调整还是比较笨重的，于是有了动态负载均衡。动态负载均衡有两种方法，第一种是按照负载，由 Node Master 定时动态移动修改一下各个 Node的边界，而不同的玩家对象按照先前的方法从一台 Node上迁移到另外一台 Node上：
图11 动态负载均衡
Node Master定时查找地图上的热点区域，计算新的场景切割方式，然后告诉其他服务器开始调整，具体处理方式还是和上面对象跨越边界移动的方法一样。但是上面这种方式实现相对复杂一些，于是人们设计出了更为简单直接的一种新方法：
图12 基于网格的动态负载均衡
于网格的动态负载均衡还是将地图按照标准尺寸均匀切割成静态的网格，每个格子由一个具体的Node负责，但是根据负载情况，能够实时的迁移到其他 Node上。在迁移分为三个阶段：准备，切换，完成。三个状态由Node Master负责维护。准备阶段新的 Node开始同步老 Node上面该网格的数据，完成后告诉NM；NM确认OK后同时通知新旧 Node完成切换。完成切换后，如果 Obj服务器还在和老的 Node进行通信，老的 Node将会对它进行纠正，得到纠正的 OBJ将修正自己的状态，和新的 Node进行通信。
很多无缝动态负载均衡的服务端宣称自己支持无限的人数，但不意味着 MMORPG游戏的人数上限真的可以无限扩充，因为这样的体系会受制于网络带宽和客户端性能。带宽决定了同一个区域最大广播上限，而客户端性能决定了同一个屏幕到底可以绘制多少个角色。
从无缝地图引入了分布式对象模型开始，已经完全脱离 MUDOS体系，成为一种新的服务端模型。又由于动态负载均衡的引入，让无缝服务器如虎添翼，容纳着超过上一代游戏服务器数倍的人数上限，并提供了更好的游戏体验，我们称其为第三代游戏服务端架构。网游以大型多人角色扮演为开端，RPG网游在相当长的时间里一度占据90%以上，使得基于 MMORPG的服务端架构得到了蓬勃的发展，然而随着玩家对RPG的疲惫，各种非MMORPG游戏如雨后春笋般的出现在人们眼前，受到市场的欢迎。
类型5：战网游戏服务器
经典战网服务端和 RPG游戏有两个区别：RPG是分区分服的，北京区的用户和广州区的用户老死不相往来。而战网，虽然每局游戏一般都是 8人以内，但全国只有一套服务器，所有的玩家都可以在一起游戏，而玩家和玩家之使用 P2P的方式连接在一起，组成一局游戏：
玩家通过 Match Making 服务器使用：创建、加入、自动匹配、邀请 等方式组成一局游戏。服务器会选择一个人做 Host，其他人 P2P连接到做主的玩家上来。STUN是帮助玩家之间建立 P2P的牵引服务器，而由于 P2P联通情况大概只有 75%，实在联不通的玩家会通过 Forward进行转发。
大量的连接对战，体育竞技游戏采用类似的结构。P2P有网状模型（所有玩家互相连接），和星状模型（所有玩家连接一个主玩家）。复杂的游戏状态在网状模型下难以形成一致，因此星状P2P模型经受住了历史的考验。除去游戏数据，支持语音的战网系统也会将所有人的语音数据发送到做主的那个玩家机器上，通过混音去重再编码的方式返回给所有用户。
战网类游戏，以竞技、体育、动作等类型的游戏为主，较慢节奏的 RPG（包括ARPG）有本质上的区别，而激烈的游戏过程必然带来到较 RPG复杂的多的同步策略，这样的同步机制往往带来的是很多游戏结果由客户端直接计算得出，那在到处都是破解的今天，如何保证游戏结果的公正呢？
主要方法就是投票法，所有客户端都会独立计算，然后传递给服务器。如果结果相同就更新记录，如果结果不一致，会采取类似投票的方式确定最终结果。同时记录本剧游戏的所有输入，在可能的情况下，找另外闲散的游戏客户端验算整局游戏是否为该结果。并且记录经常有作弊嫌疑的用户，供运营人员封号时参考。
类型7：休闲游戏服务器
休闲游戏同战网服务器类似，都是全区架构，不同的是有房间服务器，还有具体的游戏服务器，游戏主体不再以玩家 P2P进行，而是连接到专门的游戏服务器处理：
和战网一样的全区架构，用户数据不能象分区的 RPG那样一次性load到内存，然后在内存里面直接修改。全区架构下，为了应对一个用户同时玩几个游戏，用户数据需要区分基本数据和不同的游戏数据，而游戏数据又需要区分积分数据、和文档数据。胜平负之类的积分可以直接提交增量修改，而更为普遍的文档类数据则需要提供读写令牌，写令牌只有一块，读令牌有很多块。同帐号同一个游戏同时在两台电脑上玩时，最先开始的那个游戏获得写令牌，可以操作任意的用户数据。而后开始的那个游戏除了可以提交胜平负积分的增量改变外，对用户数据采用只读的方式，保证游戏能运行下去，但是会提示用户，游戏数据锁定。
类型8：现代动作类网游
从早期的韩国动作游戏开始，传统的战网动作类游戏和 RPG游戏开始尝试融合。单纯的动作游戏玩家容易疲倦，留存也没有 RPG那么高；而单纯 RPG战斗却又慢节奏的乏味，无法满足很多玩家激烈对抗的期望，于是二者开始融合成为新一代的：动作 + 城镇 模式。玩家在城镇中聚集，然后以开副本的方式几个人出去以动作游戏的玩法来完成各种 RPG任务。本质就是一套 RPG服务端+副本服务端。由于每次副本时人物可以控制在8人以内，因此可以获得更为实时的游戏体验，让玩家玩的更加爽快。
说了那么多的游戏服务器类型，其实也差不多了，剩下的类型大家拼凑一下其实也就是这个样子而已。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）