实践中高可用如何做

分享:  

高可用

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

提升可用性的手段

所谓高可用,可以从以下几个方面来考虑:

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

有状态、无状态服务

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

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

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

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

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

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