版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/gohuge/article/details/79878392
一、服务器设计问题
1、认证问题
集群设计了存储，日志，计算，网关-层，理论上这些层可以随着业务量增长无限扩展。
因此我们在整体框架的设计上，自然不会把认证服独立出来，这个业务可以在网关直接完成；
在实际运营过程中，我们会接入第三方渠道，渠道会要求认证服不能随版本维护而停止运行，必须一直启动并运行着；
在我们框架下如果一个渠道的服务器，需要独立在另一个集群中，我们就要实现充值转发以及最近登录等消息的归并处理。
在一个项目中提出了临时解决方案，我们扩展了一个中控，通过它来做转发；
而我们为此得出的结论是认证服确实不能少（因为之前做端游没有第三方的很多要求，所以认证服独立出来发现多余了）。
它需要包含：账号信息管理，充值，认证。
2、场景问题
在我们的集群框架下，MMORPG的场景应该在网关层，它的推送密集度比策略类场景多太多；
而公司另两款策略和卡牌游戏的大场景因大数据检测较多，通信不密集所以设计在了计算层。
而另一款回合制，采用的是组合模式分线运行，所以场景也在不同线不同的网关节点上。
设计注意：
a、场景必须自己维护场景里的数据，场景推动及AI检测的运算非常密集；
b、场景推动中绝对不能存在同步通信业务，会降低帧率；
c、场景事件要合并压缩后在帧尾推送。
3、结算问题
结算是一个持续过程，有10分钟乃至更长时间运算，业务应当放在计算层。
4、缓存问题
缓存数据有，玩家数据，各大系统，服务器数据，这里越把分层带来的观察性显示得更重要。
通常玩家数据都是跟着会话走自然在网关层，系统数据基本都在计算层也不排除直接在存储层的，
服务器数据便理所当然存储层+全局缓存了；当然还有常规功能，不过也都是网关的瞬时业务没有缓存可言。
二、业务数据分离和融合
我们理想是，存储->计算->网关；自上而下，相同类型节点之间不应该业务串行。
情况一：
数据和业务结合在一起，以服务器为单位，把玩家及该服务器的业务结合到一个节点。
目的，减少跨节点通信，提高运行效率，但如果节点挂了hash环出问题，会造成服务器之间理想的共享环境异常。
情况二：
如果，业务和数据不能在一起，那就要尽量减少高阶访问，唯一的方式就是缓存。
局限功能的跨节点通信，如全局业务就只有大地图和全局定时器的策略游戏《异星帝国》，直接放在计算层，其他就在网关层。
我们产生业务事件无非只有，场景推动产生、玩家行为、活动推动、系统结算。
如同：场景操作玩家数据，玩家数据在数据库和会话进程，都在不同的节点的情况下你该怎么做？
1、服务器hash归并到一个节点，数据访问透明化。
2、业务节点缓存大部分数据，用于系统操作，减少数据跨层访问。