设计思想一：服务高可用

Posted 2021-04-24 莫肥定律

什么是高可用？

高可用是指系统所能提供无故障服务的一种能力，避免因服务器宕机或服务异常而造成不可用的情况。

日常生活中几乎所有的互联网服务都涉及这一设计思想，比如用来剁手的淘宝、聊天的微信、买票的12306等等，因为这些服务对稳定性和可用性的要求非常高。

我们知道没有绝对稳定的设备，在没有高可用的情况下，一旦机器出现故障，服务的瘫痪是必然的。

即使单台设备的年故障率小于百万分之一，但当我们的设备数量达到一定规模时，出现故障的几率就是必然的，大家将会面对每天都在崩溃的服务和打不开的页面。

做好高可用，减少了运营期间，研发人员的介入，提高了用户体验；同时提高了数据的安全性，把损失降到最低，就是鸡蛋不能都放一个篮子里面。

可以说没有高可用服务就没有今天的互联网世界。

如何衡量高可用

如果你的系统全年都是正常提供服务，那么你系统的可用性就是100%，当然这个值是理想状态下的。一般都是以几个9来表示系统的可用性，如99.99%，小数点后9越多就代表可用性越强，下面来看看这个几个9是如何计算出来的。

可用性=平均故障间隔/(平均故障间隔 + 故障恢复平均时间)

所有系统都按高可用设计？

很多小成本或者创新产品很少会考虑高可用，毕竟技术是为业务服务的，成本是一个非常重要的因素。

• 小公司没有完善的基础建设，无法为一个不确定的产品考虑太多，影响开发进度、增加运营成本，而且大部分轻量级程序可能运行个几年也就偶然几次小故障。可以在业务量增大和预算多了之后，再进行扩展和升级。

• 大公司基础设施完善，任何一个模块都有比较成熟稳定的高可用解决方案，早期的投入并不会很高，而且大部分都是资源共享的，这时可以提前将这部分考虑到系统架构设计中。

如何设计系统的高可用

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

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

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

听起来很简单，但细节是魔鬼。冗余结点最大的难题就是对有状态结点的数据复制和一致性进行保证：

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

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

所以，很多高可用系统都在做各种取舍，需要根据业务特点进行分析，比如银行账号的余额是一个状态型的数据，冗余时就必须做到强一致性；再比如，订单记录属于追加性的数据，只需在failover的时候到备机进行追加即可。

高可用设计思路总结

• 要做到数据不丢，就必须要持久化。

• 要做到服务高可用，无论是应用结点还是数据结点甚至是网络线路都必须要有备用（副本）。

• 要做到复制，就会有数据一致性的问题。

• 我们不可能做到100%的高可用，也就是说，我们能做到几个9个的SLA。

这个图基本上来说是目前高可用系统中能看得到的所有的解决方案的基础了。关于M/S、MM、2PC、Paxos等各种方式的具体分析比较内容也比较多，就不在这里做展开讨论，后面有机会再讲。

举个栗子

我们举个简单的例子来看看一个简单的应用架构是如何通过高可用设计一步步“成长”的。

首先假设我们有一个网关-应用-数据库的服务架构，如下图所示。

我们知道单个应用是不稳定的，所以我们对应用部分先进行了扩展，将应用复制一份在其他机器上进行部署。为了理解简单，这里我们只复制一份应用，下同。

同理，我们可以对网关和数据库进行扩展（可根据需求选择主-主模式和主-从模式）。同时，为了保证服务的联通和可用，我们需要对他们之间的连接进行冗余设计。

是不是一下子就复杂了起来。细心的同学可能还会发现，我们服务网关的解析和映射仍然会影响我们架构的稳定性。这时，我们一般在网关前加上虚拟IP或者负载均衡器对服务解析进行管理分发。此处我们以负载均衡器为例。（虚拟IP和负载均衡的稳定性由各自服务提供者保证，此处不做考虑。）

于是我们得到了这么一套架构。看起来很完美了，但又有同学说，要是整个机房断电咋办？一般来说，数据中心的机房在电力设计上就有冗余，即我们的UPS（不间断电源）设备。那么假设一个机房真的完全不可用的时候，我们有解决办法吗？答案是多数据中心，以两地三中心（同城双中心加异地灾备）为例，形成了以下架构。

一般到这里就差不多了，当然也会有一些国际化的企业需要提供全球的高可用服务，这时可以接入一些云厂商提供的基础设施和服务来实现。

整个高可用设计需要根据具体的业务和需求确定，这里只是介绍一下思想，希望大家都能有所收获。