为什么基础服务不应该高可用（二）

关系

虽然说所有的开发者都希望基础服务能够提供尽可能高的可用性和 SLA，但是极高的 SLA 对于整体业务的长期稳定并不是一件好的事情，可能在短期内能够提供较大的价值，但是从长远来看可能会造成更大的破坏，这也就是今天想要分析的问题 —— 『为什么基础服务不应该高可用』。

设计

在这一节中，我们将从以下的三个方面依次分析『为什么基础服务不应该高可用』：

• 凡是可能出错的事情就一定会出错；

• 成本因素有时是技术决策的最关键因素；

• 只有使用更多异构的副本才能保证更高的可用性；

最后一点并不是这个观点的强论点，我们放在这里只是为了让各位读者了解能够保证服务高可用的唯一方法，需要注意的是通过保证代码逻辑的正确、服务的正确配置来提升可用性并不是我们在这里要讨论的内容，这是一个服务正常工作的前提。

墨菲定律

墨菲定律其实已经是一个几乎所有地球人都知道的定律了，它在大多数的时候都会被解释成『凡是可能出错的事情就一定会出错』，任何一个线上的服务能够正常运行都是极其偶然的，只要时间拉的足够长，我们就没有办法保证任何服务 100% 的可用性。每一个服务的正常工作可能都需要满足以下的条件：

• 依赖的所有基础服务能够正常工作；

• 依赖的所有组件能够正常工作；

• 服务的所有配置都非常合理且无一错误；

• 能够通过网线连接到互联网并接收来自其他客户的请求；

• 能够有充足的电力保证硬件的正常工作；

• 磁盘不会突然损坏或者空间不足；

• 不会有虫子爬到机箱里阻断电源；

• 不会受到核弹、极端自然灾害的威胁和影响；

• …

在这样不稳定的世界中运行一个稳定的服务是非常困难的，而想要在尽可能长的时间中保证服务的 100% 可用是不可能做到的，一旦我们接受了所有依赖条件都 100% 可用这个设定，那么当灾难真正发生时，我们是无法做到及时恢复和容灾的。

从这一点来看，基础服务其实也是没有办法做到 100% 可用，它只能尽其所能提高可用性，无法做到在足够长的时间中绝对可用。

成本因素

很多人可能都会认为服务的可用性一定是越高越好，然而并不是这样的，成本因素在很多情况下限制了服务提供的可用性，经济学原理告诉我们『理性人思考边际成本』，对于是否应该提高可用性，我们应该思考继续提高可用性带来的收益与损失。

服务的可用性最后还是一个收益与成本的权衡问题，也就是继续提升可用性的边际成本是否大于造成事故或者可用性不达标时的赔偿和损失。

随着可用性的不断提升，提高可用性的边际成本会以指数的量级升高，而服务宕机造成的损失也会随着服务的可用性的提高急速下降，这两个不同曲线的交点就意味着两者成本相当，这时再提升服务的可用性就没法带来经济上的利益了，需要注意的是这里的曲线画的相对比较简单，只是帮助读者理解高可用性与成本之间的联系。

我们其实可以这样理解这个问题，服务提供商提供的服务是为了获得有形和无形的资产，服务商对外宣称的『高可用』其实只是宣传的一种手段，很多时候高可用并不是服务方主要考虑的因素，真正促使它提供高可用服务的还是背后的直接经济利益和造成事故时需要赔偿的名誉和金钱损失。

服务可用性的提升从 2 个 9 提升到 3 个 9 并不是一件特别困难的事情，但是从 4 个 9 提升到 5 个 9 就需要考虑非常多的容灾措施，可用性每提升 1 个 9 都需要研发人员付出指数倍的努力，这其实也就是大多数的服务商最多只提供 99.99% 或者 99.95% 可用性的原因，因为在这个可用性下，服务提供商的利益才能最大化。

异构服务

上述的两个原因已经能够很好地回答今天的问题了，但是作者还是想通过最后这一小节简单介绍如何才能使用『较低可用性』的基础服务构建高可用的服务，想要让单一服务或者组件的可用性不成为系统可用性的瓶颈，我们只能依赖异构的服务或者组件，这里的异构其实是说提供相同的功能，但是有着一个或者多个不同的属性，例如：

• 物理机不同：部署在不同机器上的 Redis 服务；

• 协议和代码不同：本地部署的 Redis 和 memcached 服务；

• 服务提供商不同：谷歌云和 AWS 的 Redis 服务；

• 地理位置不同：北京和上海的机房中的 Redis 服务；

• …

假如我们只依赖于 1 个可用性为 99.9% 的 Redis 服务，那么我们服务的可用性最高只有 99.9%，但是如果我们依赖两个可以相互替代的服务，例如：Redis 和 memcached，那么我们整个系统的可用性的瓶颈就不再是 99.9% 了，这也就是服务高可用的唯一解决方案。

总结

我们在这篇文章中分析了『为什么基础服务不应该高可用』这一问题，这一个乍听起来没什么道理的观点还是非常值得我们去深入思考和探索的，简单总结一下，基础服务不需要保证高可用的几个原因：

1. 在足够长的时间中，任何服务都没法保证 100% 可用，100% 可用更像是一个危险的承诺，一旦默认了这个假设就不利于我们构建高可用的服务；

2. 边际成本是提升可用性时必须要考虑的因素，作为服务提供商必须要衡量提升可用性的成本和收益，而过高或者过低的可用性都会降低总体的收益；

3. 服务的高可用从来都不来源于单一的依赖，只有使用更多异构的副本和组件才能尽可能保证服务的稳定；

今天的讨论的问题其实并不只是一个技术问题，我们在做设计时也不应该仅仅考虑技术因素，很多的权衡与设计都来源于技术之外的其他因素。

这篇文章也不是为基础服务保证低可用提供理由，基础服务的价值就在于提供稳定的服务，作者更想让各位读者思考这一问题背后的非技术因素。

到最后，我们还是来看一些比较开放的相关问题，有兴趣的读者可以仔细思考一下下面的问题：

• 如果可用性高于约定的 SLA，很多服务提供商会在一个可用性计算周期结束之前故意动触发服务的宕机，你觉得这种做法背后的原因是什么？

如果对文章中的内容有疑问或者想要了解更多软件工程上一些设计决策背后的原因，可以在博客下面留言，作者会及时回复本文相关的疑问并选择其中合适的主题作为后续的内容。

Reference

• High availability · Wikipedia
  

• Compute Engine Service Level Agreement
  

相关文章

• 011 为什么 MongoDB 使用 B 树
  

• 010 为什么 Redis 快照使用子进程
  

• 009 为什么 MySQL 使用 B+ 树
  

• 008 为什么总是需要无意义的 ID
  

• 007 为什么基础服务不应该高可用
  

• 006 为什么 MD5 不能用于存储密码
  

• 005 为什么你应该使用 Git 进行版本控制
  

• 004 为什么 TCP 建立连接需要三次握手
  

• 003 为什么 DNS 使用 UDP 协议
  

• 002 为什么使用通信来共享内存
  

• 001 为什么 Redis 选择单线程模型
  

本文转载自 Draveness 技术博客。

原文链接：https://draveness.me/whys-the-design-unstable-infrastructure