实现云中高可用性的软件架构

作者:Brian Jimerson

确保在云中实现最高级别可用性和容错的企业应用程序设计。

2012 年 6 月发布

简介

为运行在传统基础架构中的企业应用程序设计容错是一种众所周知的流程,也有多种久经验证的最佳实践能确保高可用性。然而,基于云的架构与基于机器的传统架构有着截然不同的故障形式。

近期许多事件表明,大多数基于云的应用程序在设计时并未考虑到传统数据中心架构,一旦发生不可避免的故障,这些应用程序将无法在基础设施出现故障后保持正常运作。本文探讨了容错设计从基于机器的架构到基于云的架构的某些范式转变,同时探讨了应如何设计企业应用程序,以确保在云中实现最高级别的可用性和容错。

背景

在当今的技术领域中,“云计算”这一术语包含了很多不同的含义。云计算包罗万象,从面向消费者的媒体和文件同步到传统的桌面更换,一直延伸到企业的整个 IT 基础架构。在本文中,云计算指的是以一组服务的形式提供计算、存储、应用平台和软件,用以支持组织的业务应用程序。

这种将 IT 作为服务交付的模式有很多众所周知的好处,也给企业 IT 带来了真正变革的巨大潜力。云计算不再要求 IT 部门分配和管理物理或虚拟机以支持业务应用程序和资源,而是以资源共享和规模经济效益实现的抽象服务集来交付 IT。这带来了多方面的优势。以下是其中一些最主要的优势:

  • 用户自助服务和供应
  • 快速上市
  • 减少运营维护和管理
  • 专注于通过软件实现创新
  • 降低软硬件的资本投资
  • 针对业务线的按需付费模型

应用基础架构具有多个抽象级别,从计算和存储抽象一直到所有应用程序层的抽象。以下是最常见的三种抽象级别:

  1. 基础设施即服务 (IaaS) — 以服务的形式提供计算、存储、网络和类似功能的硬件。IaaS 的实例可追溯至大型机年代。
  2. 平台即服务 (PaaS) — 以服务的形式提供应用程序平台组件,例如应用程序运行时、数据库和消息传递基础架构。Oracle 中间件云服务器 Exalogic、Oracle 数据库服务器 Exadata 和 Oracle SuperCluster 就是用于创建企业就绪 PaaS 的很好示例。Oracle Cloud 公有云产品还提供了平台服务以及 Java 云服务和数据库云服务。
  3. 软件即服务 (SaaS) — 以服务的形式提供核心业务应用程序,如电子邮件、CRM、HCM 和办公 ERP 应用程序。企业 SaaS 的示例包括 Oracle Fusion HCM 云服务、Oracle Fusion CRM 云服务、Oracle RightNow CX 云服务和 Oracle Taleo 云服务。

图 1 展现了这些服务模型的抽象级别。

jimerson-ha-arch-cloud-fig01
图 1 – 云计算服务模型的抽象级别

根据基础架构提供商和物理位置的不同,云部署模型分为多种类型。以下是最常见的三种云部署模型:

  1. 公有云 — 提供商向大众提供的公共云计算资源。一般情况下,提供商利用现有基础设施提供一定规模的云资源供大众使用。
  2. 私有云 — 仅供特定的一组用户(通常是一个组织)使用的私有云计算资源。云基础设施可能运行在组织的物理数据中心或第三方出租的设施中。
  3. 混合云 — 混合云融合了私有云和公有云资源。例如,一个组织可能利用私有云处理日常运营事务,而向外扩展到公有云以满足高峰期的资源需求。

图 2 展示了公有云、私有云和混合云的关系。

jimerson-ha-arch-cloud-fig02
图 2 – 云部署模型

机器故障与云架构故障

在传统的基于机器(物理和虚拟)的架构中,故障往往由硬件和操作系统所导致,而大多数高可用性设计的重点是提供冗余硬件和操作系统来实现容错。例如,集群化应用服务器、主/从数据库复制、冗余网卡和 RAID 磁盘阵列等技术均用于为系统中的可能故障点提供冗余。

请注意,在这种上下文中,基于机器的架构指的是基于传统数据中心或出租设施内的物理或虚拟机构建的系统。这些架构可被视为一组垂直的硬件和软件系统,其中每个垂直分组都是一套硬件或服务器冗余。因此,如果其中的一个垂直分组(应用程序/机器实例)由于某种原因发生故障,其他节点或分组仍然可以处理应用程序的执行。图 3 描述了这种逻辑架构。

jimerson-ha-arch-cloud-fig03
图 3 – 基于机器的应用程序架构

