高可用性 —— 你真懂了吗？

 原创：http://yakyang.com/?p=663

1、决定可用性的两大因素

SLA ：Service-Level Agreement的缩写，意思是服务等级协议。

一般来说，我们的观念里一个服务至少要做到 99.9% 才称为基本上可用，是合格性产品。否则基本很难被别人使用。

MTBF 和 MTTR

MTBF: Mean time between Failures，用通俗的话讲，就是一个东西有多不可靠，多长时间坏一次。

MTTR: Mean time to recover，意思就是一旦坏了，恢复服务的时间需要多长。

一个服务的可用度，取决于 MTBF 和 MTTR 这两个因子。那就是： 要么提高 MTBF, 要么降低 MTTR

2、高可用性方案

2.1、提高冗余度，多实例运行，用资源换可用性。

虽然道理很简单，实现起来可不简单，有很多很多细节上的东西需要考虑。

第一个细节：N + 2 应该是标配。

N + 2 就是说平时如果一个服务需要 1 个实例正常提供服务，那么我们就在生产环境上应该部署 1 + 2 = 3 个节点。大家可能觉得 N + 1 很合理，也就是有个热备份系统，比较能够接受。但是你要想到：服务 N + 1 部署只能提供热备容灾，发布的时候就失去保护了。从另一个角度来讲，服务 N + 2 说的是在丢失两个最大的实例的同时，依然可以维持业务的正常运转。

第二个细节： 实例之间必须对等、独立。

千万不要搞一大一小，或者相互依赖。否则你的 N + 2 就不是真的 N + 2。如果两地三中心的一个中心是需要 24 小时才能迁移过去的，那他就不是一个高可用性部署，还是叫异地灾备系统吧。

第三个细节：流量控制

想做到高可用，必须拥有一套非常可靠的流量控制系统。这套系统按常见的维度，比如说源 IP，目标 IP 来调度是不够的，最好能按业务维度来调度流量。比如说按 API， 甚至按用户类型，用户来源等等来调度。

一个高可用系统必须要支持以下几种场景：

1. Isolation（隔离）A 用户发来的请求可能和 B 用户发来的请求同时处理的时候有冲突，需要隔离。
2. Quarantine。用户 A 发来的请求可能资源消耗超标，必须能将这类请求钉死在有限的几个节点上，从而顾全大局。
3. Query-of-death。上线之后一个用户发来个一个异常请求直接搞挂服务。连续多发几个，整个集群都挂没了，高可用还怎么做到？那么，对这种类型的防范就是要在死掉几台服务器之后可以自动屏蔽类似的请求。

2.2、变更管理（Change Management）

2.2.1、线下测试（Offline Test）

2.2.2、灰度发布

做灰度发布，如果是匀速的，说明没有理解灰度发布的意义。一般来说阶段选择上从 1% -> 10% -> 100% 的指数型增长。这个阶段，是根据具体业务不同按维度去细分的。

这里面的重点在于1%并不全是随机选择的，而是根据业务特点、数据特点选择的一批有极强的代表性的实例，去做灰度发布的小白鼠。甚至于每次发布的 第一阶段用户（ Canary / 金丝雀) ，根据每次发布的特点不同，是人为挑选的。

回到本质：灰度发布是上线的最后一道安全防护机制。即不能过慢，让产品团队过度依赖，也不能过于随机，失去了他的意义。

2.2.3、服务必须对回滚提供支持

理由1：数据改动之后格式跟以前的不兼容了，回退也不能正常！

秘籍1：设计、开发时候就考虑好兼容性问题！！！比如说数据库改字段的事就不要做，改成另加一个字段就好。数据存储格式就最好采用 protobuf 这种支持数据版本、支持前后兼容性的方案。最差的情况，也要在变更实施『之前』，想清楚数据兼容性的问题。没有回滚脚本，不给更新，起码做到有备而战。

理由2：变更删掉东西了！回退之后数据也没了！

秘籍2：你一定是在逗我。把这个变更打回去，分成两半。第一半禁止访问这个数据。等到发布之后真没问题了，再来发布第二半，第二半真正删掉数据。这样第一半实施之后需要回滚还可以再回去。

理由3：变更发布了之后, 其他依赖这个系统的人都拿到了错误的数据，再回退也没用了，他们不会再接受老数据了！

秘籍3：这种比较常见出现在配置管理、缓存等系统中。对这类问题，最重要的就是， 应该开发一种跟版本无关的刷新机制。触发刷新的机制应该独立于发布过程。 要有一个强制刷新数据的手段。

回滚兼容性问题，是一个整体难题。只有开发和运维都意识到这个问题的严重性，才能从整体上解决这个问题。而解决不了回滚难题，就不可能达到高可用。

3、可用性 7 级图表

第一级：系统崩溃了，数据也丢失了

第二级：系统崩溃了，新产生的数据有丢失

第三级：系统崩溃了，但是数据没有丢失

第四级：没有彻底崩溃，但是服务质量很差

第五级：部分服务已经出现故障

第六级：用户感觉到延迟和故障

第七级：无感知的完美故障切换

4、方案

4.1、入口

心跳检测

4.2、 高可用的服务：

• 分级管理
• 服务无状态
• 超时设置
• 异步调用
• 服务降级：两种手段，拒绝服务和关闭服务。
• 幂等性设计：有些服务必须在服务保证服务重复调用和调用一次产生的结果相同。

4.3、高可用的数据：

• 数据库主从模式
• CAP 通常会选择强化分布式存储系统的可用性（A）和伸缩性（P），而在某种程度上放弃一致性（C）. 对不一致性数据进行某种意义的补偿和纠错。