云计算老司机手把手带你搭建业务永续的高可用架构

作者：徐桂林，FIT2CLOUD 技术布道总监。

原文标题：如果公有云故障不可避免，那云上高可用架构该如何设计？

一、不管你愿意还是不愿意，云计算的时代已经到来

不管是对公有云发展持怀疑态度，还是对公有云供应商颇有微词，绝大多数 IT 从业者将不得不承认如下两个事实：

1. 公有云正在各种故障、怀疑声音中一步步向前发展，而且发展速度还在加速。作为IT用户，不管你愿不愿意，你都得面对公有云成为您日常工作中一部分（甚至是主要部分）的现实。
2. 企业 IT 对于公有云的期待和目前公有云提供的服务能力还是有差距的。这个差距需要公有云供应商持续努力改进，但更要企业IT用户更好理解公有云的设计原则，正确看待公有云产品及服务并基于此设计符合自己业务的架构。

客观来说，公有云服务的可用性比传统 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 有多可用区的布局。对企业来说，尽量选择有多个可用区的公有云 Region 部署业务，是实现云上业务高可用的前提条件!

老司机的经验之谈：

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

三、公有云服务的可用区支持

即使公有云服务上在基础设施建设阶段提供了一个 Region 内部多可用区设计的支持，但是如果不能够把这个能力通过公有云的各种服务展现出来，云上用户仍然无法使用到这个能力。

一般来说，云服务供应商提供的服务主要包括「计算」、「存储」和「网络」三大类。

• 计算服务可用区支持: 一般来说，企业可以完全自己控制计算资源跨可用区的均衡部署，但徐桂林建议还是尽可能使用云供应商提供的内建服务。它们会让这个过程变得非常简单，而且可靠。
• 存储服务可用区支持：数据存储服务是一个业务的关键所在，也是很多云上架构比较难处理的部分。越来越多的数据存储类服务希望向用户隐藏掉可用区设计的概念，并希望在服务内部解决多高可用问题。例如，典型的对象存储服务一般会把数据复制三份，其中两份在一个可用区内，而另外一份则分配到另外一个可用区。这是一个好的趋势。
• 网络服务可用区支持：类似与计算和存储，网络服务也需要提供对于可用区的支持，以方便用户在网络规划阶段实现跨可用区的高可用设计。

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

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

这是一个和用户业务场景相关性非常大的话题，很难像前面那样给出一些普遍性的具体建议。但是，如下几个设计准则仍然是值得广泛借鉴。

1. 实现业务处理节点的无状态（stateless）化。这是用户业务逻辑实现水平扩展，利用好云平台弹性伸缩的基础性要求。对于业务中需要保持的各种状态数据建议集中存放到云平台提供的高可用缓存或者持久化存储服务中。
2. 保持业务处理节点的对等性，不存在单点依赖。用户传统架构中普遍存在中心化节点，这些节点不可扩展且业务服务强依赖于此。这种中心化节点的存在导致整个业务系统的高可用性完全依赖于中心化节点的可用性，也无法利用到云上服务提供的可用区设计。

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

写在最后

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

规模运营的云服务几乎无法避免部分可用区服务中断的事故。对云服务供应商来说，非常有必要在业务架构层面实现跨可用区的架构来应对这种“黑天鹅”事故的发生，并为用户高可用架构设计提供产品和服务上的支持。