《可伸缩架构：面向增长应用的高可用》读书笔记_可伸缩架构:面向增长应用的高可用-CSDN博客

本文链接：https://blog.csdn.net/lzy_lizhiyang/article/details/112671696

可靠性：系统是否具备无差错地执行预期操作的能力。一般指一个系统的质量。
可用性：为了执行这些操作，系统当前可运行的能力。一般指系统在其能力范围内执行任务的能力。
导致低可用性的原因：资源耗尽、预期之外的压力变化、流动行为的增加、外部依赖、技术债务。
提高可用性的措施：
1. 时刻考虑应对故障
  - 设计、依赖、用户
2. 时刻考虑如何伸缩
3. 缓和风险
  - 风险管理
4. 监控可用性
  - 服务器监控、配置变化监控、应用程序性能监控、人为测试、报警
5. 以预测和确定的方式来应对可用性问题
测量可用性：通过技术手段测量服务的可用性，N个9.
提高下降的可用性
1. 测试并跟踪当前的可用性：监控、服务分级、风险模型、风险管理
2. 将手动流程自动化
3. 自动化部署
4. 配置管理
5. 更改实验和高频词的更改：具有回滚能力的自动变更流程；对系统频繁、轻易进行小范围更改的能力
6. 自动化的变更完备性测试
风险管理

确定系统中风险的位置，确定哪些风险必须消除，哪些可以暂时存在，以及如何降低这些存留风险发生的可能性和严重性。
1. 识别风险：列出所有已知风险以及他们的危害性和发生的可能性。
2. 消除最严重的风险：找出列表中最大的风险，制定相应的解决计划。
3. 风险缓和：对于无法解决的主要风险，制定一个缓和计划来降低风险发生的可能性和严重性。
4. 定期检查：定期检查风险模型，确认正确覆盖所有风险，定期调整风险等级。
严重性：如果发生风险，所需付出的代价。可能性：风险发生的几率。
风险模型
1. 风险ID
2. 系统
3. 所有人
4. 风险描述
5. 标识日期
6. 可能性：低、中、高
7. 严重性：低、中、高
8. 风险缓和计划
9. 状态：活跃、已缓和、正在修复、已解决
10. ETA：该风险距离计划解决日志的估计时间
11. 监控：对风险发生的监控步骤
12. 触发计划：风险发生后如何处理
13. 备注
14. 跟踪ID：其他系统中对给风险的跟踪处理
15. 历史：在过去是否已经发生过，时间、频率等。
风险缓和：通过降低风险发生的可能性或者降低风险发生的严重性来降低风险的影响。
风险管理：在解决风险和缓和风险之间做出选择，需要考虑是否能够经济、及时的解决风险，还是仅仅只需要降低风险的影响即可。
恢复计划：如果已知的风险已经发生，如何处理。通过恢复计划建立一系列操作，处理和修复风险所造成的影响和问题。（预案）
1. 触发执行恢复计划的必要前提。
2. 执行恢复计划需要涉及的人员列表。
3. 执行恢复计划的详细步骤，以及由谁来执行哪些步骤。
4. 需要通知的管理人员、上级人员。
5. 问题解决后必要的跟进措施。
容灾计划：一种恢复计划，灾难发生时公司应该采取哪些措施。灾难通常严重性很高、可能性很低。
比赛日：定期测试恢复计划和风险缓和措施。通过测试来触发，观察人员如何响应，并不断更新恢复计划。
构建低风险系统
1. 冗余：控制增加冗余的复杂度，以及世纪钟是否能对风险状况带来可测量的改进效果。
2. 幂等接口示例
3. 独立性：低耦合
4. 安全
5. 简单性
6. 自修复：负载均衡、失败重试等
7. 运维流程：将系统中需要人执行的操作自动化
如何划分服务：
1. 特性的业务需求
2. 清晰和独立的团队所有权
3. 天然隔离的数据
4. 共享的能力/数据
处理服务故障
1. 可预测的响应：上游依赖服务系统技工一个可预测的响应，当遇到无用输入时，不要也返回一个无用输出。即使依赖服务出现故障或者发生不可预测的行为，你也尽可能不要把这种不可预测性传递给依赖于你的服务。
2. 可理解的响应：确保约定的接口能够覆盖所有意料之外的请夸空，包括依赖服务故障的情况。
3. 合理的响应
4. 适当的行为
  1. 优雅降级：在当前服务缺少某个故障服务的结果是，可以通过降低工作量来尽可能完成工作。降级部分功能。
  2. 优雅补偿：即使你无法完全满足用户的需要，但是按照为用户提供价值的方向去改进。返回特定信息而不是报错。
  3. 尽早失败：请求必然失败，就不要再请求了。熔断。
两次失误高度：如果你能够飞行两次失误的高度，你总有一次从失误中恢复的备份方案，即使你正在从一次失误中恢复。
1. 适度冗余（机器冗余、机房冗余、恢复计划）
服务分级：服务的关联标签，表示服务对于业务运行的关键程度，通过比较各个依赖服务的服务级别，可以确定哪些服务依赖对于业务最为敏感，哪些服务略微次之。
1. 问题越严重或者服务越重要，那么就需要越及时、越紧急地响应。
2. 如果你的服务级别高于依赖服务的级别，那这个依赖就是一个关键依赖。如果你的服务级别低于依赖服务的级别，那这个依赖就是一个非关键依赖。
3. 关键依赖出现故障，你的服务应当仍然能够尽力提供服务，因为依赖服务的级别比较低，意味着它无法拥有同当前服务一样的可用性和可靠性。
服务等级协议：提供某种级别可靠性和性能的承诺。（SLA）
1. 应当保证尽可能少的SLA数量。
2. 确保SLA覆盖了服务的所有关键部分。
3. 与服务的消费方一起协商SLA
4. 定义哪些实际中可以实现监控和报警的SLA
容量调整
1. 先按照当前需求去分配容量，等到确认容量需求有变化后再重新分配。
2. 定期调整分配额度。
3. 根据当前资源的使用情况，动态、自动地调整分配容量。