分布式系统稳定性建设指南-阅读笔记

本文为阅读<分布式系统稳定性建设指南-2022版>后的摘抄
原文: 重磅发布|《信息系统稳定性保障能力建设指南（1.0）》，附下载方式

分布式系统稳定性建设目标

稳定性建设目标

  • 降发生
    • 降低故障发生的概率
    • 方案设计阶段即采用面向失败的理念设计系统架构
    • 高可用
      • 利用冗余设计, 将应用的高可用相关能力转移到为由可靠的基础设施提供
    • 高性能
      • 高性能，通过精简主干业务逻辑，不相干的业务异步化
      • 通过缓存技术，加快数据访问的性能
    • 高质量
      • 高质量设计更多的是一种软件开发最佳实践经验的沉淀。
      • 通过设立开发、运维的规范可有效减少人为故障的发生；
      • 通过合理的拆分理念，如纵向技术分层、横向业务分区的理念，提升系统的可维护性、可演进能力
  • 降影响
    • 降低故障发生后的影响范围
    • 早感知
      • 完善监控告警。通过可视化的监控告警能力，感知系统的异常变化，可以尽早发现甚至预测系统故障。
    • 快定位
      • 系统对故障定位明确，故障管理机制定义完整，职责明确，流程清晰，能有效提升故障发生后的处理效率。
    • 急止损
      • “止血"大于"修复”，故障发生后的第一反应永远是"优先止损"，在完成止损工作之后，再开展故障修复。
      • 而为了有效止损，需要提前设立各种故障预案。
    • 优改进
      • 及时复盘，实现故障闭环。
      • 故障复盘是故障发生后的改进措施，目的是完成系统韧性提升，实现故障闭环。

稳定性评价指标

  • 业务可用程度
    • SLA 有两种计算方式
      • 一种是通过时间维度计算
      • 一种是通过用户请求状态计算
    • SLA 之外，还可以配合使用 RTO、RPO 等指标，监测数据的完整性
      • RTO
        • Recovery Time Objective，复原时间目标
        • 数据中心可容许服务中断的时间长度
        • RTO 具体时间长短只是从故障发生后，从数据中心系统宕机导致应用停顿之刻开始，到数据中心系统恢复至可以支持各部门运作之时，此两点之间的时间段。
        • RTO 是反映数据中心业务恢复的及时性指标，表示业务从中断到恢复正常所需的时间，RTO 数值越小，代表容灾系统的数据恢复能力越强
      • RPO
        • Recovery Point Objective，复原点目标
        • 数据中心能容忍的最大数据丢失量，是指当业务恢复后，恢复得来的数据所对应时间
        • RPO 取决于数据中心数据恢复到怎样的更新程度，这种更新程度可以是上一周的备份数据，也可以是昨天的数据，这和数据备份的频率有关
      • 扩展:
  • 用户影响程度
    • 受影响的用户数量
  • 资产损失程度
    • 故障发生后产生的损失, 分有形资产和无形资产两部分
    • 企业内部应用只考虑有形资产

分布式系统稳定性建设模式

架构设计

