架构的定位
架构是根据具体产品所量身定制的，即使同一个产品不同需求可能架构都不同，这里的建议只是根据游戏行业特性，进行简单归纳 我们普遍遇到游戏行业的特性，大概有这么几点比较雷同。
- 随时开服，一天多服
- 疯狂灌人，配置逐步增大
- 业务收尾，多服合并
- 快速回滚，时间点或局部恢复
架构梳理
满足高并发，高可用性，高扩展性
-
如何提升系统的并发能力 互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。 垂直扩展：提升单机处理能力。垂直扩展的方式又有两种： （1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G； （2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；
-
如何保障高可用性 我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。
保证系统高可用，架构设计的核心准则是：冗余。
有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。
所以，又往往是通过“自动故障转移”来实现系统的高可用。
典型互联网架构中，如何通过冗余+自动故障转移来保证系统的高可用特性。
通常采用业务分层，或者分组管理，常见的互联网分层架构
常见互联网分布式架构：
（1）客户端层：典型调用方是浏览器browser或者手机应用APP
（2）反向代理层：系统入口，反向代理
（3）站点应用层：实现核心应用逻辑，返回html或者json
（4）服务层：如果实现了服务化，就有这一层
（5）数据-缓存层：缓存加速访问存储
（6）数据-数据库层：数据库固化数据存储
整个系统的高可用，又是通过每一层的冗余+自动故障转移来综合实现的。
扩容的方式
扩容的方式有两种，即动态扩容（运行时扩容），静态扩容（停机扩容），停机扩容相对简单，下面说一下动态扩容需要考虑的问题
关于动态扩容的考虑
- 无缝接入
- 定时器，等全局业务，在扩容节点进入后会启动，但需要人工停止， 等待扩容准备工作完成，才能通知启动，比如缓存，功能进程初始化。
- 进程分裂，会话路由也需要考虑扩容节点功能状态正常，方可运行。
- 均衡
- 服务器功能进程，通过hash至其他节点，如果增加机器hash环将改变，功能进程无法命中
- 一些基于服务器均衡分布的进程，会形成差异，需确保节点均衡
- 如果构建分布式缓存，和分布式计算需考虑变化对其影响
- 数据库扩容
- 数据需要从新分布，分布造成的影响考虑，分布完成数据验证，分布过程保障。
- 容灾考虑
- 一台机器挂了（此时可能造成雪崩效应）
- 同步过程中的并行问题
- 拉取扩容期间数据可能再次发生变化
- 转换入口的时候还可能发生变化
- 过程中断
- 迭代遍历过程
- 事务处理过程