手把手教你实现服务高可用性

        服务高可用性（High Availability, HA）是指在正常工作条件下以及发生故障时，服务仍能持续稳定地提供预期功能的能力。为了实现服务的高可用性，通常需要采取一系列技术和策略，确保服务在面对硬件故障、网络问题、软件错误等各种异常情况时，依然能够对外提供服务或快速恢复正常。

         务可用性指标

        服务的可用性通常用多少个9的指标来衡量，如下图所示，通常9越多代表可用性越高。

        相信大家在工作中或多或少的都接触过服务可用性，下面就来接单介绍下服务可用性的一般策略，帮助大家在平时工作中提高服务可用性。

        服务可用性策略

        负载均衡

        平时工作中肯定都用过负载均衡组件，最简单的 Nginx 中就使用了负载均衡，将请求分发到不同的机器上，避免大量请求请求到某几台机器，最后出现压垮机器的情况。

        冗余设计

        这一点也很关键，通常一个部署上线后部署在生产环境都会有很多机器，这样可以极大的提高服务可用性，某几台机器宕机了也不会影响整个服务。

        其实好多开源组件都有冗余设计，比如Kafka、TiDB、MongoDB等组件中都存在冗余设计的影子。

        健康检查和故障转移

        服务的健康性至关重要，健康的服务才能对外提供服务，可以通过健康检查对服务的健康性进行评估，比如 SpringBoot 中 /actuator/health 接口来对服务的健康性进行检查，如果健康检查未通过，要及时将不健康的机器下线或者重启后再重新上线。

        同样在好多开源组件中也存在类似的健康检查，或者成为心跳检查。比如 Kafka 中分区的副本有 leader 节点，要 follower 节点保持心跳，如果主节点挂掉要进行重新选主。在 TiDB 的Region 中也存在着同样的操作。心跳检查的案例不胜枚举。

        无状态设计

        微服务中每个服务都要是无状态的，这样能对服务进行快读的扩展，以应对突发情况。

        限流熔断降级

        要对服务进行保护，否者一旦一个服务出现问题，很可能会引起所有的服务出现问题，进而出现服务雪崩效应。

        比如 A 服务请求 B 服务，B 服务请求 C 服务，由于 C 服务中有慢 SQL，如果流量特别大，这就导致服务 C 的响应不能快速响应给 B，B 服务中的慢请求越来越多，进而拖垮了 B 服务，同样的道理，最终A服务也无法幸免。

        所以我们要讲问题限定在可控范围内，要对服务进行限流或者熔断降级，以达到保护服务，提高可用性的目的。

        数据备份与恢复

        数据对于一个企业的重要性不言而喻，如果数据丢失这是无法容忍的，所以要对数据进行备份冗余保存，以达到保护数据的目的。比如很多设计都是主从设计或者灾备。通过这种方式来避免数据丢失，及时丢失了也能从备份的地方还原回去。

        混合云部署

        如果公司条件允许，要尽量选择混合云部署，比如同时使用腾讯云和阿里云部署服务，他们中的一方出现问题，还可以有备份的云提供支持。不要简单的认为提供云服务的大公司就不会出现问题，其实谁都无法避免问题，所以要尽量提高自身抗风险能力。

        监控告警

        监控和告警非常重要，能让你提前发现，规避一些问题。比如CPU增高了、内存磁盘不够了、慢SQL产生了等等，这些预警要引起重视，因为很可能服务出现了问题，如果听之任之，那服务的不可用说不定马上就会出现。

        弹性伸缩

        业务在运行过程中难免会遇到突发流量，比如热点事件发生了，而且还很突然，那这是社交新闻的服务压力可能会增大，服务要能快速的自动进行扩容，以应对突发量量，通过增加机器来保证服务的可用性，负责可能出现因为大量的访问压垮服务。

        另外，如果服务中有大量的计算任务，这时可以采用云函数部署，来动态调配资源。

        服务隔离

        服务的隔离经常容易被忽略，比如将两个服务部署在了一台机器上，那某一个服务可能因为占用资源过多，从而导致另一个服务不可用。尤其是公司的核心服务，所以要尽可能的单独部署，将服务进行隔离，以提高服务的可用性。

        可灰度、可回滚

        通常如果是C端服务，要做好灰度策略，比如按设备灰度、按地域灰度等等，通过少量灰度来验证新功能是否有问题。另外服务要你能进行回滚，如果新功能出现问题，短时间无法解决，要快速回滚，避免对公司业务造成影响。

        通常公司内部会有预发布环境进行新功能的验证，这也是一个非常关键的步骤。

        资源预留

        任何业务都不可能准确估计出资源的消耗量，比如需要多大的数据库、需要多少台机器等，所以要尽量预留出一部分资源，来提高服务可用性。

        其实高可用的设计在平时随处可见，比如下面的例子：

1. Nacos 中可以设置服务的阈值，阈值指的是可用服务比总服务数，如果小于设置的阈值的话，不可用的服务就不会被踢出，以此来保证可用性
2. MongoDB 中设计的副本集，将数据进行冗余保存
3. TiDB 中 Region 的 Raft group 设计，增加副本的同时有主节点来维持正常的业务
4. Redis 中的数据持久化也是为了提高数据可用性
5. TiDB 中的灾备集群可以避免数据丢失
6. MySQL 主从库的设计，通过从库来分担压力和避免数据丢失 等等

        总之，平时要认证观察和总结，要借鉴开源组件的优秀设计，说不定就可以应用到自己的业务中。

往期经典推荐

微服务拆分：打造高性能、高扩展的未来架构-CSDN博客

全面解读MongoDB高可用、高性能与高可扩展架构-CSDN博客

深入浅出 TiDB MVCC：揭秘分布式数据库中的多版本并发控制-CSDN博客

SpringBoot开箱即用魔法：深度解析与实践自定义Starter-CSDN博客

Kafka消息流转的挑战与对策：消息丢失与重复消费问题_kafka发送消息生产者关闭了-CSDN博客

Redis缓存危机大揭秘：雪崩、击穿与穿透——从理论到实战防御策略_雪崩穿透-CSDN博客