影响稳定性的核心架构设计要点

  1. 去除单点
    1. 硬件单点.
      1. 设计确保不存在特定硬件服务器单点, 原则上所有应用服务器不前置依赖物理机
    2. 存储单点
      1. 部署架构上确保不存在特定存储主机单点，如服务依赖的数据库主机是否有单点、存储主机部署架构是否存在单点、存储管控节点是否存在单点。
    3. 网络单点
      1. 明确网络拓扑中是否存在单点，一般情况下网络基础设施应当是全冗余设计。
    4. 机房单点
    5. 基础技术单点
      1. 数据服务软件单点：如缓存、文件系统、搜索等数据服务，需要分析服务是否对上述数据服务软件存在依赖。
      2. 需考虑当上述数据服务软件发生故障时，服务容忍性设计，对于缓存产品防热点设计
    6. 服务注册中心单点
      1. 确认注册中心宕机对于自身应用的影响设计
      2. 原则上建议应用系统启动和运行时可不强依赖于注册中心，应用必须能够忍受注册中心短暂宕机所照成的影响，亦即注册中心需要具备一定恢复重建或心跳维持能力
    7. 数据单点/热点
      1. 数据库单点规避
      2. 热点数据表单点规避
      3. 热点数据记录单点规避
    8. 内部服务单点
      1. 原则上不允许有高等级服务依赖低等级服务
      2. 对于最高优先级服务提供方，必须尽最大可能，将内部业务服务单点个数降到最低，包括提供降级服务能力.
      3. 对于最高优先级服务依赖的组件，必须保证所依赖的组件发生各种类型故障时（包括崩溃型、缓慢型或任意型）不能整体崩溃。
    9. 外部服务访问单点
      1. 外部服务可视为低保障等级服务(除非外部服务有 SLA 保障/不过有 SLA 保障一样可以忽略)
  2. 依赖设计
    1. 关键是判断依赖强弱程度
    2. 最强依赖
      1. 当所依赖的服务不可用时，服务不可用，且造成系统崩溃。对于所有的依赖，不建议最强依赖
    3. 强依赖
      1. 当所依赖的服务不可用时，服务不可用，但系统不会崩溃，且当所依赖的服务恢复后自动恢复。服务只可强依赖于同等级或高等级的服务与资源
    4. 弱依赖
      1. 当所依赖的服务不可用时，服务继续可用，但损失一些次级功能。服务允许弱依赖于低等级的服务与资源
    5. 最弱依赖：当所依赖的服务不可用时，服务继续可用，且无任何功能损失。在成本可控情况下，推荐采用最弱依赖的方式
  3. 灾备设计
    1. 冷备技术
    2. 主备技术
    3. 应用双活/多活
  4. 弹性设计
    1. 故障隔离标准
      1. 系统必须具备防止故障从一个系统/组件传播到另一个系统/组件的能力。故障从一个系统/组件传播到另一个系统/组件通常有以下两种原因
        1. 系统/组件间强依赖
        2. 系统/组件间共享资源
    2. 访问量控制标准
      1. 服务提供者必须给出本服务（包括系统调用服务、页面服务等）的访问策略，包括最大的访问能力、其它访问约束（如参数约束、单账户访问约束等），说明违反服务访问策略的后果
      2. 服务提供者需要对违反服务访问策略的情况，实施管控措施。我们要求所有对外提供服务的系统（如对外服务的网关系统、对外服务的 web 系统等）必须具有防止外部访问过载的能力（即具备限流能力）
      3. 渠道入口系统需要具备能够降级入口服务的能力，确保入口功能服务在出现异常时，在交易链路的最前段截断异常，防止影响扩大
      4. 服务调用方需要对关键交易场景下的非关键服务访问进行容错设计，常用的手段包括（熔断、降级），确保在非关键服务访问出现异常的情况下，迅速切断该服务访问，保证关键交易成功率
      5. 原则上所有控制访问量的手段（如限流、熔断、降级）均应具备实时调整的能力，以保证在异常访问下系统的动态性能余量充足
    3. 服务降级、限流与熔断
      1. 服务限流
        1. 当请求量超过 2000tps 后随机或选择性抛弃一些请求
  5. 容错设计
    1. 服务不可用容错设计
      1. 跨系统服务调用，调用端必须保障请求准确送达、服务端必须保障响应准确返回. 如不可用, 应有容错机制
    2. 关键应用的容错设计
    3. 数据库容错设计

