云端架构的本质是资源池化，然后按需申请。这里”按需“既包括业务上需求的弹性伸缩，也包括抵抗故障的灵活负载。

云上的故障

云端的服务仍然是也可能出故障的，只是概率上的不同而已。这也是云供应商们为云服务引入服务等级协议（Service Level Agreement，简称 SLA）的原因，它主要是用来对服务的可靠性作出一个预期和保证。SLA 的可用性等级可能是 99.9%，也可能是 99.99%，它能够表明某项云服务在一段时间内，正常工作的时间不低于这个比例，也代表了厂商对于某项服务的信心。但是 SLA 里有再多的 9，也不可能达到理论上的 100%。

小提示：当实际产生的故障，未达到 SLA 的要求时，云厂商一般会给予受到影响的客户以消费金额一定比例金额的赔付。不过很多时候，赔付的金额不足以覆盖业务上的经济损失，你不应该依赖它。

从架构思维的角度上来说，我们需要假定故障就是可能会发生，对于它的影响事先就要做好准备，事先就进行推演并设置相关的冗余和预案。AWS 有一个非常著名的架构原则，叫做 Design For Failure。换而言之，就是”面对故障，提升冗余“。

那么，云上可能出现哪些不同层面的故障？下面我们从小到大，依次来看我们可能遇到的问题和解决办法。

第一种故障是在宿主机的级别，这也是从概率上来说最常见的一种故障。

我们需要保证多个虚拟机不在同一台宿主机上，甚至不处于同一个机架上，以免这些虚拟机一起受到局部事故的影响. 虚拟机的排布看似是一个黑盒，但其实在公有云上是有办法来对虚拟机的物理分配施加干预，让它们实现分散分布，隔开一段距离的。这一特性，在 AWS 称为置放群组（Placement Group），Azure 称为可用性集（Availability Set），阿里云对应的服务则是部署集。比如说，我们对阿里云同一个可用区内的虚拟机，在创建时选择同一个部署集，就可以保证相当程度的物理分散部署，从而最大限度地保证它们不同时出现故障了。

第二种规模更大的故障，是在机房层面（数据中心），也就是可用区的层面。 这种情况可以通过多可用区的实例部署来实现备灾。

第三种更严重的故障，就是整个区域级别的事故了。

当然这种一般非常少见，只有地震等不可抗力因素，或者人为过失引发出的一系列连锁反应，才有可能造成这么大的影响。区域级别的事故一般都难免会对业务造成影响了。这时能够进行补救的，主要看多区域架构层面是否有相关的预案。如果是互联网类的服务，这时最佳的做法，就是在 DNS 层面进行导流，把域名解析到另外的一个区域的备用服务上，底层的数据则需要我们日常进行着跨区域的实时同步。

第四种故障是云服务商整体出了问题，这种情况很极端，但是不是没有。如果有需要就要考虑”多云“，即在多个云部署实例，但是对于成本和技术都有更高的要求。

上云的时候一定要根据业务需求，在成本投入与可用性之间获得一个最佳的平衡，才是我们应该追求的目标。

云上伸缩

弹性伸缩，这是云上架构的另一个原则，也是云端的重要优势。

云的本质是租用，而且它便捷的操作界面、丰富的 SDK 和自动控制选项，使得云上“租用”和“退租”的成本很低，可以是一个很高频的操作，这就为弹性伸缩在云上的出现和兴起提供了土壤。在妥善应用之下，弹性伸缩既可以提高工作负载洪峰来临时的吞吐和消化能力，提高业务稳定性，又能够在低谷期帮我们显著地节约成本。

在 IaaS 端，能够弹性伸缩的最实用的产品形态，莫过于虚拟机编组了，也就是功能相同的多个虚拟机的集合。把它们作为一个单位来创建、管理和伸缩，是一种普遍应用的最佳实践。AWS 中相关的产品命名是 EC2 自动伸缩（Auto Scaling），Azure 中是虚拟机规模集（VM Scale Set），阿里云则叫做弹性伸缩。

弹性伸缩服务，会帮我们动态地创建和销毁虚拟机实例，自动根据我们指定的数量和扩缩容规则，来协调虚拟机的生命周期。

负载均衡器。它特别适合将流量均匀地，或者按照一定权重或规则，分发到多台虚拟机上，正好可以和提供计算资源的弹性伸缩服务形成配合。当负载增大、虚拟机增加时，负载均衡也能够自动动态识别，将流量分发到新创建的虚拟机上。

