PaaS 环境的软件设计模式

了解架构设计模式，以管理特定于平台即服务 (PaaS) 环境的非功能性需求 (NFRs)。了解 Codename:BlueMix（IBM PaaS 云操作环境）的技术特征，看看 Codename:BlueMix 如何为可靠、高度可用且可扩展的应用程序的设计和创建提供支持。

备注：Codename:BlueMix 是一款 beta 级产品，随着我们不断让功能更加完善和更易于使用，它也将不断改进。我们将竭尽全力保持本文最新，但它并不总是完全跟上现状。感谢大家的理解！

有效的、创新性的应用程序甚至都有可能被破坏或在市场上遭遇失败，因为它们无法满足性能、响应时间和总体可靠性等 NFRs。在传统上，架构师通过修改基础架构的形状和大小来响应 NFRs。并发用户数量通过将用户会话分区到多个并行运行的系统上来处理；响应时间可通过消除性能瓶颈（常常在数据库和存储使用上）来改善；服务需求通过添加能够快速执行大容量事件记录的新服务来满足；等等。但在云环境中，架构师管理 NFRs 的方法方面的选择更加有限。

云基础架构即服务 (IaaS) 平台使得基础架构的修改更经济、更轻松（这解释了 IaaS 环境在快速变化、快速扩展的工作负载中流行的原因），而且架构师的选择也相应地减少了。云平台即服务 (PaaS) 环境在此范例上更进一步，从用户角度讲消除了水平扩展、组件放置、日志记录和系统管理。这些操作都会发生，但作为 IT 架构师，您无法控制（或几乎无法控制）它们。

但是，架构师对 NFR 的管理不会在云环境中消失。相反，它们转移到了应用程序的内部机制中，转变为了一些应用程序设计模式。这些模式的实现可确保云应用程序是云操作环境 (CloudOE) 中的 “良民”，它们不会连接 CloudOE 机制并与 CloudOE 的工作方式保持一致。本文将介绍它们在 PaaS 环境中解决的 NFRs 模式和类型，还会介绍 IBM Codename: BlueMix，这是一个开放标准 PaaS CloudOE，您可以在其中让设计模式生效。

NFRs 和应力案例

功能性需求和非功能性需求在概念上不同。二者都表示定义的系统的利益相关者或影响者的动机。随着 IT 技术和角色的演变，软件系统会继续增加利益相关者的数量和他们的请求的复杂性。除了系统的用户之外，利益相关者和它们各自的需求包括：

开发人员：代码的结构和清晰度

维护人员：记录和调试工具

测试人员：跟踪和提供的其他问题判定工具

提供商：应用程序使用培训的简单性

运营商：提供的信息水平

运营经理：解决方案的可伸缩性

配置管理专家：支持的中间件包装和级别

数据库管理员数据库资源使用和优化

服务经理：监视操作所需的技能和工作

网络和系统管理专家：支持的工具

企业架构师：与公司标准架构的合规性

安全官员：实现的安全类型

采购人员：解决方案的可伸缩性和适应性

评估人员：审核工具

支持人员：用户操作的复杂性：

沟通人员：界面的清晰性

这种情况考虑了具有困难的功能性需求和严苛的 NFRs 的复杂系统，这些 NFRs 包括非常高的可用性、快速的性能和挑战性的安全需求等。云计算还增加了对极高的灵活性和地理分散性的需求 — 随时随地都可用。

IT 架构师如何确保系统的架构能够令人满意地包含了所有这些需求？这里的危机在于，需求的解决是相互隔离的，没有考虑到一种需求的解决可能对其他需求带来什么样的影响。

要从整体上考虑需求，可将它们构想为相对的 “力（force）”，如图 1 所示。IT 解决方案可能以最优方式解决这些力。

图 1. 需求是相对力

在图 1 中，这些力量包括：

1.功能性需求

2.我们在 IT 系统上施加的质量需求和约束 (NFRs)：