容量设计

  1. 数据增长预测
    1. 数据库访问量
    2. 数据库数据增长量
    3. 数据库连接数
    4. 其他数据服务访问量与数据增长量
      1. 除数据库之外的其他数据服务访问（如缓存、搜索等），可参考数据库访问量与数据增长量的评估方式进行评估，确保数据服务的访问量与数据增长量在可承受范围内
  2. 网络流量
    1. 内部网络流量、连接数与请求数：
      1. 确保不超过内部网络设备的承载能力。内部网络流量、连接数与请求数需要包含交换机、负载均衡设备、SSL 设备、防火墙、专线等。内部网络流量计算复杂，推荐两种方式：基于性能测试评测和基于生产服务实际网络流量占比推算。理想情况下可以针对每一个服务的访问量与网络流量之间建立计算公式
    2. 外部网络流量、连接数与请求数
      1. 确保不超过外部网络设备（含外部负载均衡设备、SSL 设备、路由器、交换机、防火墙等）的承载能力
      2. 外部网络流量的直接计算复杂，建议通过全链路压测评测
  3. 消息量(略)
  4. 伸缩性
    1. 复制性伸缩
      1. 应用必须是无状态的，可以通过在集群中添加应用服务器实例，可以接近线性地扩展集群容量
    2. 垂直性伸缩
      1. 应用垂直型伸缩是指按照功能将应用拆分
      2. 数据的垂直型伸缩也是指按照功能对数据拆分
    3. 水平性伸缩
      1. 水平型拆分主要针对数据，是指按照用户或请求的维度对数据进行水平拆分. 行业内水平拆分的技术可以参考 TDDL 等技术
        1. TDDL: Taobao Distributed Data Layer, 主要用于解决分库分表场景下的访问路由（持久层与数据访问层的配合）以及异构数据库之间的数据同步
        2. 类似方案: 美团开源的数据库中间件 Zebra
        3. 围观即可
  5. 链路分析
    1. 同步调用链分析
      1. 过长的同步调用链对性能、容量、可靠性都是极大的风险，整个处理的响应时间是链条中每一环的处理时间之和，链条中的任意一环出现故障或缓慢，都会造成整个处理缓慢或失败，所有的服务访问量会压到同步处理链条中的每一环，且每一环存在大量的线程等待（阻塞线程资源甚至更昂贵的数据库连接资源）。降低同步处理链路长度的通常做法有：控制系统的拆分粒度，优化系统的职责；对于大访问量的处理（每日千万级或以上），可考虑将远程调用固化成本地处理，牺牲一些灵活性换取稳定性与性能；异步化。
    2. 响应时间分析
      1. 响应时间的评估不是一个绝对值，而应该是一个响应时间区间。需要找到瓶颈点进行分析与优化，确保响应时间区间满足客户端的需要
  6. 吞吐量提升
    1. 基础设施优化
    2. 业务流程优化

运维方案设计

变更管控

  1. 新版本发布设计
    1. 停机性发布
    2. 发布顺序是否合理
    3. 发布时间点
      1. 发布时间点需尽量避开业务高峰，尤其是发布过程会对业务产生影响的核心系统. 系统发布因尽量避免影响业务，如确实对业务影响较大又无法在系统设计上避免，需将发布时间点放在绝对业务低峰点
    4. 涉及新旧功能切换
      1. 验证切换方案地合理性，可逆性
      2. 发布过程中涉及到的新旧功能切换方案，应确保可逆，即切换失败后能及时切回到旧功能。方案需在研发环境进行详细测试
      3. 如无法在研发环境进行测试，需在预发布环境进行模拟测试，确保方案正确有效，可回滚。
  2. 灰度变更
    1. 平台建设部分，对于变更及发布过程，可以通过建立多级验证环境并约束变更逐级变更来提前或在在有限影响范围内发现问题
    2. 线下环境
      1. 开发环境、联调环境
    3. 线上环境
      1. 预发布、灰度、仿真、线上等多个环境
      2. 预发布环境用于开发人员进行线上新功能验证
      3. 灰度环境用于引流内部可控用户流量进行持续验证
      4. 仿真环境可针对线上流量复制回放验证
      5. 最后再生效线上真实环境
  3. 变更灰度过程
    1. beta 发布
    2. 蓝绿发布
  4. 数据迁移分析
    1. 涉及重要性高的服务的数据迁移方案必须完整、安全、可实施、可检测、可回滚。
    2. 方案的完整性：是否本次升级内容所必须包含的待迁移数据项全部覆盖到位
    3. 方案的安全性：对于敏感信息如用户隐私信息的迁移方案，是否存在由于迁移脚本的不合理导致隐私信息泄露风险
    4. 方案的可实施性
    5. 方案的可检测性：迁移过程各个阶段的数据完整性、准确性检查脚本是否准备到位
    6. 方案的可回滚性
  5. 可回滚设计
    1. 回滚的必要性
      1. 应用新版本计划应该制定详尽的回滚计划，能够在最短时间内将应用恢复至上一稳定运行版本
      2. 一般情况下应用本身可回滚，而数据层面的可回滚性是重要的考量因素之一
      3. 原则上任何应用服务在发布之前都必须具备可回滚的能力，没有回滚能力的系统不允许发布上线
    2. 回滚的复杂性
      1. 应用回滚
      2. 数据回滚及清理
      3. 运维策略回滚
      4. 监控方案回滚
    3. 回滚操作对业务的影响
      1. 回滚方案中必须明确本次发布窗口所有相关性需求项目，明确一旦发生回滚处理受影响范围，提前告知相关项目组及业务方，同时尽可能降低多个业务关联性较强项目同一发布窗口的回滚风险
  6. 配置变更控制
  7. 复核验证

