bs三层架构能做移动端app吗

可以的，注意本文是从技术角度，而不是商业角度来分析。。

从技术角度来看，C/S和B/S除了UI不同，BLL(1)层和DAL层使用相同的DLL；BLL(0)层可以根据C/S、B/S特点开发；

即使用UI-->应用服务器(BLL0)-->BLL1-->DAL的架构方式。

1 首先看一下典型的使用场景

用户下载网页A，此时服务器更新了A的提交逻辑，A再提交后新的逻辑立即起作用，并保证所有的客户端是一样的。

在这一个场景中，有两类人：一类是客户，二类是程序开发者；客户访问了网站，程序开发者更新了网站程序。

2Client：客户端，Server：服务器端，最大的问题就在Server这个词，多数的C/S应用是C/DatabaseServer，而不是C/ApplicationServer。

21 C/DatabaseServer：即各个客户端直接访问了数据库，如果此时各个客户端的BLL层和DAL层是一样的，那没有什么问题；如果因为更新等因为BLL层和DAL层造成了不一致，就可能出现问题。 C/ApplicationServer：即各个客户端访问了应用服务器，而不能直接访问数据库

3接着说B/S，B/S=Browser +C/ApplicationServer，这里C是指Web服务器前端的请求分发的路由器，ApplicationServer即Web服务器。如果有一台Web服务器配置多个域名的经验，应该很清楚这个意思。从技术角度，B/S的本质是，不让Browser 直接读写数据库，而C/S开发则“不会舍近求远”来开发应用服务器层。B/S架构：商业逻辑总是通过Web服务器，才能到达数据库，从而有了保证。而C/S架构，各C均直接访问了数据库，这是最大的不同。

很久以前整理了篇将手机网站做成手机应用的JS框架。时隔一年多，很多新的技术已经出现，下面再来总结下还有哪些框架是适合面向手机设备的开发的。

1、jQueryMobile

jQueryMobile是jQuery在手机上和平板设备上的版本。jQueryMobile不仅会给主流移动平台带来jQuery核心库，而且会发布一个完整统一的jQuery移动UI框架。支持全球主流的移动平台。jQueryMobile开发团队说：能开发这个项目，我们非常兴奋。移动Web太需要一个跨浏览器的框架，让开发人员开发出真正的移动Web网站。

2、jQTouch

jQTouch是一个jQuery的插件，主要用于手机上的Webkit浏览器上实现一些包括动画、列表导航、默认应用样式等各种常见UI效果的JavaScript库。支持包括iPhone、Android等手机。

3、DHTMLXTouch

DHTMLXTouch是一个免费的HTML5/JavaScript框架，专门为触摸屏设备而优化。为您带来快速开发工艺精美的移动Web应用程序的能力。DHTMLXTouchUIDesigner是一个可视化的编辑器用于构建移动用户界面。它能够帮您以最少的编码构建一流的用户界面。在其主页上提供一些示例可以展示DHTMLXTouch强大的用户界面。包括一个menuappfortheiPad(适用于开发餐厅应用)和BookShop(一个电子书店应用)。

4、Mobilizejs

Mobilizejs是一个开源的HTML5-JavaScript框架用于从任何现在有标准网站快速，简便地构建移动网站。这个框架其实就是将需要在移动设备上显示的部分页面以jQueryMobile的默认主题显示，而不是实现一个全新完整的移动页面。Mobilizejs可用于任意网站，但对于基于WordPress和Sphinx的网站不需要使用该框架转换，因为已经有非常多的插件可以使用。

5、TheMProject

The-M-Project是另外一个强大的JavaScript框架，它利用HTML5新的特性来更好和更简便地开发移动应用。这个框架遵循著名的MVC软件架构模式。它还支持离线，所以你的用户可以在没有连接网络的情况下继续操作(当下次有连线的时候，再将数据同步到服务器中)。提供优秀的文档(这个项目拥有一个引导新用户入门的开发指南)。可以查看提供的示例来对该项目有一个初目的了解。这些示例包括：ToDoApp(待办事项目应用)和KitchenSink(这个示例包括这个框架提供的所有UI元素)。

6、WebAppNet

