这次从传统行业转到游戏行业，是一件值得回味的事。公司不是好公司，但代码是无罪的，学习了不少东西。这些东西也就是前人的思想总结，总算是理解了网络上一些文章说的架构。
之前看了不少游戏架构，最后还是看了具体的代码才有了真正的体会。也算是明确了今后大致的学习方向。
以下是这一个半月里对框架方面的总结，一个是系统框架，另一个是应用框架。 系统框架公司源码保密，目前就分析到的进程信息，正在自己写代码实现这个系统框架。
应用框架更多的是得到关于功能划分上的思想，分而治之，增加灵活性和吞吐量。
之前在华腾没有这方面的划分，可能是模块划分太大了，一个模拟一个功能，几乎就一个进程。
下面是较简单的总结
一 系统框架
服务端基于两个服务模型，一个同异步，一个是同步。异步的连接是双向的，要与客户端的请求交互，还要将请求送往后端的同步服务。同步的连接只面向异步服务的请求，同步端多半只与缓存系统及数据库交互，将结果返回给异步服务。
其中服务端架构层之间的通信只通过socket，目前看来是基于tcp的,并且都是长连接。
总的架构图如下：
架构服务提供几个接口函数，让你去实现，将你实现的接口打包成动态库，程序启动会读取动态库，当有请求上来时会将请求交付给你实现的接口逻辑代码。
1 异步的进程分为work进程， main进程
Work进程是逻辑代码的核心
main进程负责对外的网络连接
2 同步的进程分为work进程，network进程，main进程
Work进程是逻辑代码的核心
Network进程负责通讯
main进程负责监控进程状态，若有子进程退出则重新生成该子进程
进程与进程之间的通讯通过FIFO通讯。
服务与服务之间通过socket通讯。
说完系统框架再说服务的应用架构。
二 应用框架
服务器的服务按大的功能分为登录服务，账户服务，充值服务，游戏逻辑服务，缓存服务，排行榜服务（redis）。总的架构图如下
图中只是大致示意，箭头不要太过于较真。看起来乱，真实情况也是这样。代码也不是老板自己的，不知道是不是后期把功能补全过程中跑出了应用框架的设计计划。
游戏流程
1 手机游戏客户端向登录服务器（通过dns获取ip）发起登录请求，只说账户登录，其它登录差不多。登录服务器网关透传请求到登录服务前置（配置1对N方式），登录服务前置转换协议，增加一些信息，将请求上送登录服务proxy，登录proxy根据请求类型，决定分发给指定服务。后面的账户验证相关的就不讨论了，无外乎是渠道密钥验证，账户验证，密码验证。
2 若具体的账户服务验证通过，则应答给登录服务proxy，登录proxy再申请本次登录session给客户端。申请成功再原路返回。
3 客户接收到session后，向登录服务器请求分配游戏逻辑服务器。登录服务器将请求转发给中心服务，中心服务器上有所有游戏逻辑服务器的注册信息。中心服务器根据客户请求游戏逻辑服务器类型及网络信息分配相应游戏逻辑服务器域名给客户端。
4 客户端按游戏逻辑服务器域名向游戏逻辑服务器发起登录，若验证成功，则返回现在服务器端的游戏信息。如房间信息
5 开始具体的游戏请求，比如，进入指定房间，发射子弹，切换炮台，查看排行榜。。。
三 系统框架简评
这里不说什么，等我的实现完成了再说。
四 应用框架简评
就我的体会，有些功能分的过于细了，导致进程间的交互过多。问过老板，说以前打算做成soa模式。但我觉得soa的下一步对上一步的依赖性没多少，但这个系统中，依赖过多，下一步失败还会发起对上一步的逆操作。也就是说当流程中的服务点大于2时，程序几乎没有操作性，复杂度太大。由于不敢把状态分的过多，又因为历史原因，让一个请求功能经过了太多次交互。这可能也是登录服务器承载量2000不到就卡的原因之一.
