高可用系列一：高可用问题是如何产生的

业务不一定会碰到高性能障碍，但是对于一个企业级应用来说，高可用则是必须考虑的范围。

高可用问题产生的原因多种多样，本文从整个链路出发，分析整个链路中可能产生高可用问题的因素，并在本系列中逐步添加具体的解决方案（最新服务的bug问题，不在本文讨论范围内，上线前应充分测试，自行解决），欢迎留言补充。

从请求的链路出发：前端发起->访问后端服务，访问缓存/数据库/下游服务/第三方服务->返回结果。

一、前端发起

前端发起时，可能的高可用问题主要如下：

原因一：前端页面/版本滞后

对策：

1、缓存策略，尤其是如VUE打包等产生的旧js等资源文件失效，制定缓存策略。一种简单的办法是页面设置no-cache策略，至少保证一次刷新完成最新资源拉取

2、客户端等版本滞后，此时需要考虑接口的向后兼容问题

原因二：网络中断、波动或延迟

除友好提示外，可以添加请求超时、重试机制，如果要支持重试，需要考虑接口的幂等问题，作为高可用应用来说，任一环节的接口幂等都是应该要考虑的。

如因DNS、IP切换等原因引起，可以考虑本地存放多个地址作为后端备选，或设定一个拉取访问地址的端口，实时拉取访问地址。

二、后端服务

后端服务的高可用问题比较复杂，简单可分为基础设施层面、应用本身。

基础设施层面：单设备故障，单设备CPU、内存、磁盘等资源紧缺或磁盘IO过载等

单设备故障常见也不常见，想要宕机不影响，需要采取以下措施：

1、多设备/集群部署：将服务进行多实例部署、并将部署打散到多台设备上。

2、自动伸缩：如果服务需要防止单设备异常并持续高可用，则在单设备故障后，自动伸缩扩展新节点增加实例。

3、其中IO过载可以考虑异步化、随机写转顺序写、数据分片等来提升系统的吞吐率。

以上策略引申出的问题及解决方案：

1、服务状态丢失：如果应用设计时使用本地内存、磁盘存储状态信息，即服务有状态，此时会造成用户请求不同实例得到不同结果，此时应做无状态化改造。

ps：网上有些方案是根据某些逻辑，如根据用户，“锁定”单一服务实例，在此不做讨论。

2、服务健康实例查找：即服务发现问题，无论使用服务注册与发现机制、还是采用负载均衡策略都可能存在异常服务下线期间异常服务被访问到的问题，此时需要超时、重试策略，尽可能在到达可接受的延迟前，路由到可用服务上。此时也可配合熔断机制，减少不可用服务被命中可能，等待健康服务刷新。

3、幂等问题：此时及时响应失败，故障点也不可判断是否在服务执行完成后失效，因此重试需要考虑接口幂等。

应用层面

原因一：应用异常宕机、或垃圾回收等原因假死

多实例/集群部署、超时重试机制

原因二：服务资源耗尽

如数据库等资源池耗尽，需要验证：资源池大小时候合理、资源使用完成后是否正确释放、考虑服务限流。

引申问题：

1、资源池合理分配：避免应用多了，将整个大资源池耗尽，如数据库连接数。

2、服务限流：触发限流后，进行的重试，此时也需要根据具体业务考虑扩展实例、服务资源或是优雅提示，让用户稍后再试

原因三：下游/第三方服务异常

通常方案也是服务熔断、超时与重试机制，必要时应系统告警通知进行人工介入。

其中第三方服务异常因为有不可控性，此时除了正常的下游服务异常应对外，需要额外考虑第三方服务的幂等问题，如果第三方服务无法做到幂等的，需要考虑二次提交前先查实际执行状态、再二次提交的机制。

原因四：下游部分业务失败

超时与重试机制，提交时考虑分布式事务（事务中最容易被忽视，分类在事务中有争议的，投入性价比最高的：最小化相信上游服务的入参，任一入参的有效性和正确性校验与本业务逻辑一致）。

原因五：其他特殊场景

典型的，如第三方限时唯一访问令牌，即限制时间有效、且同时只有一个有效的第三方访问令牌。

最后，如果业务够核心，且更新风险日增，可采用灰度发布机制。

三、中间件高可用

中间件，即第三方框架应用，其实与上诉应用类似，唯一的区别在于不像自己开发的应用，大多数团队做不到“全权掌控”，但从高可用上来说，主要需要避免：

1、故障单点：即服务的多实例部署与服务发现

2、数据单点：数据多副本，多副本的及时性业务考虑

3、故障发现：根据中间件特点，监控服务状态，及时发现故障、和故障恢复（服务、数据、业务）

后续对一些常见中间件的监控指标、故障处理做一些分析。

方案总结

总得来说，我们在实现系统高可用时，目的是为了尽量让用户持续得到正确的结果，实现产品价值。当然从研发团队来说，这一系列措施是增加系统的被信赖关系，同时也很重要的一点是避免让开发人员陷入持续的救火中。

一般需要采取的措施主要如下：

1、系统版本推送与刷新机制、服务地址动态获取

2、超时、重试机制，引申问题：请求幂等、服务发现与负载均衡策略

3、多实例部署，避免单点，引申问题：服务发现、服务状态维护、服务伸缩

4、资源池的合理管理

5、服务熔断、服务限流

6、分布式场景下的分布式事务处理，涉及第三方服务的二次业务验证

7、特殊服务提升吞吐量：异步化、数据分片等

8、特殊场景下的特殊解决方案

9、有效的监控与故障发现、报警、处理机制

如果非得从其中找出核心中的核心（最容易被忽视，且忽视后最容易陷入救火状态的），那么：超时/重试机制、服务幂等、事务（+入参校验）！

本作品的版权所有权归作者所有，受法律保护。未经作者书面许可，任何个人或组织均不得以任何形式使用、复制、修改、传播、展示或在未获得授权的情况下进行商业利用。