WebAppNet提供了很多的API，因此可以帮助你节省很多工作了。不需要花时间去进行Ajax调用的编码，因为已经内置了，另外还有很多其它内置功能，提供了详细的文档和应用演示。

7、Wijmo

Wijmo是一个基于jQueryUI的UI部件的套件。Wijmo部件进行了优化客户端Web开发和利用jQuery的优越的性能和易用性的力量。所有的Wijmo部件都配备了20多个主题和支持ThemeRoller。

8、960GridonjQuery-Mobile

jquery-mobile-960是一个用于移动Web开发的网格框架，综合了960gs的灵活性和jQueryMobile的方便性。它的目的是让jQueryMobile布局更加的灵活，使得应用应许在移动终端更加易用。

9、SenchaTouchFramework

SenchaTouch是世界上第一个基于HTML5的移动Web开发框架，支持最新的HTML5和CSS3标准，全面兼容Android和AppleiOS设备，提供了丰富的WEBUI组件，可以快速的开发出运行于移动终端的应用程序。Shencha是第一个使用HTML5，CSS和JavaScript并且支持音频/视频，本地存储，圆角，渐变背景以及阴影的开发框架。

10、NimbleKit

NimbleKit是为iOS设备构建应用程序最快速的方式，你不需要知道Objective-C或者iOSSDK，你只需结合JavaScript代码编写HTML页面就可以了。

11、TouchyBoilerplate

TouchyBoilerplate是一个用来创建移动webapp，包括HTML模板，Metatag等的工具。Touchy可以支持动态页面导航，固定页头，滚动内容，浏览历史记录等功能。Touchy使用jQuery或者ZeptoJS。

12、PhoneGap

PhoneGap是一个用基于HTML，CSS和JavaScript的，创建移动跨平台移动应用程序的快速开发平台。它使开发者能够利用iPhone，Android，Palm，Symbian,WP7,Bada和Blackberry智能手机的核心功能——包括地理定位，加速器，联系人，声音和振动等，此外PhoneGap拥有丰富的插件，可以以此扩展无限的功能。PhoneGap是免费的，但是它需要特定平台提供的附加软件，例如iPhone的iPhoneSDK，Android的AndroidSDK等，也可以和DW55配套开发。使用PhoneGap只比为每个平台分别建立应用程序好一点点，因为虽然基本代码是一样的，但是你仍然需要为每个平台分别编译应用程序。

13、joshfire

Joshfire是一个开源的跨设备开发框架，帮助开发者创建可以在多种设备上运行的webapp。它使用HTML5和JavaScript，并且允许开发者快速整合本地应用和特定的web应用。Joshfire可以让你的应用接受键盘，鼠标，触摸屏，遥控器等设备的输入。Joshfire支持NodeJS。4SenchaTouch：基于HTML5的移动网页开发框架。

14、Julia

Julia框架由基本CSS3文件、JS库和各个平台的运行库构成。不像PhoneGap，Julia不仅仅包含调用本机代码的接口层，它还包含Model-View-Controller(MVC)支持，Delegation支持，OAuth支持，异步数据库存取接口，HTML选择符(类jQuery调用接口)，HTML模版(允许嵌入JS代码)等应用开发必备的API接口。基于Julia的应用开发就像网站开发那么简单，是的，你终于可以用HTML5开发一个完整的、跨平台的、不亚于本机代码的、易于维护的移动应用了！大幕即将揭晓，让我们一起进入移动开发的新时代

15、SproutCoreHTML5ApplicationFramework

SproutCore是一个HTML5移动Web开发框架，它的目标是在无需浏览器插件的情况下，在浏览器中位应用程序提供极佳的桌面效果。

16、Titanium

这是一个强大的，健壮的移动Web开发框架。能够让使用现有的HTML,CSS和JavaScript知识来为iOS和Android平台开发原生移动应用。作为一个越来越大的移动Web框架，它拥有超过300个的APIs和活跃的开发者社区。你从这个社区中得到每一个开发人员的帮助。TitaniumMobile支持原生的iOS和AndroidUI元素如Tableviews,tabs,switches和popovers。它提供能够与移动设备的摄像头和本地文件存储系统相交互的特性。

17、Lungojs