这种架构完全适应传统数据中心和应用基础架构。这些架构的大多数故障均属与硬件或资源相关的故障,通常仅发生在集群的某个节点上。提供物理节点和虚拟节点的冗余能解决其中一个节点因某种故障不可用的问题。例如,在这种情况下,如果应用程序节点 2 的网络接口出现故障,应用程序节点 1 和 3 仍能继续处理负载平衡器的请求。

云计算给企业带来的重大技术转变之一就是云以服务的形式提供。传统的数据中心以离散、原子的形式提供运行时设施,如应用服务器和数据库。然后将这些离散的原子单元汇集到一个逻辑集群中,让每个单元或节点都知晓集群中其他成员的存在。

而云架构却与此截然不同。云架构旨在抽象存储、数据持久性和运行时依赖性等特性。此外,云架构还需提供较高水平的多承租方功能和可伸缩性。

为了应对这些挑战,基于云的架构更趋向于采用一组横向逻辑服务层,它们彼此交织,形成了构成应用程序的组件网。这些横向层并不是硬件实例,而是由云基础设施提供的服务区域。这些横向层可以是 UI 层、业务逻辑层、NoSQL 数据层、RDBMS 数据层等。图 4 展示了对比的逻辑云架构。

jimerson-ha-arch-cloud-fig04
图 4 – 基于云计算的应用程序架构

这种横向服务结构为基于云的应用程序提供了近乎无限的可伸缩性、按需服务、性能和成本效益。然而,它也极大地改变了应用程序中发生的故障类型。基于云的架构中的故障通常涉及一个或多个横向结构,而不是纵向硬件节点的故障。再多的硬件冗余设计也无法避免这种类型的故障。相反,云架构需要采用不同的方法来进行容错设计。

云设计的注意事项

考虑到云架构中最有可能发生的故障类型,本文后续部分将重点讨论可能会对云计算的容错能力和高可用性产生根本性影响的设计注意事项。

多个区域

在云计算中,“区域”指的是在物理上彼此隔离的云计算资源组。这就提供了冗余云计算设施,可将应用程序部署到其中。在为云设计容错时,最有效、最简单的方法之一就是为应用程序使用多个区域。云中的故障往往涉及某个给定区域内的一整套服务;例如,东区的数据库服务完全瘫痪,所有用户均无法使用这些服务。如果某个服务分布在多个区域中,该服务的用户即可故障切换到其他区域。

这种方法会增加应用程序和配置的复杂性,但也能解决云计算中常见的一类故障。为了实现这种方法,服务用户必须能够动态访问不同的云服务端点。

分布式数据管理平台

随着基于云的架构得到采用,像 Oracle Coherence 这样的分布式数据管理平台也受到了广泛欢迎。分布式数据管理系统是一种高度可伸缩、低延迟、分布式和复制的数据系统。这些系统旨在提供以内存速度访问数据的能力,能够全局地执行数据自动分片和数据复制,同时也通过对等集群实现了庞大的规模。

云架构中有许多使用情形能受益于 Oracle Coherence:

全局数据复制
地理分布区域所面临的挑战之一就是数据必须可用于所有区域。通常情况下,调用地理距离较远的数据库时,速度极为缓慢,成本极其高昂。典型的做法是在两个区域之间复制数据。但是这会造成大量不同步的数据,通常也需要连续复制大量数据。

为了解决这一问题,Oracle Coherence 等产品采用了一项称作“分片”的技术。通过分片,一个数据集将被划分成多个较小的部分,并分布于一个大型集群内;这样,即使某个节点发生故障,整个数据集也能实现重建。这意味着,在任何时候跨区域内复制的只有那些很小的数据块,而完整的数据集在本地区域中将始终保持可用。

事件驱动的通知
很多基于云的现代应用程序都需要向客户端传递事件驱动的通知,无论此类客户端是最终用户应用程序还是其他外部应用程序。例如,在社交网络应用程序中,如果一名最终用户的朋友发布了一条信息,就可能需要向该用户发出通知。实现这种需求的典型方法是从客户端定期轮询服务器端资源来获取更新。

然而,这种服务器端资源的轮询操作代价极高,因为即使没有信息更新,服务器也需要不断响应各客户端。Oracle Coherence 提供了一项“连续查询”特性,用以满足这项需求。客户端可以向 Coherence 注册一项查询,一旦查询结果发生改变,Coherence 即可通知客户端。这就缓解了通常必须由服务器端资源承担的轮询负担。

客户端缓存和脱机访问
基于云的现代应用程序的主要特点之一就是必须支持的最终用户渠道的数量。例如,现今很多业务应用程序能同时支持 web 浏览器、平板电脑和其他移动设备,甚至还能支持胖客户端。很多最终用户设备通常处于脱机模式,或者使用带宽较低的网络连接。这意味着应用程序的设计必须考虑到对云资源访问受限或速度缓慢的情况。

