基于高可用的可伸缩架构方法论生态

• 2020 年 2 月 24 日
• 筆記

1、什么是可用性

高可用性对于构建高可伸缩系统是一个极其重要的因素，那么什么是可用性，系统可用性和可靠性之间怎么区分。

1.1可用性和可靠性

• 可靠性 系统是否具备无差错地执行预期操作的能力
• 可用性 为了执行可靠性，系统当前可运行的能力

金融支付系统最敏感的业务场景-资损，用户完成一笔跨境收款，正常钱应该从跨境电商平台资金账户A流转到具备跨境收款能力的跨境支付的用户虚卡账户B，但是由于系统bug，钱流转到了虚卡账户C，业务功能逻辑错误，表示可靠性很低；如果钱流转到了虚卡账户B，但是永远得不到结果，可用性就很低，可靠性可以通过功能测试来修复，但是可靠性很难解决。

1.2 低可用性的架构驱动因子

• 资源耗尽
• 预期之外的压力变化
• 流动行为的增加
• 外部依赖
• 技术债务

2、如何提升应用程序的可用性

• 时刻考虑应对故障
  • 设计
  • 依赖
  • 用户
• 时刻考虑如何伸缩
  • 设计出能够增加数据库数量和容量的架构
  • 考虑限制你的数据伸缩的原因
  • 应用服务器可伸缩，服务状态如何维护、如何路由流量
  • 将静态流量导向离线提供方
  • 动态资源静态化
• 缓和风险 保持系统高可用需要消除系统中的风险，架构约束条件是要先确定风险及风险分类，从系统思考角度考虑风险类别：
  • 存在系统崩溃的风险
  • 存在数据库崩溃的风险
  • 存在返回结果不正确的风险
  • 存在网络连接失败的风险
  • 存在新部署的软件功能出现故障的风险
• 监控可用性
  • 服务器监控
  • 配置变化监控
  • 应用程序性能监控
  • 人为测试
  • 报警
• 以预测和确定的方式来应对可用性问题

3、可用性可度量

测量可用性对保证系统高可用非常重要，任何一款APM系统或者自研的监控系统，都具备监控指标的可度量，只有度量才能实时的追踪系统服务的运行轨迹。

通常可用性都会拿N个9来衡量，比如某跨境支付公司，号称对外收款核心接口能够保证9999(4个9)的可用性，这是一个什么概念，每月只有4分钟故障时间，见如下表格：

可用性误区

• 可用性等级定义需要结合实际的业务场景
• 计划中和日常维护导致系统的不可用也要计算到度量中

维护窗口可用性计算规则

业务接口可用性百分比=(该期间的总秒数-系统宕机的秒数)/该期间的总秒数

每周的小时数=7天*24小时=168小时

每周不可用的小时数=2小时

业务接口可用性(没有故障)=(168小时-2小时)/168小时=98.8%

业务接口可用性(没有故障)=98.8%

如果每周系统维护窗口时间为2小时，那么系统可用性都达不到最低标准2个9，这是是多么的可怕。

4、服务分级

微服务架构、分布式架构以及云原生架构盛行，导致服务依赖关系复杂度增强，关键服务与非关键服务之间级联故障导致相关服务的可用性极低，解决问题的关键是结合服务的业务场景进行服务分级。

4.1什么是服务分级

服务分级其实是与服务关联的标签，表示业务场景下，对于业务可用性的关键程度。

1级服务

1级服务是系统中最关键的服务，如果某个服务出现故障会导致用户或者公司业务出现较大的损失

例如：用户服务、汇兑服务、出金和入金服务、vat付款等

2级服务

2级服务对于业务非常重要，但是关键性不如1级服务，2级服务只会影响用户体验

例如：订单搜索服务、订单结算服务等

3级服务

3级服务会对业务系统造成较小的影响，不容易注意到

例如：用户头像服务、推荐服务和站内信等

4级服务

4级服务是对业务不会造成任何影响

例如：异步邮件或者短信提醒服务等

5、使用服务分级

如何使用已经达成一致的服务分级，一般会从如下维护考虑

• 期望 管理服务期望的一种手段就是SLA(服务等级协议)
• 响应性 系统故障的响应性的关键决策因素：故障的严重性、出现故障的服务级别。 依赖响应性动态调整系统策略：
  • 报警通知
  • 期望的SLA
  • 对于低优先级问题的上报路径
  • 提供响应的时间安排(24*7或仅办公时间)
  • 是否提供紧急部署或者产品更改
  • 根据服务的可用性和响应性制定SLA
• 依赖
  • 关键依赖 如果你的服务级别高于(数字小于)依赖服务的级别那么这个服务就是关键依赖，不能忽略依赖服务的故障，必须考虑服务降级，尽最大可能保证服务的可用性和可靠性，依赖服务的服务级别比较低，可用性和可靠性比较低
  • 非关键依赖 如果你的服务级别低于(数字大于)依赖服务的级别那么这个服务就是非关键依赖，可用忽略依赖服务的故障。

6、服务等级协议(SLA)

服务等级协议是团队和服务所有者之间的协议，提供了一个沟通服务间期望的机制。

6.1 服务等级协议定义

服务等级协议是一个提供某种级别可靠性和性能的承诺，它们用来在服务所有者和用户之间创建一个牢固的合约关系。

SLA需要结合具体服务的业务场景，和利益相关者协商服务之间的期望，比如可用性、性能、产品功能等

6.2 SLA性能检测

• 调用延迟
• 流量
• 运行时长
• 错误率

6.3 SLA阈值

SLA必须要设定阈值，比如RT<20ms等

6.4 SLA排名

比如TP90（百分之90的请求的RT低于20ms）、TP95（百分之95的请求的RT低于20ms）、TP80

（百分之80的请求的RT低于20ms）

6.5 延迟分组

比如某个服务在一定流量下，可以保持一定的延迟，比如当TPS<250k 调用延迟TP90<25毫秒，当TPS>=250k 且小于 400k 调用延迟TP90<30毫秒。

7、处理服务故障

在构建大型基于微服务(分布式服务或者云原生服务)的系统时，如何处理服务故障是一个必须要解决的前置条件，服务越多，服务出现故障的可能性就越大，依赖于故障服务的其他服务数据也会越来越多。

级联式的服务故障

依赖的服务发生故障会影响可用性，可以说业务团队几乎每天都在忍受或者着手解决这些故障，因为谁也不能保障我们所依赖的服务什么时候会挂，很多业务团队也没这个经历去梳理这个问题，很多都是被动的等故障发生，然后在做局部的修改，规避故障问题，其实问题的解决是有很多方法论技巧的。

如何响应服务故障

面对服务故障，技术开发人员如何响应很关键，响应服务故障必须具备如下前置条件：

• 可预测的 拥有可预测的故障响应式当前服务能够依赖其他服务的一个重要指标，可预测的响应，要求当前服务必须具备统一吃的异常错误码机制，如果依赖的服务给了一个不可预测的响应，当前服务必须给一个合理的响应，保证请求链路故障的可溯源。
• 可理解的 响应故障必须满足双方的错误处理契约，也就是错误码必须能够识别。
• 对当前场景是合理的 合理并具备业务意义的响应，便于问题定位。

如何确定故障

• 乱码响应
• 表示致命错误发生的响应
• 结果可以理解但是所需的结果不匹配
• 结果超出预期范围
• 没有接收到响应
• 接收响应很慢

如何解决故障

• 优雅降级
• 优雅补偿
• 尽早失败

8、应用程序可伸缩方法论