南宫NG·28

首先，我们需要理解什么是高可用，英文叫High Availability，基本上来说，就是要让我们的计算环境（包括软硬件）做到full-time的可用性。在设计上一般来说，需要做好如下的设计：

1、对软硬件的冗余，以消除单点故障。任何系统都会有一个或多个冗余系统做standby；

2、对故障的检测和恢复。检测故障以及用备份的结点接管故障点。这也就是failover；

3、需要很可靠的交汇点（CrossOver）。这是一些不容易冗余的结点，比如域名解析，负载均衡器等；

听起似乎很简单吧，然而不是，细节之处全是魔鬼，冗余结点最大的难题就是对于有状态的结点的南宫NG·28复制和南宫NG·28一致性的保证（无状态结点的冗余相对比较简单）。冗余南宫NG·28所带来的一致性问题是魔鬼中的魔鬼：

• 如果系统的南宫NG·28镜像到冗余结点是异步的，那么在 failover 的时候就会出现南宫NG·28差异的情况。
• 如果系统在南宫NG·28镜像到冗余结点是同步的，那么就会导致冗余结点越多性能越慢。

所以，很多高可用系统都是在做各种取舍，这需要比对着业务的特点来的，比如银行账号的余额是一个状态型的南宫NG·28，那么，冗余时就必需做到强一致性，再比如说，订单记录属于追加性的南宫NG·28，那么在 failover 的时候，就可以到备机上进行追加，这样就比较简单了（目前一些企业所谓的异地双活其实根本做不到状态型南宫NG·28的双活）。

下面，总结一下高可用的设计原理：

• 要做到南宫NG·28不丢，就必需要持久化；
• 要做到服务高可用，就必需要有备用（复本），无论是应用结点还是南宫NG·28结点；
• 要做到复制，就会有南宫NG·28一致性的问题；
• 我们不可能做到 100% 的高可用，也就是说，我们能做到几个9个的SLA。

下面，我们来看一下 MySQL 的高可用的方案的 SLA（下图下面红色的标识表示了这个方案有几个9）：

图片来源：MySQL High Availability Solutions

简单解释一下 MySQL 的这几个方案（主要是想表达一个越多的 9 就越复杂）：

• MySQL Repleaction 就是传统的异步南宫NG·28同步或是半同步 Semi-Sync（只要有一个 slave 收到更新就返回成功）这个方式本质上不到 2 个9；
• MySQL Fabric 简单来说就是南宫NG·28分片下的M/S的读写分离模式。这个方案的的可用性可以达到 99%；
• DRBD 通过底层的磁盘同步技术来解决南宫NG·28同步的问题，就是 RAID 1——把两台以上的主机的硬盘镜像成一个。这个方案不到 3 个9；
• Solaris Clustering/Oracle VM ，这个机制监控了包括硬件、操作系统、网络和南宫NG·28库。这个方案一般会伴随着节点间的“心跳机制”，而且还会动用到 SAN（Storage Area Network）或是本地的分布式存储系统，还会动用虚拟化技术来做虚拟机的迁移以降低宕机时间的概率。这个解决方案完全就是一个“全栈式的解决方案”。这个方案接近 4 个9；
• MySQL Cluster 是官方的一个开源方案，其把 MySQL 的集群分成 SQL Node 和 Data Node，Data Node 是一个自动化 sharing 和复制的集群 NDB，为了更高的可用性，MySQL Cluster 采用了“完全同步”的南宫NG·28复制的机制来冗余南宫NG·28结点。这个方案接近5 个9；

那么，这些 2个9，3个9，4个9，5个 9 是什么意思呢？又是怎么来的呢？请往下看。

上面那些都不是本文的重点，本文的重点现在开始，如何测量系统的高可用性。当然是SLA，全称 Service Level Agrement，也就是有几个 9 的高可用性。

工业界有两种方法来测量 SLA，一个是故障发生到恢复的时间，另一个是两次故障间的时间。但大多数都采用第一种方法，也就是故障发生到恢复的时间，也就是服务不可用的时间，如下表所示：

比如，99.999% 的可用性，一年只能有 5 分半钟的服务不可用。感觉很难做到吧。

