今天早上读了天美J3工作室服务器主程关于游戏服务器架构的点评，我略有一点体会，总结一下。
文中提到的优先考虑全区全服的模式，我比较赞同，如果一开始设计架构的时候就从这个高度入手，对于整个online团队就充满挑战，想想就很刺激。就算是有分区分服的需求，也可以从在全服上做虚拟分配，这样后面合服就非常方便。想想传统的分区分服的后期运营，每隔几天就合服，各种脚本跑，还不能保证是否有脏数据的情况。
另一个我比较有体会的就是解耦，拆分成多进程，大系统小做。这点从我开始做服务器到现在体会越来越深，如何解耦以及保证优雅的RPC，也就是最近各大厂商炒作中台服务的思想。提高整套系统的容灾能力，加强熔断机制，提高系统的复用性，降低开发成本，这也是online团队一直孜孜不倦追求的目标。
对于解耦，我最近体会较深的是，如何剥离出更多的无状态服务。这些服务除了可以提供二进制的通讯协议，也可以提供REST的服务。比如登陆，匹配，聊天，甚至战斗也是可以的。这样这些无状态服务可以脚本化实现，单元测试也更加方便了。这也就是微服务的思想吧。
说一说online程序员经常遇到的GameServer和CombatServer。GameServer在mmo游戏里扮演的角色比较重要，在其他的moba或是fps的房间类游戏中就没有那么重度。想一想mmo游戏和moba游戏，角色进入场景都携带哪些数据。Mmo中角色的属性，装备属性，其他乱七八糟的中国式属性，这些数据都需要从db中load，而且这些数据要被角色一直携带在各个场景中穿梭，还要被经常update，并被落地到db。而在moba游戏中，角色携带的额外数据可能就是皮肤或是装扮之类的，这些数据被修改的频率是极低的，基本都是付费才能获得。其他的基本数据都是从配置文件中获取。所以mmo的GameServer是有状态的，而房间类的GameServer是无状态的，它甚至可以和Client共用一套代码，它更多的职责在于计算玩家的交互产生的数据，以及结果，所以它可能是CPU密集型。如果Client中有地形计算，碰撞计算的，那共用代码的优势就更加突出了，一份代码，两处运行，省心。mmo的GameServer业务逻辑复杂多变，让它变的简单容易就需要解耦，从它中间拆分出更多的无状态的服务，让瘦身后的GameServer充当转发数据的角色。这样我上面提到的CombatServer是完全可以从中间拆出来的，这样GameServer就变成了Host，CombatServer上都是Host的replication了，只要做好replication的同步就好了。
按照我们的思路进行解耦后，会发现代码清晰了很多，大家之间的分工协作更加轻松愉快了。但同时挑战也来了，就是大量的进程间交互以及数据传输。有几个点需要重视的：
1，在有状态的服务器上，要做好entity的状态迁移，要做到状态不依赖服务器的消息到达顺序，也就要求服务器启动顺序无关，所以消息的缓存以及重传机制也是必然的。
2，有状态服务和无状态服务的load balance算法。
3，容灾机制，要保证节点故障后，迅速切换到备用节点，降低受影响的用户。
4，多节点之间的数据一致性问题，如果出现了不一致，如何做出预警以及数据恢复。
5，自动化运维。
最后谈一谈压力测试以及性能监测。我的经验是至少承受指标120%的压力，同时在正式release的时候，只做80%的负载，这样两头都留有一定的空间，相当于上了双保险。性能监测这块，不说太多，我比较同意文中的不同类型进程搭配部署的想法，这样比较节省资源。也就是说可以把CPU密集型的进程和内存密集型的进程配对的部署在物理机上，这样可以充分发挥机器的性能。
以上。
