关于高可用的系统

在《这多年来我一直在钻研的技术》这篇文章中，我讲述了一下，我这么多年来一直在关注的技术领域，其中我屡次提到了工业级的软件，我还觉得有不少人会问我怎么定义工业级？以及一个高可用性的软件系统应该要怎么干出来？这样我也能够瓜熟蒂落的写下这篇文章，可是没有人问，那么，我只好厚颜无耻的本身写下这篇文章了。哈哈。

另外，我在一些讨论高可用系统的地方看到你们只讨论各个公司的技术方案，其实，高可用的系统并不简单的是技术方案，一个高可用的系统其实还包括不少别的东西，因此，我以为你们对高可用的系统了解的还不全面，为了让你们的认识更全面，因此，我写下这篇文章。

理解高可用系统

首先，咱们须要理解什么是高可用，英文叫High Availability（Wikipedia词条），基本上来讲，就是要让咱们的计算环境（包括软硬件）作到full-time的可用性。在设计上通常来讲，须要作好以下的设计：

 

1. 对软硬件的冗余，以消除单点故障。任何系统都会有一个或多个冗余系统作standby
2. 对故障的检测和恢复。检测故障以及用备份的结点接管故障点。这也就是failover
3. 须要很可靠的交汇点（CrossOver）。这是一些不容易冗余的结点，好比域名解析，负载均衡器等。

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

• 若是系统的数据镜像到冗余结点是异步的，那么在failover的时候就会出现数据差别的状况。

• 若是系统在数据镜像到冗余结点是同步的，那么就会致使冗余结点越多性能越慢。

因此，不少高可用系统都是在作各类取舍，这须要比对着业务的特色来的，好比银行帐号的余额是一个状态型的数据，那么，冗余时就必需作到强一致性，再好比说，订单记录属于追加性的数据，那么在failover的时候，就能够到备机上进行追加，这样就比较简单了（阿里目前所谓的异地双活其实根本作不到状态型数据的双活）。

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

• 要作到数据不丢，就必须要持久化
• 要作到服务高可用，就必须要有备用（复本），不管是应用结点仍是数据结点
• 要作到复制，就会有数据一致性的问题。
• 咱们不可能作到100%的高可用，也就是说，咱们能作到几个9个的SLA。

高可用系统的技术解决方案

我在《分布式系统的事务处理》中引用过下面这个图：这个图来自来自：Google App Engine的co-founder Ryan Barrett在2009年的Google I/O上的演讲《Transaction Across DataCenter》（视频： http://www.youtube.com/watch?v=srOgpXECblk）

这个图基本上来讲是目前高可用系统中能看获得的全部的解决方案的基础了。M/S、MM实现起来不难，可是会有不少问题，2PC的问题就是性能不行，而Paxos的问题就是太复杂，实现难度太大。

总结一下各个高可用方案的的问题：

• 对于最终一致性来讲，在宕机的状况下，会出现数据没有彻底同步完成，会出现数据差别性。
• 对于强一致性来讲，要么使用性能比较慢的XA系的两阶段提交的方案，要么使用性能比较好，可是实现比较复杂的Paxos协议。

注：这是软件方面的方案。固然，也可使用造价比较高的硬件解决方案，不过本文不涉及硬件解决方案。

另外，现今开源软件中，不少缓存，消息中间件或数据库都有持久化和Replication的设计，从而也都有高可用解决方案，可是开源软件通常都没有比较高的SLA，因此，若是咱们使用开源软件的话，须要注意这一点。

高可用技术方案的示例

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

图片来源：MySQL High Availability Solutions

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

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

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

高可用性的SLA的定义

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

工业界有两种方法来测量SLA，

• 一个是故障发生到恢复的时间
• 另外一个是两次故障间的时间

但大多数都采用第一种方法，也就是故障发生到恢复的时间，也就是服务不可用的时间，以下表所示：

系统可用性%	宕机时间/年	宕机时间/月	宕机时间/周	宕机时间/天
90% (1个9)	36.5 天	72 小时	16.8 小时	2.4 小时
99% (2个9)	3.65 天	7.20 小时	1.68 小时	14.4 分
99.9% (3个9)	8.76 小时	43.8 分	10.1 分钟	1.44 分
99.99% (4个9)	52.56 分	4.38 分	1.01 分钟	8.66 秒
99.999% (5个9)	5.26 分	25.9 秒	6.05 秒	0.87 秒

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

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

影响高可用的因素

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

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

无计划的宕机缘由

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

 

有计划的宕机缘由

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

 

咱们能够看到，上面的宕机缘由包括以下：

无计划的

• 系统级的故障 –  包括主机、操做系统、中间件、数据库、网络、电源以及外围设备
• 数据和中介的故障 – 包括人员误操做、硬盘故障、数据乱了
• 还有：天然灾害、人为破坏、以及供电问题。

有计划的

• 平常任务：备份，容量规划，用户和安全管理，后台批处理应用
• 运维相关：数据库维护、应用维护、中间件维护、操做系统维护、网络维护
• 升级相关：数据库、应用、中间件、操做系统、网络、包括硬件升级

真正决定高可用系统的本质缘由

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

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

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

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

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

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

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

其它

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

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

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

（全文完）