可观测设计

  1. 分布式系统各服务节点需要具备完善的日志、监控指标、链路追踪等可观测手段，以便准确观测业务系统运行情况并及时定位处理问题
覆盖类型 指标描述
基础设施 操作系统、中间件等运行监控，包括计算、存储、网络资源，如 CPU、load、线程池等
系统服务 链路系统各节点运行情况，便于定位问题节点
应用依赖 系统组件依赖服务，如存储、中间件、第三方依赖
核心组件 应用核心处理逻辑的关键运行数据及报错监控
业务运行 能够直接体现业务运行情况，包括用户体验监控

演练设计

  1. 预案演练
    • 根据单个系统的应急预案，模拟应用系统的一种或多种故障场景，验证系统的可靠性
    1. 预案演练原则
      1. 确保业务能提供连续性服务
      2. 演练范围和风险影响可控
    2. 预案演练目的
      1. 检验预案
      2. 锻炼队伍
      3. 磨合机制
    3. 演练实践
      1. 明确演练场景, 明确要演练的故障场景及影响范围。
      2. 明确风险和应对措施
      3. 明确演练人员
      4. 明确演练技术方案和业务验证方案
        1. 演练前检查与业务验证：
          1. 包含系统检查：检查数据库、负载均衡、应用集群等状态是否正常；
          2. 应用检查：检查服务是否可用、交易量、交易成功率等指标是否正常；
          3. 网络检查：检查负载均衡、集群、数据库间网络环境是否正常；
          4. 业务验证：根据案例进行演练前的业务验证。
      5. 切换阶段
        1. 明确演练切换的各操作步骤，建议通过工具实现作业编排，自动化执行切换操作
      6. 切换后检查与业务验证
      7. 回切前检查
      8. 回切阶段
      9. 回切后检查与验证
    4. 演练实施流程
      1. 演练实施流程即演练切换前后每一步操作指令，一般建议三要素形式明确，主要包含：时间，操作，内容。
      2. 如演练前的操作 => 00:00 关闭负载均衡，阻止交易进入

安全设计

分布式系统稳定性建设路径

"从业务来，到业务去"应当是稳定性保障设计的关键原则，否则再先进的技术也可能只是空中楼阁，脱离实际业务需求

稳定性建设需求分析

  • 确认分析对象主体
    • 一个应用系统，通常以独立的应用系统为分析对象，如聊天软件、交易系统等；
    • 一组应用系统，通常以业务场景为主体关联，如电商订单支付关联系统、微信聊天关联系统；
    • 一个架构域: 略
  • 确定被分析对象的稳定性需求
    • 确定被分析对象提供的所有服务
    • 确定服务的使用场景
    • 每一个服务的重要性等级

稳定性建设实现分析

  1. 服务实现流程分析
    1. 分析明确服务的实现流程，如服务实现的 UML 活动图、UML 序列图或者业务流程图等
  2. 强弱依赖分析
    1. 分析服务实现流程中所依赖的所有应用系统（以及这些系统提供的服务）
    2. 对每一个依赖，需要识别该依赖的以下属性：
      1. 依赖强弱
      2. 同步或异步：同步表示需要等待返回，异步指调用发生后无需等待立即返回
      3. 依赖权重：一次服务过程中依赖的次数，即访问的次数
    3. 针对具体的服务类型，需要针对性地开展依赖分析，如
      1. 数据库依赖
      2. 硬件服务依赖
      3. 基础技术服务依赖
  3. 部署架构分析
    1. 明确系统有哪些部分组成，以及明确系统间的协作关系，如集群划分、集群的大小、集群 IDC 分布、网络拓扑
  4. 访问模式与访问量分析
    1. 可以给出该服务访问量与业务量之间的函数关系。
    2. 这样做的好处是可以方便准确地推算出该服务的访问量与访问模式，简化容量分析与规划

