架构的定位
架构是根据具体产品所量身定制的,即使同一个产品不同需求可能架构都不同,这里的建议只是根据游戏行业特性,进行简单归纳 我们普遍遇到游戏行业的特性,大概有这么几点比较雷同。
- 随时开服,一天多服
- 疯狂灌人,配置逐步增大
- 业务收尾,多服合并
- 快速回滚,时间点或局部恢复
架构梳理
满足高并发,高可用性,高扩展性
-
如何提升系统的并发能力 互联网分布式架构设计,提高系统并发能力的方式,方法论上主要有两种:垂直扩展(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环将改变,功能进程无法命中
- 一些基于服务器均衡分布的进程,会形成差异,需确保节点均衡
- 如果构建分布式缓存,和分布式计算需考虑变化对其影响
- 数据库扩容
- 数据需要从新分布,分布造成的影响考虑,分布完成数据验证,分布过程保障。
- 容灾考虑
- 一台机器挂了(此时可能造成雪崩效应)
- 同步过程中的并行问题
- 拉取扩容期间数据可能再次发生变化
- 转换入口的时候还可能发生变化
- 过程中断
- 迭代遍历过程
- 事务处理过程