就算是3个9的可用性，一个月的宕机时间也只有40多分钟，看看那些设计和编码不认真的团队，把所有的期望寄托在人肉处理故障的运维团队， 一个故障就能处理1个多小时甚至2-3个小时，连个自动化的工具都没有，还好意思在官网上声明自己的SLA是3个9或是5个9，这不是欺骗大众吗？

老实说，我们很难计算我们设计的系统有多少的可用性，因为影响一个系统的因素实在是太多了，除了软件设计，还有硬件，还有每三方的服务（如电信联通的宽带 SLA），当然包括“建筑施工队的挖掘机”。所以，正如 SLA 的定义，这不仅仅只是一个技术指标，而是一种服务提供商和用户之间的 contract 或契约。这种工业级的玩法，就像飞机一样，并不是把飞机造出来就好了，还有大量的无比专业的配套设施、工具、流程、管理和运营。

简而言之，SLA 的几个 9 就是能持续提供可用服务的级别，不过，工业界中，会把服务不可用的因素分成两种：一种是有计划的，一种是无计划的。

1、无计划的宕机原因

下图来自 Oracle 的 《High Availability Concepts and Best Practices》

宕机原因包括如下：

• 系统级的故障 –  包括主机、操作系统、中间件、南宫NG·28库、网络、电源以及外围设备；
• 南宫NG·28和中介的故障 – 包括人员误操作、硬盘故障、南宫NG·28乱了；
• 其它：自然灾害、人为破坏、以及供电问题；

2、有计划的宕机原因

下图来自 Oracle 的 《High Availability Concepts and Best Practices》

宕机原因包括如下：

• 日常任务：备份，容量规划，用户和安全管理，后台批处理应用；
• 运维相关：南宫NG·28库维护、应用维护、中间件维护、操作系统维护、网络维护；
• 升级相关：南宫NG·28库、应用、中间件、操作系统、网络、包括硬件升级；

从上面这些会影响高可用的 SLA 的因素，你看到了什么？如果你还是只看到了技术方面或是软件设计的东西，那么你只看到了冰山一角。我们再仔细想一想，那个 5 个 9 的 SLA 在一年内只能是 5 分钟的不可用时间，5 分钟啊，如果按一年只出 1 次故障，你也得在五分钟内恢复故障，让我们想想，这意味着什么？

如果你没有一套科学的牛逼的软件工程的管理，没有牛逼先进的自动化的运维工具，没有技术能力很牛逼的工程师团队，怎么可能出现高可用的系统啊。

是的，要干出高可用的系统，这就是一套严谨科学的工程管理，其中包括但不限于了：

• 软件的设计、编码、测试、上线和软件配置管理的水平；
• 工程师的人员技能水平；
• 运维的管理和技术水平；
• 南宫NG·28中心的运营管理水平；
• 依赖于第三方服务的管理水平；

深层次的东西则是对工程这门科学的尊重：

• 对待技术的态度
• 一个公司的工程文化
• 领导者对工程的尊重

所以，以后有人在你面前提高可用，你要看的不是他的技术设计，而还要看看他们的工程能力，看看他们公司是否真正的尊重工程这门科学。

就像汽车一样，如果汽车的生产商只能做到3个9的可用性，也就是每天你的汽车要抛锚1分多钟，你是不是觉得想当的不靠谱？生命安全都得不到保障了。所以，人家把汽车的可用性做到好多个9，这完全不是找几个技工来做汽车的节奏，这就是一个严谨的科学化的工业生产的节奏。

有好些非技术甚至技术人员和我说过，做个APP做个网站，不就是找几个码农过来写写代码嘛。等系统不可用的时候，他们才会明白，要找技术能力比较强的人，但是，就算你和他们讲一万遍道理，他们也很难会明白写代码怎么就是一种工程了，而工程怎么就成了一门科学了。其实，很多做技术的人都不明白这个道理。

包括很多技术人员也永远不会理解，为什么要做好多像Code Review、自动化运维、自动化测试、持续集成之类这样很无聊的东西。就像我在之前的文章中提到的，阿里很多的工程师，架构师/专家，甚至资深架构师都没有这个意识，当然，这不怪他们，因为经历决定思维方式，他们的经历的是民用级的系统，做的都是堆功能的工作，的确不需要。

看完这些，最后让我们都扪心自问一下，你还敢说你的系统是高可用的了么？嘿嘿嘿 😉