1)运行时质量

2)非运行时质量

3)业务约束

4)技术约束

特别重要的是可能在任何给定时刻一起运行的相对力的组合。此外，一些同时作用的力也会相互加强。也就是说，它们的影响会增加系统的特定部件上的应力。举例而言，大量并发用户与发生错误后较短的恢复时间相结合，可能在系统发生故障后给用户识别子系统带来压力，从而导致产生大量操作和实际阻止操作运行。类似地，严格的响应时间和具有有限资源的数据库相结合，可能带来无法处理的请求组合，除非应用程序是专为处理它而设计的（举例而言，通过使用缓存机制）。就像在土木工程中一样，我们使用词汇应力案例 来识别这些同时作用、相互加强的力。

云提供商的服务水平协议 (SLA) 是解决方案的需求（约束）之一，可能影响应力案例。例如，如果 IaaS 合同指定了一定容量的虚拟网络，托管应用程序的内部吞吐量上的这种潜在约束可能需要特定的机制来实现外部吞吐量目标。

有时，一种应力案例可能使得无法同时满足所有需求。在这些情况下，可能必须设定一组更加受限的需求，以便为用户维护合理的服务水平。我们将这些案例称为降级的操作。降级的操作在云应用程序中可能无法避免，所以小心地设计它们并在它们出现时与用户沟通很重要。

降级操作的一个简单、普遍的示例与分片数据库的最终一致性 机制由关。这些数据库在云中提供了多个读取实例来确保性能和可靠性，而特定数据元素的写入始终在同一个实例上完成（为了保持写入一致性）。因为复制新数据所花费的时间有限，所以某个数据库实例中的信息可能在读取时不一致；它只是最终 一致的。使用最终一致的数据的应用程序必须能够支持降级的操作，通过做笑话用户感知到的不一致性（例如，通过显示仍在缓冲区中，还未提交的更新），或者（如果没有活动数据可用）通过在数据库最后更新时提醒用户。

一个示例

为了帮助解释如何处理 CloudOE PaaS 环境中的 NFRs，我们将基于虚构的 AMGRO.cloud 公司开发一个示例，这家零售商通过获取佣金的独立兼职销售人员网络来销售其商品。

AMGRO 决定通过提供一个目录来购买应用程序，开始进入在线销售市场。为了加速部署，AMGRO 计划在一个云提供商的 PaaS 环境中开发了该应用程序（该提供商将提供 Web UI、安全服务和访问控制），并且链接到在交付服务和支付服务方面的市场领导者的在线服务。新应用程序还必须与现有的 AMGRO 企业资源规划 (ERP) 平台相集成，以便用于会计和仓库管理。

AMGRO 的新应用程序的 NFRs 包括：

1.并发用户数量预计约为 10,000。

2.所有目录视图预计在常规 ADSL 连接或高速蜂窝网络上只需不到 1 秒即可获得。

3.AMGRO 的云环境和支付服务预计具有 24x7 的可用性。

4.AMGRO 和交付服务提供商通过常规的 Internet 连接。

对交付服务请求的响应具有 2 小时的承诺 SLA。此外，交付服务的可用性目标在晚上、他们执行系统维护期间有所不同。出于合同原因，此 SLA 不应更改。

因为新的 PaaS 应用程序将连接 AMGRO ERP 系统，所以此接口是高度敏感的，必须得到足够的保护。

图 2 演示了 AMGRO 示例。（此图和本文后面的大部分图都采用了 TOGAF ArchiMate 概念。）

图 2. AMGRO 示例

在 AMGRO 的系统中，以下 NFR 组合一定属于应力案例：

案例 1：亚秒级响应时间，但系统加载了：

10,000 个并发用户

亚秒级响应时间

案例 2：亚秒级响应时间，但外部系统缓慢或不可靠：

亚秒级响应时间

通过常规 Internet 连接交付和支付服务

