一款SNS战略休闲游戏开发笔记01——分布式系统逻辑架构设计

　　近来参加一个休闲SNS游戏的开发，现在刚完成了内部DEMO版，DEMO主要任务是对一种全新游戏玩法的尝试及一些客户端技术的测试。既然DEMO版成功出世，自己就要更进一步了，呵呵。

　　由于这款游戏是一款即时在线游戏，用户操作较频繁，对服务器响应的要求较高，因此在"升级"DEMO版开发前，我认真的考虑了一下服务器端的逻辑架构。为了进一步理清思想，向博友们致敬特此笔记。

　　对于博客园，虽以前也偶有"贡献"，但基本上仍是个"纯获取者"。但这次下定决心鼓起勇气将这个游戏开发的每个阶段都认真作好"开发日志"，请大家监督。

 

　　声明：

1、为了维护公司利益，本文只谈一些技术不会提及任何游戏逻辑和规则，大家就将它想成一挥版《开心农场》吧(它是即时战略类的)，请大家见谅！
2、本文里的所有“服务器”一词是逻辑概念，与一个进程等同。

 

游戏基本需求	相应开发需求	解决方法/方案
能与SNS集成	客户端只能用web技术	采用FLASH+html+js
不分区分服，是一个似开心农场地的“大世界”	服务器端必须能Scale Out 及Scale Up，以便方便的通过增加机器来提高承载	分层、分布式架构,
多人即时战略游戏(在线星际)	服务器端必须响应速度很高、稳定性高 对数据存储量的需求不是很大，只需要记录用户资料，战斗结果、道具等	采用好的网络IO模型并采用优化的战斗服务（器）。

 

　　鉴于以上的如此有挑战的需求，我感到压力的同时更多的是兴奋！我一直对分布式开发感兴趣，而也做过一些试验性的开发，但是还没有成功的商业运营项目经验，作为一个技术，还有什么比这更感令人兴奋的？我甚至联想到了《开心农场》的服务器群。。。呵呵先给自己的一个目标！

　　在重新研究自己写的试验项目，以及参考了无数大牛们的经验之谈后，我正式开始规划了。。。下面正式进入《笔记》主题。

 

我设计的玩家玩游戏的流程是：

1、在SNS网站上登录；
2、连接到登录服务器，登录游戏；
3、连接到游戏服务器；
4、在与游戏服务器上确定开始即时战斗机后连接上战斗服务器；
5、战斗结束再进行第4步或回到第3步。

 

现在我们的服务器架构包括以下几个组成部分（Service）

	服务,组件	功能	线程模型	状态	端口	特别要求
1	Web Server (Web)	A.游戏界面承载 B.资源文件 *根据负载数据选择一个登录服务器	多线程＋心跳	有	80	流量大
2	Login Service (LS)	A.对用户进行登录验证 B.新用户创建用户角色 C.根据负载分配算法选择空闲游戏服 务器返回客户端，客户端连接上此游戏服务器 D.其它功能	多线程＋心跳	有	12012 12022	逻辑简单，连接建 立销毁频繁
3	Game Service (GS)	A.非战斗过程的所有逻辑 B.开始战争	多线程＋心跳	有	12013 12023	IO流量大
4	War Service (WS)	A.战斗数据处理 B.战斗数据保存	多线程＋心跳	有	12014 12024	数据报小但收发 频率，要求高响应
5	IM Service (IS)	A.聊天服务 B.系统消息广播 C.游戏数据广播(将GS的一些需要广 播的操作调用这个功能)	多线程＋心跳	有	12015 12025	--
6	Slave Proc (SP)	A.启动/重启、中止 MS 要求的服务 B.更新服务程序	单线程＋心跳	有	12011 12021	自启动
7	Master Service (MS)	A.Manager Slave,包括启动各个 服务（器），监控各个服务的状态，需 要实现心跳协议 B.Console,提供对各个服务器操作的命 令接口 C.Name Service D.Status Query,状态查询，对各服务 进行集中查询、logging采用http 的 REST方式 E.负载均衡策略实现，并为所有服务提 供负载查询及分配。	多线程＋心跳接收	有	12010 12020	自启动
8	Session Servers (SS)	A.作为各服务（器）之间数据共享及交互		有	12016	用Memcached +Key-value DB 实现
9	Cache Servers (CS)			有	12017	用Memcached服 务器即可
10	Database Servers					主要用MySql，以后 可与NOSQL数据结合应用
*SP是除了MS外每台服务器上都必须执行的调度进程 *1201X 端口为各位服务的端口 *1202X 端口为stats端口,每个服务都提供状态服务，且以HTTP+REST的形式提供查询接口

 

 

心跳协议的设计

1、几乎所有服务都要定期向MS发送心跳，而服务器也要定时检查各服务的心跳状态。

 

2、心跳消息的内容
Ａ.发送方的时间，防止消息堆积导致假心跳
B.服务的启动时间，及当前负载情况

3、心跳的检查
A.S的心跳发送间隔为T，C的检查间隔为T
B.如果最近的心跳消息的发送时间早于NOW-2T，S失效
C.T的选择要容忍网络延时和机器时差，以及时间跳变

4、关键点
A.要在工作线程发送，不要单独起一个"心跳线程"
B.与业务消息用同一个连接，不要单独用"心跳连接"

具体开发设计的要求

1、将整个框架标准化，即形成一个可重用的分布式开发框架，方便的其他项目的开发，或许还可以开源，“创福”社会，呵呵

2、要基于开源技术、开源平台

3、所有多线程服务服务器的开发模型：event loop per thread +NON-BLOCKING IO 

4、贯彻“design for failure” 和"failover"

5、Slave 要能重连MS，且能随机器自动重启

6、强调Name Servie 的应用，所有配置文件里对服务器的配置采用service_name

7、对一个Service里各种处理逻辑的执行频度、执行时间等进行分析并分类，尽可能对不同种类的逻辑采用不同的线程，以提高响应性能

 

架构规划就这样了，接下来就要进行程序设计了。最后联附上用手写板画的草图（要敢于接受新事务，^_^）