Lungojs是一个采用HTML5,CSS3和JavaScript技术实现的移动Web应用程序开发框架。利用这框架开发的应用程序可运行所有流行的平台包括：iOS,Android,Blackberry和WebOs。它还支持触摸事件如：tap,double-tap和swipe。整个框架没有用到任何包括图标，所有都矢量化。可以在这个框架中使用HTML5拥有的一些特性如：WebSQL,地理位置定位，历史或设备方向等。Lungojs是一个模块化并且完全可定制的框架。

18、xuijs

有时候你可能需要一个超轻量级的框架，只要拥有用于开发标准客户端所需要的功能如：DOM操作，事件处理，Ajax和一些动画效果。如果是这样的话，这个框架刚好非常适合你。整个框架采用GZIP压缩完之后只有42KB。

19、EmbedJS

EmbedJS是一个用于嵌入式设备的JavaScript框架如：移动电话，TVs、tablets和soforth。EmbedJS强大之处在于，它拥有专门为特定平台和浏览器如iOS,Firefox,Android等提供相应的开发版本。这样就能够以最少的代码，为用户提供最佳的体验。而且假如你喜欢自己定制，可以利用其提供的EmbedJSBuildtool工具实现。EmbedJS基于Dojo实现，所以你如果熟悉DojoAPI语法，那EmbedJS将是你最佳的选择。

20、zeptojs

zeptojs是一个专为mobileWebKit浏览器(如：Safari和Chrome)而开发的一个JavaScript框架。它标榜自己在其简约的开发理念，能够帮助开发人员简单、快速地完成开发交付任务。更重要的是这个JS框架，是超轻量级的，只有5KB。zeptojs的语法借鉴并且兼容jQuery。

21、Baker

Baker是用来在iPad或者iPhone平台上发布交互式的电子书或者电子杂志的HTML5电子书框架。

22、-UI

-UI是一个手机移动Web开发框架，采用HTML5,WAML,CSS和JavaScript等技术实现。基于JavaScript框架，包含最新的ChUIJS和ChUIcss

23、MagazineGrid