案例 3：应用程序应该是可用的，但外部系统是异步的，或者具有不匹配的 SLA：

24x7 可用性

Internet 连接

可用性 SLA 不匹配

离线流程

案例 4：混合云：

安全的连接

PaaS 应用程序、NFRs 和架构师的角色

一个基于云操作环境的 PaaS 解决方案会利用 CloudOE 编程模型来管理 NFRs，为应用程序架构师减轻了一些任务：

在水平范围上管理用户负载：CloudOE 根据工作负载在虚拟机中添加和删除组件实例，从而进行进行相应调整。应用程序架构师不再需要处理可伸缩性，但现在必须理解哪些组件必须同时扩展，以及如何管理通信的组件之间的不同扩展水平。

为关键的路径利用最新的技术：在内部部署的解决方案中，架构师在系统的关键部分（数据库、消息主干网等）中利用了最新的技术。在云计算中，您采用了标准技术并拥有有限数量的基本选择。消除了硬件或软件技术上的不一致，但关键的路径必须通过设计模式来处理。

通过放在同一位置可消除性能瓶颈：将具有高交互程度的工件相邻放置，是一种改善性能的常见做法。您仍然可以对 CloudOE 中的应用程序这么做（假设这种捆绑不会妨碍水平扩展），但您可能无法控制具有多个分布式副本的应用程序和技术服务（例如 MongoDB）的协同定位。

控制 SLA：在 CloudOE 中，没有应用程序是孤立的。出于增强系统总体可靠性的用途，涉及的组件可以在任何地方。另一方面，（应用程序）本地的云提供商提交的 SLA 可能与不同云平台上的另一个连接的组件提交的 SLA 不同。应用程序架构师无法假设具有统一的 SLA，必须考虑响应丢失或延迟的可能性。

PaaS NFRs 管理模式

如果绘制 PaaS 的 操作上下文图，我们可确定 4 种类型的外部角色：

应用程序本身的用户（应用程序服务的使用者）：这些角色同行具有与应用程序的响应时间和可用性相关的需求。此外，由于并发用户数量的不同，典型的云应用程序常常具有无法预测的复杂性。

外部系统：这些是云外部的物理系统，不在应用程序架构师的控制之下。

事件驱动的服务：一些服务可能实现长期运行的流程或一个异步接口。

内部部署的系统（混合服务）：内部部署系统的云组件和内部组件都在应用程序架构师的控制之下，因此架构师可根据 NFRs 来调节它们。

与 4 种 PaaS 角色对应，我们确定了 4 种与 NFR 相关的设计模式：

无状态应用程序模式，管理用户数量的扩展、高可用性和对短响应时间的支持，甚至在系统具有负载时亦可执行此操作。

异步应用程序模式，在长期运行的服务需要参与应用程序流程时，管理响应时间和持续可用性。

外部 API 模式，在流程流涉及到外部系统时管理高可用性和扩展。

安全 VPN 模式，安全地集成内部部署的系统。

图 3 演示了 4 种模式和它们与 4 种角色的关系。

图 3. PaaS 模式

无状态应用程序模式

无状态应用程序模式的目标是，确保系统可同时扩展，服务大量请求并保持执行路径尽可能短。图 4 演示了无状态应用程序模式。

图 4. 无状态应用程序模式

使用的基本机制是 CloudOE 水平扩展功能。水平扩展功能通过执行环境实例的动态打开和关闭，以及系统级路由器/平衡组件来提供。

要高效地使用动态扩展，应用程序组件必须完全是无状态的。通常在传统的 Web 应用程序中，所有来自某个用户的请求都会路由到同一个应用服务器实例，该实例会将会话数据和对话状态保存在内存中。会话 cookie 被用作从内存检索会话数据和处理请求的密钥。在云计算中，大多数托管云实现都无法保证，是同一个应用程序实例将为一个会话服务。会话请求必须由面向 Internet 的路由器路由到不同的应用程序实例。因此，在此模式中，要保持执行实例完全无状态，会在外部使用内存存储，并作为服务在托管云提供的所有实例之间共享。（否则，在一个实例的所有会话关闭之前，不可能进行向下调整。）

