近来参加一个休闲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.游戏界面承载 |
多线程＋心跳 | 有 | 80 | 流量大 |
| 2 | Login Service (LS) |
A.对用户进行登录验证 B.新用户创建用户角色 C.根据负载分配算法选择空闲游戏服 务器返回客户端，客户端连接上此游戏服务器 D.其它功能 |
多线程＋心跳 | 有 |
12012 |
逻辑简单，连接建 立销毁频繁 |
| 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 要求的服务 |
单线程＋心跳 | 有 | 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外每台服务器上都必须执行的调度进程 |
||||||
心跳协议的设计
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里各种处理逻辑的执行频度、执行时间等进行分析并分类，尽可能对不同种类的逻辑采用不同的线程，以提高响应性能
架构规划就这样了，接下来就要进行程序设计了。最后联附上用手写板画的草图（要敢于接受新事务，^_^）
