【知识整理】一文理解系统服务高可用
一、如何理解高可用
1、什么是高可用
高可用性（英语： High Availability，缩写为 HA），指系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。
2、决定可用性的两大因素
谈可用性不需要绕来绕去，只谈 SLA 即可：SLA（Service-Level Agreement），服务等级协议，用于评估服务可用性等级。计算公式是 MTBF/(MTBF+MTTR)
2个9和3个9是可以靠技术完善和运气达到。但是从3个9往上，就基本超出了人力的范畴，考验的是业务的自愈能力，架构的容灾、容错设计，灾备系统的完善等等。
MTBF（Mean Time Between Failure），系统可用时长
MTTR（Mean Time To Repair），系统从故障后到恢复正常所耗费的时间
一个服务的可用度，取决于 MTBF 和 MTTR 这两个因子，要么提高 MTBF, 要么降低 MTTR。
3、构建高可用系统，面临哪些难题
不过，打造高可用系统，这个话题还是相对来说比较虚的。高可用构建不是一个点，而是所有点组合的一个结果。不像技术案例具体可实现，高可用更抽象，需要有足够的技术视野，需要能够观测并提前做好布局。即便如此，在构建稳定性时，还是会遇到很多难题。
难题一：业务变化之快
对于一个业务来说，不同阶段业务目标是不同的，对系统的要求也是如此：业务初期的要求迭代效率，业务中期的要求是业务起量，业务长期的要求是高可用（稳定性）。需要注意的是，面对业务的快速发展及不确定性，想要提升系统稳定性，需要贴合业务的节奏，对于影响稳定性高严重性、高可能性的风险进行风险管控处理。
难题二：构建范围之广
稳定性建设需要从全局视⻆总览，建设范围广，工作量大，其中包括研发、测试、运维、DBA等多个⻆色，流程规范，变更管理，涉及架构设计、数据库、缓存、消息队列、基础架构等。
例如：我们可能针对某个核心关键流程进行优化、容错、解耦设计，这个改动可能涉及系统层面从上到下的多处修改，包括数据结构调整、业务逻辑改造、数据交互方式等，涉及诸多方面，很可能有遗漏或bug，导致严重的事故，需要有逐一确认某个细节及强有力的测试才可以。
难题三：实施成本之高
稳定性建设是需要投入一定的成本，带来的收益也是隐形的，不像业务目标那么明显。一般情况下，业务上不会给技术做稳定性建设的，除非是业务已取得一定的收益，业务模型已形成闭环，此刻业务为了走的更远，打稳地基，允许投入一定的成本做稳定性建设。不过技术债，还是要尽早还，因为前期的成本要小很多。比如，服务依赖不合理，前期调整比后期调整的成本就要小的多。
4、影响稳定性因素有哪些
影响稳定性的因素有很多，比如业务代码、配置信息、基础设施、断电等，为了便于我们理解和记忆，我这里对影响稳定性的因素进行抽象的总结，分为：人为因素、自然因素两大类。
二、高可用性的方案高
可用分为4个步骤：预防、发现、恢复、复盘。
1、预防
通过良好的设计+规范+自动故障转移来实现。
架构设计原则
研发规范
设计阶段：遵循架构设计原则、技术设计文档
编码阶段：代码规范、工程结构规范、单元测试覆盖率和通过率、日志规范、CR规范、安全规范、高质量的代码发布阶段：变更三板斧（可灰度、可回滚、可观测）
故障转移
限流
限流是指对服务的并发访问量进行限制，设置单位时间内的并发数，超出限制的请求拒绝并fallback，防止后台服务被冲垮。（限流算法：计数器、滑动窗口基数、漏斗、令牌桶），集群限流、单机限流、如何做动态限流
降级
降级，是指牺牲非核心的业务功能，保证核心功能的稳定运行。简单来说，要实现优雅的业务降级，需要将功能实现拆分到相对独立的不同代码单元，分优先级进行隔离。在后台通过开关控制，降级部分非核心的业务功能，减轻系统依赖和性能损耗，从而提升集群的整体吞吐率。
开关降级：一是自动开关，这种降级方式要设立好降级预案，采集各类降级指标，包括业务指标和系统运行环境指标（例如：CPU、内存、某个支付通道的成功率等）；
二是手工开关，这类降级要做的是设立好精准的告警。
读服务降级：出问题后一个接口返回（空、只读缓存、缺省、备份数据、其它服务等），前提是业务上可以容忍这类降级。
写服务降级：写服务大多数场景比较难做降级。可以控制写流量、写数据库改写成MQ或者缓存之类。
系统降级：业务中非核心的系统，流量大后可以关掉此类系统，将最好的资源留给最核心的服务。
功能开关：打开和关闭某些功能，比如消息量过大，系统处理不了，把开关打开后直接丢弃消息不处理。上线新功能增加开关，如果有问题关闭新功能。运行时动态调整日志级别，调试时打开对应开关动态调整输出级别。
熔断
当服务异常或者大量延时，满足熔断条件时服务调用方会主动启动熔断，过载保护，自我嗅探，进行流量恢复。防止因为故障、超时、重试导致故障被多重放大。
容错
FailXXX
容错的设计有个基本原则，就是面向失败设计“Design for Failure”。为了避免出现“千里之堤溃于蚁穴”这种情况，在设计上需要考虑到各种边界场景和对于服务间调用出现的异常或延迟情况，同时在架构设计和开发时也要考虑周到，这一切都是为了达到以下目标：
一个依赖服务的故障不会严᯿破坏用户的体验。
当出现下游调用失败时，我们一般有几种处理方式：
1. failretry，即失败重试，需要配合退避时间，否则马上重试不一定会有效果。失败重试能够提高成功率，但是也会造成响应时间变慢，服务提供方压力倍增。具体要不要重试要根据具体情况决定：对响应时间有要求吗？接口失败率如何？重试会不会造成雪崩？当调用外部服务异常时可以设置重试策略，每次重试时间递增，但是需要设置最大重试次数和重试开关，避免对下游系统产生影响。请求对外接口的时候，需要设置合理的超时时间，避免外部接口挂掉时，阻塞整个系统。
2. failover，即所谓的故障转移。比如调用下游a接口失败，那么RPC的负载均衡器将会调用a接口提供方的其他机器进行重试；在比如数据库x挂了，应用自适应容灾将对x库的调用切换到y库调用，此y库即可以是faillover库（流水型业务），也可以备库（状态型业务）。
3. failsafe，即静默，一般下游链路是弱依赖的时候，可以采用failsafe，即可和failover相结合，比如failover了3次还是失败，那么执行failsafe。
4. failfast，立即报错，failfast主要让工程师快速的感知问题所在，并及时进行人工干预。
5. failback，延迟补偿（回血），一般可以采用消息队列或定时扫描等。
容灾
容灾的定义指在相隔较远的两地（同城或异地）建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处因意外（天灾、人祸、挖掘机事件或者机房断电）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作，侧重数据同步和系统持续可用，通俗的讲是指当灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生产系统的业务不间断地运行，对灾难的容忍能力，容灾的核心思想是基于隔离的冗余。
方案：两地三中心、同城多活、异地多活等。
备份
对重要资源的备份，如系统、应用、数据、静态资源、配置和代码等。
隔离
对系统、业务所占有的资源进行隔离，限制某个业务对资源的占用数量，避免一个业务占用整个系统资源，对其他业务造成影响。
可以分为数据隔离、机器隔离、线程池隔离、进程隔离、模块隔离、业务隔离、机房隔离、在数据库的使用中还经常用到读写分离。
变更管理
变更：代码发布（灰度、可回滚）、DB、配置、网络、基础设施等
未变更管理：服务未续费、证书配置未更新导致过期等
2、发现
监控
监控元数据：CPU、内存、网络、IO、磁盘、负载
分层监控：网络层、接入层、服务层、基础层、中间件层、系统层等
日常监控：Nginx日志、错误日志、业务埋点日志、运行时日志，做监控检查，及早发现请求延迟、异常流ᰁ、错误等。
业务接口和数据监控：1.接口监控对核心的接口请求指标监控等等，2.核心业务数据监控。
报警
告警移动化。通过飞书、企业微信、钉钉移动化工具第一时间通知相关人员。
可视化
效率&稳定性：通过将服务的信息平台化，透明化，能够清楚了解服务的信息，提升业务方调用的效率，能够快速的对服务进行了解；另外能够清楚知道的服务的上下游依赖，业务方或调用方，这样在服务变更前能够及时通知到各个依赖方，并评估变更的影响。
服务治理：服务治理通过对当前服务的信息进行梳理、观测各项指标是否正常，包括服务职责，上下游依赖依赖是否合理，服务信息维护状态等等，防止慢慢的随着时间，逐渐的腐化。
可观测
Metrics（度量）, tracing（跟踪）, and logging（日志）
3、恢复
缩短故障影响时长：增大 MTBF ，减小 MTTR
优先恢复业务进行止损，再排查问题
异常预案（硬件、软件、业务） 值班
可回滚：发布版本失败时可随时快速回退到上一个稳定版本，或者开关回滚
自动恢复、自动扩缩容
4、复盘
复盘会和改进措施：排查根因、由点及面发现问题、制定改进方案计划和实施。
三、总结
人的意识是最重要的，专业能力可以锻炼培养。如果意识不足或松懈，好的能力以及机制流程也会形同虚设。
永远要对敬畏线上，敬畏客户体验。面向线上的稳定性战术上可以基于专业度锻炼后自信，但战略和思想上必须持
续如履薄冰、三省吾身。线上稳定性保障是作为技术人自己专业度的追求，始终保持敬畏。不因为业务繁忙、个人
状态、团队是否重视而有变化，只要职责在，就要守护好。技术主管以及系统负责人要有持续感知稳定性隐患和风
险，保持灵敏度以及系统性的查缺补漏。