异步应用程序模式

异步应用程序模式用于解决方案的事件驱动部分，一般在同步响应不可能实现也未想到时使用。图 5 演示了该模式。

图 5. 异步应用程序模式

该模式包含一个无状态异步业务服务（也称为工作应用程序 (worker)）池，这些服务从一个队列中获取作业，执行它们，然后将结果存储在一个（SQL 或 NoSQL）数据库中，供其他模式（例如无状态应用程序模式）使用。作业是一个独立的命令和上下文集合，另一种模式可使用它与工作应用程序通信。作业通常由前端应用程序放在队列中。流程的结果存储在数据库中，以便前端应用程序可避免扫描队列或等待队列关联 ID。

可同时存在多种工作应用程序类型、多种作业类型和多个队列，每种都有一定的特殊性。因此，使用不同的队列，可使用模式按正确的顺序执行一组活动。首选的数据库是一个最终一致的数据库，它可能拥有本地副本，但它至少对读取操作是一致的。具有单一实例的 SQL 数据库仅在 ACID（原子性、一致性、隔离性、耐久性）他特征很重要时使用， 例如，在执行信息传输操作时，比如在执行银行帐户上的借贷操作时。

外部 API 模式

在您必须将一个外部（CloudOE 外部的）系统（例如，一个基于 IaaS 应用程序）集成到您 PaaS 解决方案中时，外部 API 模式很有用。在这种情况下，您可以假设外部系统发布了一个您通常所依赖的 SLA — 使用 “通常” 这个词是因为模式的准确用途是让您的应用程序远离外部应用程序可能拥有任何 “执行故障”。图 6 演示了此模式。

图 6. 外部 API 模式

该模式可通过在为您的（和其他）应用程序服务的 API 实例时间缓存活动数据来提供支持。以 AMGRO 场景为例，过去 24 小时内从外部支付服务收到的支付尝试或确认信息可缓存，以便在 AMGRO.cloud 用户请求最近发生的支付列表时无需访问外部服务。

公共服务 API 通常可帮助客户实现缓存机制，填充标准的 HTTP 响应标头：Cache-Control、Expires 和 ETag。例如，使用此标头，刷新内容只有在太平洋时间 2014 年 8 月 30 日（星期四）14:56:34 之后才会收到：

Cache-Control: public
Expires: Thu, 30 Aug 2014 14:56:34 GMT

使用此标头，收到的内容会缓存 868 秒，然后才会发出另一个 API 请求：

Cache-Control: max-age=868

安全 VPN 模式

安全 VPN 模式（如图 7 中所示）是外部 API 模式的一个变体。安全 VPN 模式旨在满足将云上的组件与内部部署的组件（例如一个现有的记录系统，如 “设计一个 SoE 生态系统来支持富用户体验”中所述）的需求，这是混合云应用程序中的典型需求。

图 7. 安全 VPN 模式

此模式背后的假设是，您可同时控制两种环境，进而比外部 API 模式更好地控制累积 SLA。

系统的内部部署部分将依赖于传统的架构模式，比如集群，以确保可伸缩性和可用性（裸机和 IaaS 解决方案都是如此）。云端惟一值得注意的加载项是活动数据的缓存（用以减少流经高开销 VPN 渠道的通信）。

VPN 渠道是该模式的核心，因为它在应用程序的两部分之间建立了受信任的通信。出于这个原因，除了标准 CloudOE 防火墙之外，PaaS 应用程序还使用了一个软件 VPN 功能（由 CloudOE 以服务的形式提供），该功能对应于内部部署端的一项类似（硬件或软件）功能。

ACID 和最终一致性数据库模式

