在过去的一段时间里面，我们经常会听到来自公有云供应商的各种故障报道。每次出现这些故障新闻总是会引起大家的各种讨论。有对公有云发展持怀疑的，有对公有云供应商抱怨的，当然也免不了一些互黑的事情发生。无论您的观点如何，我们都不得不承认如下两个事实：

1.公有云正在各种故障、怀疑声音中一步步向前发展，而且发展速度还在加速。作为IT用户，不管你愿不愿意，你都得面对公有云会进入您日常工作中一部分（甚至是主要部分）的现实。

2.企业IT对于公有云的期待和目前公有云提供的服务能力还是有差距的。这个差距需要公有云供应商持续努力改进，但更要企业IT用户更好理解公有云的设计原则，正确看待公有云产品及服务并基于此设计符合自己业务的架构。

上面两点都是很大的主题，无法在一篇文章篇幅内包括全部。这里让我们关注公有云上系统高可用设计。简单来说，企业云上业务高可用设计需要考虑三个层次上的问题。从下到上依次是 1）云基础设施和服务的高可用性；2）企业业务架构的高可用性；3）企业业务到达客户终端的高可用性。其中，第三点高可用性更多是需要互联网基础网络运营商来保障的内容。在这个领域也存很多如BGP多线接入技术等高可用设计，但整体来说云上企业客户对此的可控度比较弱，这一主题也超出这篇文章要讨论的范围。对于如上第一点高可用，客观来说，公有云服务的可用性比传统IT和私有数据中心已经有了很大的提升，基本都能够提供三到四个九的可用性SLA，但也肯定无法做到100%高可用保障。如果您希望自己业务有更好的高可用表现，就需要考虑企业业务架构的高可用性设计。幸运的是现实生产中已经有这方面的成功案例。例如，在2015年9月，AWS全球最大区域（AWS-US-EAST1）出现20多个服务长达几个小时不可用情况下，Netflix则利用其业务架构上的高可用设计成功保障了业务基本不受影响（具体消息可参考这里）。

两个关键的公有云概念

为了支持云上用户更好使用和部署业务，也为了云厂商能够更加标准化自身服务。公有云供应商在基础设施层面普遍会提供如下几个关键抽象设计：

1.Region（区域）：Region是公有云厂商为一个区域最终用户提供服务的抽象能力。它设计的初衷主要是为了 1）降低云上业务到达最终用户的网络延时；2）符合不同区域的数据及业务服务法规。

2.Avaliable Zone（AZ、可用区）：可用区是一个物理上相互隔离，网络、电力等供应相互独立的基础设施区域，可以简单理解为云基础设施可用性保障的最小单元。不同可用区之间的可用性是相互完全独立，互不影响。需要注意的是可用区同样是一个抽象概念，它并不等同于我们日常所述的数据中心（或者机房）。一个可用区可以由多个物理数据中心组成。

一般来说，公有云的一个Region都会包括多个可用区，以方便用户把自身的业务跨可用区部署，实现高可用架构。云基础设施供应商需要保障的是每个Region内多个可用区之间可用性做到完全独立，不相互影响（但确实无法保障每个可用区都不会出现服务中断）。当然，为让用户业务在多个可用区部署后能流畅运行，公有云供应商都会保障一个Region内的多个可用区之间网络延时极短（一般小于5ms）。真是这一点给可用区选址提出限制，要求一个Region的不同可用区之间物理距离不可以太长。

由上可见，可用区是公有云供应商提供高可用架构的基础，是跨多给可用区部署业务也成为云上业务高可用性设计的核心所在。因此，能否在一个Region内提供多可用区服务成为对云供应商最基本的需求。目前，如AWS、Azure等公有云供应商都基本实现所有Region的多可用区布局，国内云供应商也都在加紧部署这一点。

建议1：请尽量选择有多个可用区的公有云Region部署您的业务，这是实现云上业务高可用的前提条件!

跨Region实现业务的高可用是一种可能的选择。但是Region设计的初衷是为了让基础设施服务尽可能靠近云上业务的最终用户，解决业务延时和合规问题。所以，Region之间的网络延时很多时候不能保障，并不容易用于设计在线业务的高可用。当然，用户数据备份或者容灾处理，跨Region设计是一个可能选择。但是，无论如何，跨Region设计不是云上业务高可用架构的第一要务（优先考虑一个Region内的跨可用区高可用设计）。

公有云服务的可用区支持