Oracle Coherence 等产品能解决这样的限制。Coherence 使用对等、分片集群机制,可以在客户端设备上安装 Coherence 节点,以提供应用程序数据的本地缓存。客户端仍然可以通过本地缓存访问应用程序数据,而一旦客户端处于联机状态或者使用更高带宽的连接时,缓存即可得到更新。

完美降级

基于云的分布式应用程序应假设其系统中的某个部分不可用。这种“不可用”并不是意味着整个系统无法使用。在做功能需求时应考虑到此类服务中断,并确定可能发生故障的交互点。同时还要考虑故障的后果,确保系统的其余部分保持正常工作。这种概念就称为“完美降级”。

举例来说,假设一个应用程序允许用户通过各种客户端(包括移动设备和 PC 在内)在线查看和购买音乐,则此系统的用户应可在所有设备上执行以下功能:

  1. 搜索艺术家
  2. 查看从第三方网站上收集的专辑和艺术家信息
  3. 预览专辑曲目
  4. 查看艺术家的社交网络活动
  5. 购买专辑曲目

现在,我们假设由于某种原因,专辑和艺术家信息不可用。原因可能是移动设备的网络带宽受限,或者一个或多个服务停止。这种情况不应导致整个系统无法使用,更不应该出现更糟的情况 — 向用户显示一条错误消息。相反,做需求时应考虑到可能发生的每一种故障。在这种情况下,应当向用户发送一条消息提示该服务暂时不可用。但用户应仍然能够预览和购买专辑曲目。

异步消息传递

异步消息传递是设计传统应用程序时的一项公认准则。它促进了系统组件与交互的松散耦合,确保长时间运行的进程不会影响用户体验。

在基于云计算的应用程序中,这些准则甚至更加重要。正如前面所提到的那样,云应用程序在逻辑和地理上都有着高度分布式的特点。通常,它们还支持大量不同的客户端。在适当的情况下,在这些分布式组件之间使用异步消息传递有助于确保这些组件不会不必要地依赖于其他组件的可用性、端点的紧密耦合、网络延迟或者其他因素。

在使用异步消息传递时,可以利用 Oracle WebLogic 12c 这样的产品。WebLogic 中的消息是持久性的,由持久消息存储提供支持;如果发生故障,可以恢复和重新发送消息。此外,消息传递寻址将在 WebLogic 内集中管理,从而缓解应用程序的负担。

原子和幂等服务

构成云应用程序的服务应始终设计为原子服务和幂等服务。根据定义,原子服务是指其功能从逻辑上不能进一步拆分的服务;换句话说,其责任范围已经达到最小。幂等服务是指确保可以安全地多次调用的服务,且不会影响调用结果;客户端可以充满信心地反复调用幂等服务,而不会导致意外后果。

原子性和幂等性这两种补充特征有助于确保服务中断后的恢复。客户端可以多次安全地调用原子和幂等服务,直至获得满意的结果;同时也可以安全地调用一个原子和幂等服务的多个实例;即使其中一项服务完全不可用,也能恢复服务的正常功能。

举个关于原子和幂等服务的例子,设想某个应用程序使用一项信用卡处理服务。为保证原子性,该服务只能执行付款处理,并且应该只需要处理付款所需的数据。它不应执行其他任务,例如更新用户更改后的账单地址。如果这项服务变得不可用,原子性能够确保将功能损失降到最低。

为保证幂等性,服务应能进行多次调用。如果传递的是相同的数据,服务不应重复收取信用卡费用。如果在另外一个区域中调用服务,幂等性能确保在服务恢复可用时不产生意外后果。

总结

容错和高可用性是所有企业应用程序的必要属性,任何系统停机都意味着收入的损失和利益相关者信心的下降。

鉴于容错是应用程序取得成功的重要条件,有必要在实施的过程中予以最优先的考虑。但是,习惯于传统数据中心架构的架构师和工程师必须转变工作重心,从注重硬件和操作系统冗余转为以软件为导向的高可用性特征之上。

IT 即服务带来了对软件和创新的密切关注,也能减少和消除底层计算平台的问题所产生的潜在影响。然而,未能关注软件应用程序的容错能力可能会产生破坏性的影响。为了发挥云架构的全部潜力,必须密切关注云计算的这个方面。


Brian Jimerson 是俄亥俄州克利夫兰 Avantia, Inc. 公司(这是一家自定义解决方案提供商,同时也是 Oracle 金牌合作伙伴)的一位高级技术架构师。他专门研究中间件和 Web 基础架构解决方案、企业集成模式与实践以及企业方法。小 LinkedIn 图标