为什么这么设计（Why’s THE Design）是一系列关于计算机领域中程序设计决策的文章，我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。如果你有想要了解的问题，可以在文章下面留言。

作者在去年使用过 Google Cloud 平台提供的 Kubernetes 来管理生产环境的集群，然而在托管的过程中却经历了一些比较严重的线上事故，几个集群的中的节点因为停机维护而同时重启导致线上的服务几个小时都处于不不可用的状态。

当然事故时间如此之长的原因有很多，在这里不会展开讨论，然而事故刚刚出现时作者曾经也想去责怪和质疑谷歌云服务的稳定性，但是在随后的分析中得出了另一个结论『你的基础服务其实不应该高可用』，我们在这篇文章就会为各位读者分享作者产生这一观点的原因。

概述

为了帮助大家理解今天的内容，我们需要帮助各位读者理解问题中的两个个关键点，也就是高可用意味着什么、基础服务在这里的定义以及基础服务和 SLA 之前的关系。

ha-and-infra

高可用

想要让服务达到高可用并不是一个容易的事情，不仅服务运行过程中出现的事故会影响可用时间，用于维护的计划停机和更新其实也会影响服务整体的可用时间，如果一个服务要求可用性为 99.95%，那么全年不工作的时间可能只有 4.38 小时，每个月只能宕机 21.9 分钟。

可用性	不可用时间（每年）	不可用时间（每月）
99%	87.6h	7.3h
99.9%	8.76h	0.73h
99.99%	52.56min	4.38min
99.999%	5.26min	26.3s
99.9999%	31.56s	2.63s

假设我们需要达到 4 个 9 的可用性（99.99%），全年的不可用时间只有不足 1 小时，每个月的不可用时间只有 4.38 分钟，99.99% 就是 Google 云计算引擎对外提供的服务质量，每个月不可用时间小于 5 分钟，这也是作者见到过云服务商对外提供的最高服务等级协议（Service-Level Agreement, SLA）了。

很多人可能认为每个月不可用 5 分钟也没什么难的，但是如果你的业务服务建立在稳定性只有 99.95% 甚至 99.9% 的服务上时，你还能保证服务的高可用么？

基础服务

在这篇文章中我们谈到的基础服务指的其实都是基础设施和基础架构，例如用于支撑整个业务系统的 MySQL、Redis 以及 Kubernetes 等系统，这些系统的稳定性和可用性会影响整个业务系统的可用，由于这些基础服务往往提供了相对较为简单和稳定的功能，所以我们对基础服务的可用性有着更高的要求。

infra-service

业务服务由于经常发版和迭代，有时很难保证服务的稳定和可用，而基础服务和基础架构因为处于更加底层的位置，所以它们稳定性的提升对于依赖它们的上游来讲会有比较大的收益，这也是所有业务同学对基础服务以及架构的期望 —— 保证尽可能高的可用性并保证服务不会宕机。

本文转载自Draveness技术博客。

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

创作场景

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