即使公有云服务上在基础设施建设阶段提供了一个Region内部多可用区设计的支持，但是如果不能够把这个能力通过公有云的各种服务展现出来，云上用户仍然无法使用到这个能力。一般来说，云服务供应商提供的服务主要包括「计算」、「存储」和「网络」三大类。这里，我以AWS为例来说明它是如何通过产品服务把多AZ能力提供给云上客户，以及云上客户使用它们进行高可用设计的最佳实践。

基础设施云（IaaS）领域的绝大部分服务都支持可用区，并暴露给最终用户选择。但是PaaS层服务（如AWS DynamoDB）可能会直接隐藏掉可用去概念，由云服务供应商在内部实现跨可用区的设计。

计算服务可用区支持:

1.作为最基础服务，AWS EC2服务支持用户指定在不同的可用区创建虚机，并且在不同区域提供对应的EBS盘挂载到用户的虚机上。因此，用户可以自己按照业务调度需求在不同可用区上按需创建虚机，实现业务计算能力的跨可用区部署。

2.ELB是AWS提供的向一组EC2虚机均衡分发业务流量的服务。用户在创建一个ELB实例（其实是一个抽象实例）时需要指定其流量转发的可用区，并且自动实现不同可用区之间的负载均衡。

3.Auto-Scaline是AWS提供的按照业务需求进行EC2虚机水平自动伸缩服务。用户在创建一个AutoScale的Scaling Group时候需要指定在哪些可用区上实现水平伸缩。Auto-Scaling会主动平衡不同可用区内的EC2虚机数量，自动实现不同可用去上虚机数量的大体均衡。

所以，要实现AWS上计算资源的跨可用区的架构，就可以结合如上ELB + Auto-Scaling + EC2的模式，非常直接和高效地实现整个业务的跨可用区高可用设计。例如，下图来自AWS网站托管白皮书上的建议架构

如上图所示，一个website可以分成接入层（Web Tier）、应用层（App Tier）和数据存储层（Data Tier）。其中Web Tier和App Tier都采用了ELB + AutoScaling + EC2的模式部署，实现两个不同可用区的均衡部署，能够保障在其中一个可用区出现故障的时用户业务快速切换到另外一个可用区，最终降低（甚至消除）对于最终业务的影响。

建议2：尽管您可以完全自己控制计算资源跨可用区的均衡部署，但是还是尽可能使用云供应商提供的内建服务。它们会让这个过程变得非常简单，而且可靠。

注意：在如ELB或者Auto-Scaling服务做跨可用区部署虚机或者分配流量时候，一般都是以可用区为最小单元做均衡决策，并且支持自带的健康检查服务。

存储服务可用区支持：

数据存储服务是一个业务的关键所在，也是很多云上架构比较难处理的部分。如前所述，对于部分数据存储服务（如对象存储S3），云供应商已经帮助客户解决了一个Region内的跨可用区处理工作。用户自己无需关注它们的高可用具体实现，只需要通过服务接口（如API）使用即可。但是，对于部分广泛使用数据存储服务仍然需要自己解决跨可用区部署的工作。这其中最为典型的就是云上RDS服务。

1.作为用户使用最为广泛的数据存储服务，RDS服务提供内置的Multi-AZ部署模式。用户只需要指定一个RDS应用实例是否需要在多可用区部署模式。如果选择了该模式，则RDS服务自动会在两个独立的可用区分别启动一主一从两个实例，并开启它们之间的强同步模型。

2.为了提升传统RDS的读取能力，RDS服务还提供“只读副本”功能，并且能够让用户指定创建“只读副本”的可用区所在。再次提供了RDS跨可用区提供服务的能力。

3.Cache集群服务（如Redis、MemoryCache）也同样提供用户设置跨可用区部署节点的能力。用户可以自己指定每个可用区的集群节点分布逻辑，也可以使用Cache集群服务内置的多可用区高可用部署模式自动分配节点的可用区。

如前图所示，在云上部署WebSite时，数据存储层采用主-从架构，并且部署在不同的AZ上。

建议3：为生产环境RDS或者Cache集群开启Multi-AZ部署功能是一个推荐的最佳实践。这样您的数据存储服务就自动拥有了跨可用区的高可用能力，并且在一个可用区出现故障后能够自动切换到另外一个可用区的节点。

可以看出越来越多的数据存储类服务希望向用户隐藏掉可用区设计的概念，并希望在服务内部解决多高可用问题（例如，典型的对象存储服务一般会把数据复制三份，其中两份在一个可用区内，而另外一份则分配到另外一个可用区）。这是一个好的趋势，但是对于继承自传统IT的关系性数据库和Cache集群在目前仍然需要普遍暴露可用区给最终用户，并让用户有能力对其跨可用区部署做合理设计。

网络服务可用区支持：

