互联网高可用设计方案 High Availability

  • 互联网高可用设计方案 High Availability
  • 为什么需要高可用
  • 如何来衡量高可用性可用性
  • 微服务高可用设计方法
  • 服务冗余
  • 无状态化（stateless）
  • 负载均衡
  • 幂等设计
  • 超时机制
  • 异步化设计
  • 服务降级-限流-熔断机制
  • 架构拆分、服务治理
  • 如何无缝停止线上服务


互联网高可用设计方案 High Availability

为什么需要高可用

高可用（High Availability）是系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 高可用是一种面向风险设计，使系统具备控制风险，提供更高的可用性的能力， 所有事物都不是100%可靠的 。

如何来衡量高可用性可用性

通常表示为一个百分比，表示在给定时间段内特定系统或组件的正常运行时间，其中100％的值表示系统永不失效。例如，在一年的时间内保证99％可用性的系统最多可以有3.65天的停机时间（1％）。这些值是根据几个因素计算的，包括计划和非计划维护周期，以及从可能的系统故障中恢复的时间。目前大部分企业的高可用目标是4个9，也就是99.99%，也就是允许这台系统的年停机时间为52.56分钟。(个人觉得衡量高可用的方式=停机时间的影响请求量/总请求量（一年）)

描述

通俗叫法

可用性级别

年度停机时间

基本可用性

2个9

99%

87.6小时

较高可用性

3个9

99.9%

8.8小时

具有故障自动恢复能力的可用性

4个9

99.99%

53分钟

极高可用性

5个9

99.999%

5分钟

微服务高可用设计方法

服务冗余

服务冗余通过部署多份相同的服务提供服务，为了避免单点故障，导致服务不可用，通常至少部署两个及以上的服务，单个服务宕机其它服务仍然正常提供给服务，冗余服务是必须且保证服务高可用的最有效且必须的方案。

无状态化（stateless）

既然要通过服务冗余，那么要保证每个相同的服务是无状态的，冗余部署的服务是完全对等的stateless，请求到达任意一个节点执行均可满足服务正常提供。如何打造stateless的服务呢？（关注author，后续会介绍到）

负载均衡

因为大多数互联网服务是动态的，有时要去掉老机器，有时要灰度发布，有时用户访问量又会突发，当业务服务海量用户拥有大量请求的时候，如果保证流量雨露均沾，不会造成流量请求冷热不均，是HA架构的一个难题之一。

狭义上的负载均衡：侠义上的负载均衡相对比较简单，通常是指6种广为人知的负载均衡策略

1、轮询法（ Round Robin ）

将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

2、随机法（ Random）

通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知，随着客户端调用服务端的次数增多，

其实际效果越来越接近于平均分配调用量到后端的每一台服务器，也就是轮询的结果。

3、源地址哈希法（HASH）

源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。

4、加权轮询法（ Weight Round Robin ）

不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。

5、加权随机法（ Weight Random ）

与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。

6、最小连接数法（ Least Connections ）

最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前

积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。

广义上的负载均衡：

广义上的负载均衡是打造HA服务非常重要的一点，不能实现广义上的负载均衡，是很难达到HA架构的，是指部分服务超时或者宕机不可用时，上层服务自动选择可用的其他相同服务正常提供服务，待服务可用时，上层服务能发现服务可用，建立服务，分摊流量。

幂等设计

我将这里的幂等分为请求幂等和业务幂等

1、请求幂等

同一个请求执行一次和或短时间内重复执行多次，保证是完全对等的。

2、业务幂等

不同的请求，在特定的业务下，保证只有一次成功。业务幂等通过串行化的方式，主要通过分布式锁方式。

超时机制

设计超时机制及时反馈用户，面向用户友好编程，不伤害用户，用户是最忠诚的伙伴，爱是相互的。超时时间设计多长比较合适呢，通常timeout不超过100ms，超时次数不超过三次，为什么三次？不是五次？超过三次可能是网络异常，或者下游服务business，try again and again会再次增加下游服务服务，甚至导致下游雪崩。

异步化设计

异步化可以将服务解耦，提高吞吐量，适用与非强一致性的请求，业务允许条件也可提供默认值反馈用户。

服务降级-限流-熔断机制

当有热点事件发生，突发的流量会导致服务过载，所谓人有悲欢离合，月有阴晴圆缺，限流熔断降级是服务HA的避雷针，由于资源有限，不可能无限量为了短时的服务添加服务器扩容，这是不现实的，另外时间有限，远水解不了近渴，降级限流熔断使服务更加柔性，牺牲小我 ，成全大我，虽然对有一些用户是雪中送碳，但对另一些用户是锦上添花，让服务正常运行，极端情况下要壮士断腕，弃卒保车，保护机制也是HA必不可少的方案。

通常使用组件化的解决方案，但是组件化的方案有一个弊端，与业务耦合在一起，不能自由配置，条件允许可提供平台级的解决方案，通过管理平台自由开启。

架构拆分、服务治理

保证业务可拆分，服务可扩展的能力是HA的手段之一，通过横向拆分和垂直拆分，让服务更加灵活，通过秒级别的服务治理和监控，实时查看服务的运行情况，主动发现系统异常，服务治理使服务有了神经和脉络。

如何无缝停止线上服务

网关层具备热切换能力，通过配置中心启动开关，gateway将直接返回之后时间点的请求相应服务正忙，待下层的业务层日志不再更新，平稳的停止服务。

也可以通过超时时间，网关层设置超时时间如5s，5秒之后关闭服务。

也可以设置防火墙只进不出，等到超时时间之后关闭服务，更严谨可以查阅日志保证服务日志不再更新。