事实上 CloudOE 同时提供了 SQL ACID 数据库服务和 NoSQL 最终一致性数据库服务，严格地讲，这不是一种设计模式。但我们在这里包含了它，因为这种灵活性对 PaaS 架构师很重要。图 8 演示了这种 PaaS 特性。

图 8. ACID 和最终一致性数据库

SQL 数据库可保证操作按一种顺序执行，无论有多少用户在使用该服务。这是通过锁定资源来执行的，所以更新冲突不可能发生。一次读取会返回一个字段的最后一个值或倒数第二个值（而且想要的行为通常可由用户自定义）。在缺陷方面，锁定机制限制了活动实例数量（因为多种多对多副本很快会变得无法管理）或需要一个具有单一中央锁定表的数据库 — 整个系统的单点故障。

NoSQL 数据库（比如 MongoDB）为本地写入维护着相同的规则，但会将这些写入操作复制到多个分布式副本上。如果一个副本失败，其他副本会接管它的客户端。复制无法立即进行，所以一个副本上的读取操作可能返回到苏第 n+1 个值。副本最终会保持一致，但我们不知道具体时间。最终一致性是一种强大的扩展机制，适用于易变性较低的数据，因为本地读取比远程读取快得多。例如，来自工作应用程序的结果（通常写入一次且从不更新）是放入最终一致的数据库上的很好的候选数据。相反，一些（或许是大多数）高易变性数据需要 SQL 数据库的 ACID 属性。

Codename:BlueMix：一个 PaaS CloudOE

CloudOE 和参与型系统

我们在上一篇文章 “设计一个 SoE 生态系统来支持富用户体验” 中，将 CloudOE 的概念介绍为现代参与型系统 的支持性技术。

CloudOE 的成功的一种度量方式是，它帮助前线开发人员快速编写旨在验证业务想法的敏捷应用程序的能力。我们将通过一个示例大体介绍一下 IBM CloudOE（Codename:BlueMix)，探讨 Codename:BlueMix 的一些简化了响应式、可扩展、高度可用、高度可靠 且安全 的应用程序的开发的特征。

Codename:BlueMix 构建于开源的 Cloud Foundry PaaS 技术之上，它从该技术集成了一些重要概念，比如应用程序、服务、组织、空间 和构件包。如果不熟悉这些概念，不要担心。我们将借助（图 9 中描绘的）一个以云为中心的典型应用程序的蓝图，帮助您了解这些概念。

图 9. 一个 PaaS 应用程序

了解 Codename:BlueMix

要从 Web UI 中了解 Codename:BlueMix，使用您的 IBM ID 登录 并创建第一个应用程序。

随后，您可能希望评估多个访问 Codename:BlueMix 的接口：

1.Web UI

2.Cloud Foundry 命令行，它可直接从 Web UI 下载

3.一个可从 Eclipse 下载的 Cloud Foundry Eclipse 插件

可使用 Orion 在线编辑代码并将其推送到 Codename:BlueMix。可将代码托管在 JazzHub 上并将其推送到 Codename: BlueMix。

我们使用词汇以云为中心的应用程序 来表示一个为在 CloudOE 中运行而构思和设计的系统。这样一个系统通过可通过 Web 访问的 GUI 为用户提供了价值（图 2 中的 Presentation Web 应用程序）。它也可向其他系统提供服务，在此情况下，您可能发现使用具象状态传输 (REST)/JavaScript 对象表示法 (JSON) 接口来设计另一个 Web 应用程序（图 2 中的 Application services Web 应用程序）会很有用 — REST/JSON 比 HTML 页面更适合系统集成。您希望在系统中提供的第三个元素是一个工作应用程序，它负责以异步方式将前端应用程序与会降低用户体验的后端流程分离。