稳定性建设活动

  1. 建设稳定性保障机制
    1. 规范编制
      1. 代码编写规范
      2. 变更规范
      3. 运维操作规范
      4. 日志排查命令及规范
      5. 监控告警制定告警处理流程、告警升级机制
    2. 方案评审机制
    3. 测试准入准出机制
    4. 值班及责任判定机制
      1. 设置值班制度，每天有技术人员负责值班
    5. 能力考核机制
    6. 故障管理机制
      1. 故障管理机制包括规范管理故障响应流程、故障升级机制、故障复盘机制，
      2. 规范技术人员在应对突发故障时的操作流程，明确职责边界，提升沟通效率，推动故障闭环，提升故障处理效率。
  2. 建设组织保障能力(略)
  3. 建设稳定性保障体系
    1. 稳定性度量模型

稳定性建设工具

  1. 故障预防工具
    1. 可观测能力
      1. 系统运行情况采集
      2. 故障发现
      3. 故障辅助定位分析
    2. 系统运行情况采集
      1. 数据完备程度
        1. 可观测性数据形式上可分为三大类，日志、监控指标、分布式追踪
        2. 内容上分为系统数据和业务数据
        3. 系统数据
          1. CPU/内存负载、磁盘 I/O、网络
        4. 业务指标
          1. 业务成功率、响应时间、吞吐量
      2. 故障发现
        1. 主要通过提升监控告警时效来达成
        2. 在系统运行情况采集完整的基础上，对可观测性数据进行监控。根据用户输入的规则，及时发现异常数据，并产生告警
      3. 故障辅助定位分析
        1. 主要通过完善单节点和全链路的故障定位能力来实现。
        2. 单节点的定位能力，包括 SLO、错误码、热点、内部资源等；
          1. SLO: service level objective, 服务质量目标, 定量的描述服务可靠性的程度
          2. SLA （service level agreement）:服务等级协议
          3. SLI（service level indicator）:服务等级对象，指的是对象，例如：qps，响应时间，准确性等
          4. SLO（service level objective）:服务等级目标，指的是目标，例如：qps 99.99% ，响应时间 10ms 等
          5. SLA 指的是整个协议，协议的内容包含了 SLI，SLO 以及恢复的方式和时间等等一系列所构成的协议，是与服务对象就 SLO 所签署的协议。具体用公式表达为: SLA = SLO + 后果 ，当然协议中有时规定的可能不仅仅是一个 SLO 指标，这时也会出现 SLO 可能是部分不达到或全部不达到的情况，如：达到响应时间 SLO+未达到可用性 SLO
          6. via SRE 运维（五）从 SLO 开始
        3. 全链路的点位能力，包括定位到问题节点、定位到节点根因
    3. 变更管理
    4. 容量管理
    5. 全链路压测
      1. 2014 年初，生产全链路压测的方法开始诞生，其目标是希望在大型促销活动来临前，可以在生产环境上模拟路演进行验证整体容量和稳定性。
      2. 由此，出现了全链路压测方法所涉及的公网多地域流量模拟、全链路流量染色、全链路数据隔离、全链路日志隔离、全链路风险熔断等关键技术
    6. 混沌工程
      1. 选定假设设计故障实验
      2. 自动化编排与执行实验
      3. 故障爆炸半径控制
      4. 实验观测
      5. 分析实验结果
  2. 故障止损工具
    1. 应急平台
    2. 容灾管理

分布式系统稳定性建设行业特点

互联网业

在复杂的分布式系统中，无法阻止故障的发生

互联网行业系统稳定性解决方案

  1. 建设可观测性能力
  2. 建设混沌实验平台
  3. 建设全链路压测能力
  4. 建立故障应急机制
  5. 建设 AIOps 能力
#稳定性
分布式系统稳定性建设指南-阅读笔记
https://www.yaozeyuan.online/2022/09/18/2022/09/分布式系统稳定性建设指南-阅读笔记/
作者
姚泽源
发布于
2022年9月18日
许可协议