实践中高可用如何做

Posted 2022-06-22 18:02 +0800 by ZhangJie ‐ 1 min read

高可用 #

提升服务可用性当然是一件好事，但是实现高可用也是有成本的。提升可用性的常用做法是通过靠设备冗余来实现，当然还有其他的办法，但是不管是哪种办法，做这些工作是有成本的。实践中，一般要权衡投入产出比，来决定需不需要做HA，做的话对哪些服务做HA。

提升可用性的手段 ##

所谓高可用，可以从以下几个方面来考虑：

• 进程内模块的开闭（特性开关）：对异常代码分支进行打开、关闭控制，有问题时可以关闭
• 特定用户的影响：特定用户本地数据问题可能触发某种异常，可以暂时对用户屏蔽特定逻辑
• 子系统级的影响：大系统小做，轻重分离，将关键服务和一般服务拆分开，避免互相影响
• 进程级的影响：多进程模型，避免单个进程挂掉产生影响，常用的共享内存队列+多进程
• 节点级的影响：单个节点挂掉，可以通过冗余、屏蔽故障节点的方式来解决，主备、集群等
• 组件级的影响：对组件的性能边界要有清晰的认识
• 大流量冲击：消息队列削峰
• 地震火灾导致的区域性故障：部署时考虑跨机房、跨区域部署，异地多活
• 等等

有状态、无状态服务 ##

服务也分为有状态服务、无状态服务，对这两种情景的处理方式一般也不同的。

• 无状态服务，一般通过屏蔽故障节点、负载均衡的方式来解决即可；
• 有状态服务，则相对更复杂一些。总而言之节点级的可用性的提升，一般要借助设备冗余来实现，但是对游戏业务而言，这个成本会比较高。而且有些游戏后台服务是有状态服务，对这类服务做HA会明显增加整体方案的复杂度（比如主备方案，或者分片+副本的集群方案），而且设备成本也会增加很多。设备成本过高，还不如让玩家重开一局。

游戏业务的特点和普通的业务可能不太一样，其战斗服务器一般都是有状态服务，所以主流无状态服务采用的HA方案、主备或者集群方案，不一定总适用于游戏场景的，因为考虑到机器挂掉后恢复的收益，这个实现成本、方案复杂度就太高了。

游戏业务中对有状态服务的HA一般这样做，可能会通过：

• 分区分服
• 分set
• 多进程
• 大系统小做+轻重分离
• 特性开关
• 用户数据异常屏蔽
• 等等

通过这些方式的来降低问题影响面，也算是提升可用性的办法吧。