Presentation 应用程序、Application services 应用程序和工作应用程序都是 Codename:BlueMix 应用程序：可通过 HTTP 协议访问且使用受 Codename:BlueMix 支持的任何语言和 Web 开发框架（包括 Java / Liberty、Node.js / Express 和 Ruby / Sinatra）编写的 Web 应用程序。

如果一个工作应用程序（比如图 2 中的应用程序）没有提供 Web 服务，您将没有将 HTTP 路由与它关联，所以它无法从网络访问。但是，如果您使用一个工作 API 来查询和控制工作应用程序，在此情况下您不会丢弃 Codename:BlueMix 在云中部署工作应用程序时自动配置的 HTTP 路线。

这些应用程序实现了您系统的逻辑。您的开发团队编写代码。您无需担忧运行时（Liberty、Node Express）的部署和配置

Codename:BlueMix 会完成此任务。在设计系统时，您绝不能忘记的惟一一点是，应用程序必须遵循 12 因素方法，以便它们是无状态的。

为什么选择无状态？

无状态性对以云为中心的应用程序不可或缺，因为 Codename:BlueMix 具有两种行为：它在应用程序节点（应用程序实例）崩溃时自动重新启动它们。而且它可同时运行同一个应用程序的更多实例，每个实例在自己的容器中运行，将它们放在平衡流量的面向 Internet 的路由器背后。这些行为让您的应用程序可靠、高度可用 且可扩展。

如果您的代码没有将任何配置数据或业务数据持久保存在本地，Codename:BlueMix 应用程序非常合适。本地文件系统是短暂性的，它不会将信息保留到应用程序实例重新启动后。那么应将数据持久化到何处？服务 和环境 都是有魔力的词汇：在每个应用程序实例启动时，Codename: BlueMix 提供的应用程序环境中的源配置数据利用了 Codename:BlueMix 托管服务 来存储业务数据。

服务是应用程序通过网络使用的中间件资源：例如，数据存储（比如 SQL Database (SQLDB) Service 或 MongoDB）、消息/队列系统（比如 IBM Elastic MQ (ElasticMQ) 或 RabbitMQ），以及缓存系统（比如 IBM DataCache 或分布式内存）。Codename:BlueMix 会全面管理它提供的服务，所以您无需置备和管理（监视和备份）您的数据存储。而且 Codename:BlueMix 提供了工具（命令行、Web UI、IDE 插件）来请求服务实例，还提供了客户端 API 来在您应用程序中使用该实例。

分布式缓存、消息/队列，以及数据服务

现在您已理解了服务在 CloudOE 中的作用，我们返回看看 图 9 中 3 个基本服务，您构建以云为中心的应用程序需要这些服务：消息/队列、数据存储和分布式缓存。

您可能需要一个分布式缓存服务来改善 Presentation 应用程序的响应时间，缓存来自用户的频繁请求。分布式缓存还拥有卸载应用程序服务和数据服务层的优势。使用分布式缓存服务的 Presentation 应用程序的另一个用例是，存储必须在应用程序实例之间共享的 HTTP 用户会话数据。所以，分布式缓存服务可帮助开发人员构建响应式系统。

消息队列服务有助于改善以云为中心的应用程序的性能。此服务用在 异步应用程序 模式中，以预防演示和应用程序服务层执行会对用户体验带来负面影响的可能很慢的任务。任何时候在演示或应用程序服务层中执行这种任务，您都要使用消息队列服务来将任务委托给工作应用程序。工作应用程序获取任务并按自己的进度执行它。用户会异步获得操作结果的通知。

通常，任务的星系描述暗示要更新业务数据库。CloudOE 提供了数据服务来实现此用途。图 9 显示了一个关系 (SQL) 数据服务，但也可使用 CloudOE 所提供的基于文档的或键/值 (NoSQL) 数据服务。

使用 Codename:BlueMix 中的服务

