备注说明：相关总结属于个人学习笔记，请勿商用，感兴趣的可在极客时间订阅该《乔新亮的CTO成长复盘》专栏学习，谢谢~
高可用设计：“冗余设计”、“故障转移”？
单点架构是高可用的大敌
“冗余设计”：通过集群来替代单点服务，做好冗余备份
“故障转移”：为了缩短故障时间，保证故障发生时，业务可以快速恢复。
常见方案：“CAP 理论”、“异地多活”、“双机架构”
“CAP 理论”：
在一个分布式系统中，最多只能同时满足以下三个特性中的两个：
- C - Consistency（一致性） 所有节点在同一时间内看到的数据是一致的。即，一旦数据被更新，所有后续的读操作都应该返回最新的值。
- A - Availability（可用性） 每个请求都能在有限时间内得到响应，无论请求是成功还是失败（系统始终能响应，但不保证数据是最新的）。
- P - Partition Tolerance（分区容错性） 系统在网络发生分区（即部分节点之间无法通信）的情况下，仍然能继续运行。
- CP 系统：强一致性 + 分区容错，如 ZooKeeper、etcd。
- AP 系统：高可用性 + 分区容错，如 Cassandra、Dynamo。
- CA 系统：强一致性 + 高可用性，但在网络分区时无法保证，因此在分布式系统中几乎不存在 （如单机数据库 MySQL 在单节点下可以认为是 CA）。
异地多活
系统可以在多个地理位置（如不同的城市或数据中心）同时对外提供服务，即使某个地区发生故障，其他地区仍然可以正常运行，保证业务不中断。
- 多活：多个数据中心同时处理请求，而不是主备模式（一个主，一个备）。
- 容灾能力强：即使一个数据中心宕机，其他数据中心仍可继续服务。
- 数据同步挑战大：需要解决跨地域的数据一致性和延迟问题。
双机架构
- 主备模式（Active-Standby）
- 主节点工作，备节点待命。
- 主节点故障时，备节点切换为主节点（手动或自动）。
- 数据通常是实时或准实时同步。
- 主从模式（Master-Slave）
- 主节点负责写操作，从节点负责读操作（读写分离）。
- 数据从主节点复制到从节点。
解剖高可用设计
想做好架构设计，第一步是将一个 IT 系统从应用层级至底层基础设施，
全部拆解为一个个应用模块，我们也可以称之为“元素”或“组件”；
第二步是保证各个模块间不能孤立存在，还要做好充分的协作，协作通过应用模块对外暴露的“服务”来承载，我们也可以称之为“连接”。
应用模块和服务，或者叫做元素和连接，共同组成了所谓的架构。
要实现架构的高可用等于 实现所有元素、连接的高可用。
真正的高可用，是指实现所有元素、所有连接的高可用。
只要一个元素或一个连接没有做高可用设计，都意味着风险的存在。
例子 ：公司要求每天必须按时上班，只要迟到就罚钱
如何保证自己的“出勤系统”是高可用的
闹钟至少有两个——互为主备、
要保证衣物都在、
要为堵车准备预案、
要保证高峰期能挤上电梯
保证身体健康，拉肚子会迟到。
在这个例子里。闹钟可能不响、堵车可能会发生，没问题，只要在老板眼里，你永远按时打卡就行，只要整个系统是高可用的就好。
更准确地说，所谓高可用，是要保证“业务的连续性”，即在用户眼里，业务永远是正常（或基本正常）对外提供服务的。
没有实现高可用的原因：
相关负责人压根儿就没考虑高可用设计；
做全套高可用的代价太大了，钱不够用，时间不够用。
“trade-off”权衡选择
墨菲定律，只要事情有变坏的可能，概率再小也会发生。
高可用方案1 降级服务
在风险爆发、系统出现问题的情况下，对外提供“降级服务”。
例子：电商系统的物流时效产品
该系统需要通知用户已购商品的到达日期。比如，邻近区域当日送达、跨省隔日送达、偏远地区三日送达，等等。具体的物流时效和用户和仓库的距离、仓库作业能力、车辆配送能力很多因素都有关。
因为一个 Bug 或一个配置文件修改错误，导致物流时效产品崩溃了，用户在四级页、购物车，订单确认页调用该服务时失败，怎么办呢？
由服务器端技术人员写一段程序，保证任何用户查询物流情况，都显示 3 天送达。出问题的时候，使用此服务进行替换。然后，全体技术人员努力恢复服务，系统恢复后替换回正常的物流时效服务
高可用和高可靠不是一个概念
在最理想的情况下，我们既保证高可用，也保证高可靠；但出现问题时，我们优先保证高可用，其次保证高可靠。这是另一点关键认知。
比如在流媒体领域，当用户观看直播出现严重卡顿时，很多企业的第一反应不是查服务器 Log，而是为用户自动降码率。因为比起画质降低，卡的看不了显然会让用户更痛苦。
如果“降级服务”还解决不了问题，应该提供“熔断服务”，让出现 Bug 的模块从系统中“熔断”，虽然用户会看到物流系统报错，但整个业务依然是正常响应的，不会被一个系统的 Bug 拖死。
总结：
高可用意味着对系统全部元素、连接都进行高可用设计，在物理实例层面主要表现为冗余和集群设计，在代码逻辑层面，方法则多种多样。当你的资源和精力不足以实现全链路高可用时，提供“降级服务”和“熔断服务”，优先保证高可用，其次保证高可靠。
高可用，不只是个“设计问题”
例子：
底层物理实例问题 ： 机房停电
代码逻辑问题：ZooKeeper 连接数超过阈值就会停止服务
不发布新版本、不修改配置文件、不修改数据库脚本，系统大概率会一直保持正常
高可用设计真正的敌人是“变化”。
研发管理水平的高低，决定了你在版本发布方面的成功率和信心。
发布关心的问题：
- 记录系统的任何一次发布和变化，包括发布系统 / 组件、发布时间等；确保自己可以随时定位任何一个时间段内的任何元素及任何发布动作，包括但不限于代码、配置文件、SQL 脚本、设备参数修改等；
- 发布时不影响业务；
- 保证任何发布都可以回滚。尤其当一个大版本的发布时，能否精确识别回滚单元，并做到秒级回滚。
思考
由代码逻辑导致的系统风险，是如何进入生产环境的？
风险是经由开发环境、SIT 环境、压测环境、PRE 环境，进入生产环境的。所以我们要做的，是严格检查各个环境下的异常，研发管理规范，应该为代码版本进入下一个环境设置准入标准，对于任何异常，都有负责人进行修正。如果异常通过了评估，审核者要对其负责。
生产环境出现严重故障，是不是毫无征兆地发生的？
人在生病前，会在各项生理指标上有所表现。系统 Bug 在导致生产故障前，也往往会有各类异常，我们要做好监控并正式的处理掉它。
真正的、为业务负责的高可用设计，不是画框图就能解决的，它是一个面向 IT 组织的整体设计。高可用设计，意味着“Design For Failure”