类似与计算和存储，网络服务也需要提供对于可用区的支持，以方便用户在网络规划阶段实现跨可用区的高可用设计（注意：这里的讨论不包括AWS的经典网络模式）。在AWS中，网络可用区能力的产品载体为“子网（subnet）”

1.网络子网（subnet）是云上虚拟网络（vpc）中的一个虚拟二层网络。一个子网只能在一个可用区内。

2.一个虚拟网络（vpc）可以有多个网络子网（subnet），它们可以分布在一个Region的不同可用区，也可以在相同可用区。

在虚拟网络模式，用户的计算资源、存储资源（如RDS实例）都必须通过指定子网（subnet）来部署到子网所在的可用区上。用户可以通过API或者控制台创建不同子网，实现用户网络在可用区内部的二层隔离。如此同时，子网也成为用户创建各种可用区相关的资源指定可用区的载体。

建议4：为一个应用在不同可用区中创建均衡的子网（包括数目和子网包含的虚拟IP空间）是一个推荐的实践。这样一方面可以实现网络的高可用，另外一方面也方便计算资源和存储资源能够均衡落到不同的可用区。

由于云服务厂商的高可用设计基本是做到不同可用区粒度的负载均衡（而不是不同子网上的负载均衡），所以如ELB、Auto-Scaling这样的服务在分配流量和平衡主机资源都是按照可用区粒度进行。换一句话说，用户在一个可用区创建多个子网并不会导致ELB会向这个可用区分配多于其他只有一个子网可用区的流量，Auto-Scaling服务中的实例放置逻辑逻辑也类似。

总结来说，我们可以看出云服务供应商仅在基础设施层面提供“可用区”设计的支持仍然不够，还需要在更多云产品层面把可用区设计嵌入进去，并尽可能让跨可用区的高可用架构在这些产品上非常容易实现。

用户业务架构的高可用设计

在讨论完如何利用云平台提供的“可用区”进行高可用架构设计后，用户业务高可用设计仍然需要自身业务架构的支持。这是一个和用户业务场景相关性非常大的话题，很难像前面那样给出一些普遍性的具体建议。但是，如下几个设计准则仍然是值得广泛借鉴的。

1.实现业务处理节点的无状态（stateless）化。这是用户业务逻辑实现水平扩展，利用好云平台弹性伸缩的基础性要求。对于业务中需要保持的各种状态数据建议集中存放到云平台提供的高可用缓存或者持久化存储服务中。

2.保持业务处理节点的对等性，不存在单点依赖。用户传统架构中普遍存在中心化节点，这些节点不可扩展且业务服务强依赖于此。这种中心化节点的存在导致整个业务系统的高可用性完全依赖于中心化节点的可用性，也无法利用到云上服务提供的可用区设计。

如上两条设计准则可以大体保证用户业务是一个“云友好”的业务架构，也可以比较容易的使用上可用区设计，实现业务的弹性伸缩。当然，如果能够更向前推进一步，充分解耦业务模块，让其中的任意模块角色足够“小”。这样将让整个业务架构向“微服务”架构靠近，并最终实现“云原生”应用。当然，这个解耦过程带来的服务角色增加和服务状态快速变化也引入新的挑战（例如服务发现、负载均衡和质量保障等）。

写在最后

业务高可用是所有IT生产系统设计都必须考虑的重要指标。云平台（尤其公有云）提出了以“可用区”为核心的基础设施可用性保障新模型，并通过其上层服务提供给云上业务。所以，云上业务高可用设计也同样要以“可用区”为基础进行业务部署架构和逻辑架构的设计，并遵循常见的可水平扩展分布式架构设计准则，以实现“云友好”的高可用设计目标。

作为云供应商，我们希望大家能够普遍重视并尽快提供类“可用区”基础设施能力，并在自己的云服务产品中合理简化“可用区”架构的使用难度，让用户可以低门槛、高效率的实现跨可用区的高可用云业务架构。而不是一再强调自身服务的绝对稳定性和可用性。因为规模运营的云服务几乎无法避免部分可用区服务中断的事故。如果这样，我们更应该尽可能告诉用户如何在业务架构层面实现跨可用区的架构来应对这种“黑天鹅”事故的发生，并为用户高可用架构设计提供产品和服务上的支持。

最后，或许你会说高可用就应该让云供应商完全解决，而不是让用户来操心这个事情。目前，我们也确实在部分PaaS层服务或者数据存储服务上看到这种趋势。但是，当下大量的遗留业务系统以及IT系统的复杂业务要求都让此短时间难以达到。所以，还是让我们立足当下，用好当下云平台的高可用设计，服务好我们自己的客户。