使用 Codename:BlueMix 中的服务很简单。您配置一个实例（create 操作），将它与需要它的应用程序关联（bind 操作），然后开始编码。Codename:BlueMix 存储列出可用的服务，每个服务提供了文档和可供您用于开始编码的示例代码。所有服务都可通过 REST API 在网络上访问。API 端点 URL 和使用服务的凭据在 VCAP_SERVICES 环境变量中提供给绑定的应用程序。

我们以 Codename:BlueMix DataCache 服务为例。IBM 将 IBM WebSphere? DataPower? XC10 Appliance 中的底层技术创建为缓存键/值数据对的 Codename:BlueMix 服务。创建一个 DataCache 服务并将它绑定到应用程序后，Codename:BlueMix 配置一个网格和一组用于缓存和检索数据的凭据。VCAP_SERVICES 定义类似于清单 1。

清单 1. VCAP_SERVICES 定义

VCAP_SERVICES=
{
  "DataCache-0.1":[
    {
      "name":"DataCache-8acb7",
      "label":"DataCache-0.1",
      "tags":[],
      "plan":"free",
      "credentials":{
        "catalogEndPoint":"75.126.158.85:2809",
        "restResource":"http://75.126.158.85/resources/datacaches/S5D22GP5TOisTeszePBbpAWU",
        "restResourceSecure":"https://75.126.158.85/resources/datacaches/S5D22GP5TOisTeszePBbpAWU",
        "gridName":"S5D22GP5TOisTeszePBbpAWU",
        "username":"MKzIkp36RpKBWZP9FmXZHgFJ",
        "password":"lyk7FzsNR66pBm7kWlTAvwHP"
      }
    }
  ]
}

我们假设您在编写一个 Node.js 应用程序。要使用 REST API 缓存一个键/值对，可执行 3 个步骤：

初始化一些帮助器变量：

点击查看代码清单

准备用来缓存一个键/值对的 HTTP POST 请求，如清单 2 所示。

清单 2. 准备 POST 缓存请求

var post_options = {
  hostname: parsedUrl.hostname,
  path: parsedUrl.pathname + '/'+ credentials.gridName + '/' + encodeURIComponent(key),
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': auth }
};

写入值并提交请求：

post_req.write(JSON.stringify(value));
post_req.end();

PaaS 应用程序中的层

在普通的 Web 应用程序中，您可能会找到一个按层组织的应用程序组件分层结构：

1.演示组件管理与应用程序用户的交互

2.流程管理器组件管理实现应用程序用例的活动的工作流

3.应用程序服务组件处理位于应用程序核心的信息实体和服务

4.技术组件向上方的各层隐藏底层的技术

5.中间件组件位于应用程序外部

如图 10 所示，此结构的绝大部分仍然对 PaaS 应用程序有效。PaaS 应用程序的 Presentation Web App 将传统演示角色和流程管理器角色压缩到单个组件中，以最大限度改善相关设备和用户交互的用户体验

图 10. PaaS 应用程序中的各层与传统 Web 应用程序对比

我们在 Codename:BlueMix 中确定的 CloudOE 应用程序服务和工作应用程序组件：PaaS CloudOE 部分可分类为应用程序服务，工作应用程序专门用作异步服务。要满足云应用程序严格的 NFRs，可能有必要识别所有可通过异步交互来解决的用例，使用它们识别工作应用程序组件，保持应用程序裸机的执行路径尽可能短。

CloudOE 提供的每个中间件服务包含至少一个技术组件。通常，云应用程序使用非严格的分层，就此而言，演示应用程序和应用程序服务都可使用技术组件。

结束语

在传统上，架构师通过调整系统的基础架构和技术架构，解决了新系统上的 NFRs 带来的压力条件。云消除了架构师的指向任务，但需要他们确保云应用程序是云操作环境中的 “良民”。本文介绍的模式利用了 CloudOE 的特性，比如 IBM Codename:BlueMix。通过使用模式，可将 PaaS 应用程序设计为云中的可靠的、高度可用的、可扩展的 “良民”。