MagazineGrid是一个超现代的CSS框架，用于iPad和iPhone手机，使用类似杂志的设计风格。MagazineGrid可让用户使用HTML5元素来组织杂志页，非常轻量级(

24、KendoUI

KendoUI是一个强大的框架用于快速HTML5UI开发。基于最新的HTML5、CSS3和JavaScript标准。KendoUI包含了开发现代JavaScript开发所需要的所有一切，包括：强大的数据源，通用的拖拉(Drag-and-Drop)功能，模板，和UI控件。

25、HTMLAppHostFramework

这是一个用于构建基于WindowsPhone7的HTML/JavaScript托管框架，使用HTML5技术。该框架由支持在标准xap格式中嵌入html应用的控件。

手机APP软件开发该如何做？

1、了解自己的APP软件开发需求是什么

2、知道自己开发的系统是安卓还是ios

3、开发语言是什么

4、下载开发环境，比如ios就需要下载专门的开发环境

5、硬件环境，最好是用苹果的电脑，这样开发ios就比较顺手

6、要有灵活的大脑，根据不同的需求，想出好的算法，才能做好APP软件开发

7、可以请一些专业的手机APP软件开发团队帮忙开发，也可以找 一些专业的移动APP软件开发公司合作开发

手机app软件开发步骤是什么？

1、整理手机app软件开发需求；

2、把app软件开发需求整理成文档，提交给app开发团队，如酷蜂科技；

3、功能需求确定，然后开始app软件的原型策划以及UI界面策划；

4、原型图及UI界面策划完毕，开始程序开发；

5、程序开发完成，测试；

6、测试完成，然后提交。

如何选择APP软件开发公司？

1、要注重核心竞争力

一个好的企业核心竞争力在于，APP所有的制作流程都可以独立完成，不需外包，这样APP制作所花费的时间能够缩短，并且安全性和兼容性方面能够得到更好的体现。

2、要有品牌案例

选择APP软件开发公司，要看看这个公司是否之前有成功的案例，了解企业的口碑，这样对企业的判断就能够准确些了。

3、服务优质

选择APP软件开发公司最关键的还是看服务，能够创造性满足企业的各种需求。

将一个单体应用拆分成一组微小的服务组件，每个微小的服务组件运行在自己的进程上，组件之间通过如RESTful API这样的轻量级机制进行交互，这些服务以业务能力为核心，用自动化部署机制独立部署，另外，这些服务可以用不同的语言进行研发，用不同技术来存储数据 。

通过以上的定义描述，我们可以基本确定给出微服务的节特征：

用微服务来进行实践到生产项目中，首先要考虑一些问题。比如下图的微服务业务架构：

在上图图表展示的架构图中，我们假设将业务商户服务A、订单服务B和产品服务C分别拆分为一个微服务应用，单独进行部署。此时，我们面临很多要可能出现的问题要解决，比如：

1、客户端如何访问这些服务？

2、每个服务之间如何进行通信？

3、多个微服务，应如何实现？

4、如果服务出现异常宕机，该如何解决？

以上这些都是问题，需要一个个解决。

在单体应用开发中，所有的服务都是本地的，前端UI界面，移动端APP程序可以直接访问后端服务器程序。

现在按功能拆分成独立的服务，跑在独立的进程中。如下图所示：

此时，后台有N个服务，前台就需要记住管理N个服务，一个服务 下线 、 更新 、 升级 ，前台和移动端APP就要重新部署或者重新发包，这明显不服务我们拆分的理念。尤其是对当下业务需求的飞速发展，业务的变更是非常频繁的。

除了访问管理出现困难以外，N个小服务的调用也是一个不小的网络开销。另外，一般微服务在系统内部，通常是无状态的，而我们的用户在进行业务操作时，往往是跨业务模块进行操作，且需要是有状态的，在此时的这个系统架构中，也无法解决这个问题。传统的用来解决用户登录信息和权限管理通常有一个统一的地方维护管理（OAuth），我们称之为授权管理。

基于以上列出的问题，我们采用一种叫做网关（英文为API Gateway）的技术方案来解决这些问题，网关的作用主要包括：

网关(API Gateway)可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Nodejs的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为 单点故障 点或者性能的瓶颈。

最终，添加了网关(API Gateway)的业务架构图变更为如下所示：

所有的微服务都是独立部署，运行在自己的进程容器中，所以微服务与微服务之间的通信就是IPC（Inter Process Communication），翻译为进程间通信。进程间通信的方案已经比较成熟了，现在最常见的有两大类： 同步调用、异步消息调用 。

同步调用

同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。同步调用的有两种实现方式：分别是 REST 和 RPC

基于REST和RPC的特点，我们通常采用的原则为： 向系统外部暴露采用REST，向系统内部暴露调用采用RPC方式。

异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。需要付出的代价是一致性的减弱，需要接受数据 最终一致性 ，所谓的最终一致性就是只可能不会立刻同步完成，会有延时，但是最终会完成数据同步；还有就是后台服务一般要实现 幂等性 ，因为消息发送由于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）。最后就是必须引入一个独立的 Broker，作为中间代理池。

常见的异步消息调用的框架有：Kafaka、Notify、MessageQueue。

最终，大部分的服务间的调用架构实现如下所示：

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。这就出现了新的问题：

这就是服务的发现、识别与管理问题。解决多服务之间的识别，发现的问题一般是通过注册的方式来进行。

具体来说：当服务上线时，服务提供者将自己的服务注册信息注册到某个专门的框架中，并通过心跳维持长链接，实时更新链接信息。服务调用者通过服务管理框架进行寻址，根据特定的算法，找到对应的服务，或者将服务的注册信息缓存到本地，这样提高性能。当服务下线时，服务管理框架会发送服务下线的通知给其他服务。

常见的服务管理框架有：Zookeeper等框架。

如上的问题解决方案有两种具体的实现，分别是： 基于客户端的服务注册与发现 、 基于服务端的服务注册与发现 。

优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持。

优点是所有服务对于前台调用方透明，一般小公司在云服务上部署的应用采用的比较多。

前面提到，单体应用开发中一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。

因此，当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多，比如说：

端游、手游服务端常用的架构是什么样的？

类型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人以内，因此可以获得更为实时的游戏体验，让玩家玩的更加爽快。

说了那么多的游戏服务器类型，其实也差不多了，剩下的类型大家拼凑一下其实也就是这个样子而已。