所以，我们可以尝试使用弹性伸缩服务来实现云端弹性架构，用它来管理一组虚拟机，并与负载均衡一起配合。这特别适合处理无状态类的计算需求，因为它会为你代劳底层计算资源的管理。

以阿里云为例，下面就是在创建一组弹性伸缩服务。这里配置告诉伸缩组何时进行自动扩缩容，比如图中我们选择监控平均 CPU 指标，我们希望理想状态下控制在 50% 左右。换句话说，如果平均 CPU 偏离 50% 太远，系统就会自动地为我们增加或减少机器。

img

需要注意： 弹性伸缩服务创建的实例要依赖已经创建好的镜像。

云上运维

”上云“不但没有消灭运维，反而是助推了运维的发展。

这是因为，云的引入能够让我们在更高的层面去思考和解决问题。比如说，云端基础设施的存在，可以让运维从偏硬件服务器、偏物理机房的日常繁琐工作中解脱出来，更多地基于云在软件的层面，进行部署、监控、调整。而云上的高质量、高可用的服务，也能避免我们重复建设，不用自己造轮子，也大大减轻了运维负担。

所以，云其实是提高了运维的效率，改变了运维的形态。与此同时，由于云上运维的软件属性显著增强了，它就自然地和研发会有更强的融合。近期 DevOps 理念和云原生热潮的兴起，就说明了这一点。许多工作，你慢慢地会分不清它究竟是属于运维还是研发，因为两者的界限正在模糊。

云其实是提高了运维的效率，改变了运维的形态

举个例子，如果你要频繁地在云上部署一套包含众多资源项的复杂系统，你需要一个得力的帮手：资源编排类云服务。属于这个领域的服务包括有 AWS CloudFormation、 Azure 的 ARM Template、阿里云资源编排服务（ROS）等等，它们都可以通过使用一个 JSON 格式的文本文件，来描述和定义一个系统中所有的组件，以及它们互相之间的关系。这个 JSON 文件，就是一个可以自动部署、可复用的单元了。这其实就是“基础设施即代码”（Infrastructure as Code）理念在云端的实现。 这个概念和K8s中资源对象声明的YAML很像。

这类资源编排服务，理论上能够支持云上所有服务的组合，而且配置节点互相能够引用，功能十分强大。它还具有一定的灵活性，一般都有输入参数字段，允许你在部署时动态决定一些选项和参数值，还可以自定义结果输出字段，方便部署完成后告诉你一些结果信息。在这类资源编排部署系统的帮助下，我们云端部署类的工作可以得到极大的自动化，通过研发程序即可实现。

云运维由哪些工作组成？

首先，在云端，传统的运维工作仍然存在，其中包括你所熟知的监控、部署、升级、备份等等。只是操作手段会有所不同，比如在云上，我们可以利用前面说到的命令行工具和资源模板来进行部署。

1. 监控：几乎所有的云端服务都自带有一定的监控功能，默认提供了不少内置的维度指标和可视化图表，这些开箱即用的图表你要充分利用好，它们能够很好地帮助你了解相关服务的状态。或者使用Prometheus / Skywalking 等第三方监控工具，进行自定义设计。
2. 备份：即便是在云端，尽管云厂商已经做了许多如三副本之类的防护措施，但还是会存在出故障的可能，所以我们仍然需要做好备份，尤其是重要数据的备份。总之，我们在云上需要创造多层次的冗余，而备份在创造冗余方面也承担着重要的角色，有的时候，它会是我们的最后保障，所以我们要善于使用镜像和快照。
3. 迁移：只要不是在云上创建的全新业务，传统业务在逐步上云的过程中一定会面临迁移工作。在迁移的过程中切记操之过急，要逐步迁移，以便遇到问题而有回滚的余地；同时要尽量使用官方的迁移工具，避免自己误入歧途。
4. 管理：云上运维会具有很强的管理属性，这里的管理，指的不仅仅是对云上资源的管理，更要深入到流程和制度的管理层面。比如对于云资源的命名、开通、清理等日常操作的规范。这些都需要有效的管理手段，才能避免资源在云上的野蛮生长。

高明的云上运维，既要为应用开发赋能，要足够高效，也要有适当的管理和约束。我们团队的组织架构和分工，最好也能够配合和适应这个需要