这个给我们带来的启示是什么，云服务本身也是会发生故障的，比如买了云数据库，我们没有办法假设它是 100% 可用的，当它出现问题我们怎么办，是给云厂商提工单说什么时候能恢复，还是我自己能够有一个容灾的方案解决这个问题。从 2015 年开始，我们越来越多地发现，对架构可用性最大的威胁是什么？在市政施工里一定几率就会莫名其妙搞出光缆被挖断等故障，我们不得不考虑，当云服务本身出现问题我们该怎么办。

　　应对措施

所以我们需要有一套面向云的高可用架构。在很早以前有厂商提出类似 SDN 的一个概念，叫 SDI——软件定义基础设施，过去我们发现只有大厂可以做这个事情，设计一套很复杂的管理系统帮他实现，这里放一个路由器，这边放一台虚拟机，可以通过软件的控制流去控制这个东西。但是在云的时代，资源变得很容易获得。以阿里云为例子，可以用 API 随时创建新的虚拟机，新的负载均衡，或者是新的存储，都可以通过 API 随时创建随时销毁，这对于你的基础设施的灵活度非常有好处。

以前有的人会觉得，性能问题或者容量问题应该通过性能优化的方式解决，通过一些黑科技方式解决，加机器会觉得很 low。但我觉得一个问题如果能简单用加机器来解决是很不容易的，意味着对你的整个架构的水平扩展性要求非常高，而且解决效率很高，加机器就解决了，而对一些中心化的系统来说就比较麻烦，加机器都加不了，可能要把机器关掉升配置再重新拉起来。所以我们说，在公有云上面，在资源如此容易获得的情况下要充分利用这个特性，要做一个能够做水平扩展的架构。

那么第一步要做什么，前两年很火的容器、微服务，本质上都是解决了是无状态的应用怎么做自动化的扩容这个问题。右边这个图上面，上面是一个负载均衡，中间是一个前端的服务，后端是一个无状态的后端服务，底层是 MQ、对象存储、数据库这些东西，如果我们能够把前端和后端的无状态服务第一步先容器化，就可以做到当流量过来的时候，只要后端的存储没有问题，整套架构就是能够水平扩展的。

从去年公开的报道和故障来看，很多人有个误会是说云厂商的机器应该是不会挂的，我买了一台云厂商的虚拟机应该是随时可用的，即使不可用云厂商也要帮我解决热迁移的问题，热迁移在业界是很复杂的问题，不光涉及到磁盘存储的迁移，也涉及到内存是要做迁移的，可能还要用 RDMA。并且对于传统的 IDC 来说，不管物理机还是虚拟机都是有可能挂的，对云也不例外。

当我们在使用公有云服务的时候，都是会挂的，这是个心理准备。不光是机器，包括负载均衡是不是也有可能挂，下面的消息队列或者数据库是不是也有可能会挂，当你基于任何东西都可能会挂的前提设计一个系统的时候，才能真正做到这个系统在任何情况下都不会受底层云服务的故障影响。

而对于不同的云服务来说是有不同的容灾策略。比如一台虚拟机挂了，通常来说负载均衡不管是 4 层还是 7 层都会做健康检查，挂了健康检查不通自动会把流量切断。如果我的负载均衡挂了怎么办，如果 DNS 有健康检查那就方便了，如果没有的话可能就要设计一个旁路系统解决这个问题，发现这个已经不通了，就自动把它从 DNS 上摘掉。

不管是云服务发生故障还是自己应用发生故障有个大原则是如何最快速解决问题，就是一个字，切。为什么要做异地多活，为什么要把流量往各个地方引，切流量是解决问题最快的，把坏流量切到好的地方马上就解决了，如果你要等定位问题解决问题再上线客户就流失掉了。对淘宝来说也是一样，当某一个单元低于我们认为的可用性的时候，我们会把这个单元的流量引到另外一个可用的单元，当然前提是那个单元的容量是足够的。

弹性是不是万能的？所有的云服务都是弹性的，弹性其实不是万能的，容量规划仍然是有必要的，不然就没必要做双十一备战了。这里有一个你需要付出的代价，弹性的过程往往是需要时间的，那么容量规划在这个环节中起到的作用就很重要，当真的逼不得已的时候，我要扩容了，怎么保证我扩完容之前系统不雪崩？就是要结合之前的限流，尽可能保障每个客户得到他应有的服务，但是也要保障系统的稳定性。