使用 Cloud Foundry 设计可移植的应用程序_cloud foundry 应用程序-CSDN博客

[译注]本文翻译自Cloud Foundry 英文博客站点，原文题为“Designing Portable Applications With Cloud Foundry”，文章发表时间是2012 年 12 月 13 日。

在云计算环境中，保留对云的选择权至关重要。被限制在一个云中存在着切实的风险。Cloud Foundry 提供了一个用来部署和扩展应用程序的抽象层，并保留了在目前的云之间移动以及移动到将来的云中的功能。

在本篇客座博客中，Cloud Foundry Core 应用程序开发企业 Cloud Elements 的共同创始人 Mark Geene和 Vineet Joshi 就如何在不牺牲性能或功能的情况下设计可移植的应用程序给予了指导。

可移植性为何十分重要

我们常常发现，客户在首次开发他们的应用程序时所选的云提供商无法随着他们应用程序的扩展而满足延迟、正常运行时间或冗余要求。

有一家客户的经历让我们惊讶不已：这家客户真切地看到，随着他们的应用程序开始增长，他们在自己的云基础架构提供商身上所增支的成本也会快速增加，因为他们需要付出更多的时间、管理精力和费用来设置服务器，管理负载平衡器和网络配置，并持续不断地调整应用程序和基础架构来实现高可用性、冗余和故障切换。

为了换一家更合适的云提供商，这家公司的开发人员付出了超过六个月的努力来解除专有的服务集成，其中包括存储管理、工作流和身份管理。

采用开源技术开发应用程序并不能保证在将该应用程序重新部署到其他云提供商提供的平台时它能够移植。您还需考虑这些技术在您选择的基础架构内的交互情况。

RDS 与 MySQL 互操作性方面的教训

这方面的教训是我们在与一家客户合作时亲眼所见。当时，这家客户针对印度的零售行业开发了一款移动销售队伍自动化应用程序。在原型设计阶段，他们力图最大限度地降低成本，于是就采用 Amazon RDS（关系数据库服务）设计了这款应用程序。

随着原型变为成功的产品，很多大型零售客户都希望将这款应用程序部署到私有云中。令他们惊讶的是，RDS 的 MySQL 实现是专有的，因而迁移应用程序数据并不是只需从 RDS 中导出数据文件、再将这些文件导入到专用的 MySQL 安装中这么简单。

RDS 提供的部分 API 在开源版本的 MySQL 中并未提供。经过事后反思，他们对选择专有服务懊悔不已，因为为了迁移到真正开源版本的 MySQL，他们多付出了将近两个月的努力。

设计可移植的应用程序 – 客户案例

根据诸如此类的经验，我们制定出了一套流程来指导客户设计可移植的云应用程序：

首先选择一款 PaaS 产品
将可移植性作为关键的 PaaS 选择标准
使用 PaaS 服务来推动云应用程序体系结构
选择符合可移植性标准的增值应用服务
对所选的服务进行松散耦合

首先选择一款 PaaS 产品

选择合适的 PaaS 对保持应用程序的可移植性有着重要影响。我们力劝客户先选择自己的 PaaS，再选择自己的 IaaS 提供商 — 而不是反其道而行之。您并不会先选择硬件供应商、后选择操作系统，那么您为什么却要在云中采取这种方法呢？

PaaS 对云应用程序而言就相当于操作系统。它提供的应用程序运行时和数据库服务等一组功能如果在平台层而不是在基础架构层使用，则会具有更高的可移植性。事实上，我们已通过使用 PaaS 而非 IaaS 来作为 MySQL 数据库的提供程序（即使在部署到 AWS 时也是如此），避免了上述 RDS 迁移问题。

公共/私有 PaaS 的可移植性

当我们将可移植性作为我们应用程序的设计标准时，我们也将其作为选择 PaaS 时的评估标准。

我们在评估 PaaS 可移植性时采用的标准如下：

有多家 IaaS 提供商采用该 PaaS 来提供公共云
可以通过开源方式进行私有云和混合云部署
它提供了独立于基础架构管理和监视的应用程序管理和监视功能

例如，我们使用私有云中部署的 Cloud Foundry PaaS 为客户开发了一款应用程序。这种情况下我们有两个选择：1) 采用为该应用程序提供运行时和服务的 PaaS；或者 2) 我们自行安装、配置和管理这些服务。该应用程序的技术堆栈包括 Apache、在一个 Tomcat 容器中运行的 Java、用于数据库的 PostgreSQL 以及一个开源 NoSQL 数据库。

根据以往未使用 PaaS 时的经验，需要付出两周的努力来设置硬件/操作系统、安装并配置 Apache、Tomcat、Java 和 PostgreSQL，然后才可以部署该应用程序。这些努力并不包括为确保该应用程序顺畅运行而对网络、软件和硬件配置进行的调整。

对于这家特定客户，我们选择了使用私有云中的 Cloud Foundry 来部署该应用程序。只用了不到一天时间便完成了设置、安装、配置 Cloud Foundry 以及将我们的应用程序部署到私有云的工作。更重要的是，如果要添加新的服务器/节点，只需以这种配置复制虚拟机即可，而这不到一分钟即可完成。

在时间和工作量上所实现的这种巨大节约甚至还未包括开发人员在以下方面所耗费的数不清的时间：设计应用程序架构并调整应用程序以通过 JMX 提供运行状况检查、实时应用程序管理等功能，以及集成硬件和应用程序监视控制台。我们无需额外编写一行代码，即可实现上述所有目的。

几个月后，我们将我们客户的应用程序迁移到了一个混合云，也就是说，部分应用程序继续在私有云中运行，而有些则移至 Rackspace 云基础架构上的一个专用 Cloud Foundry 实例。得益于我们底层 PaaS（即 Cloud Foundry）的可移植性，迁移过程总共用了 24 个小时。

IaaS 服务与 PaaS 服务之间的严格分离

我们看到客户对最大限度增加由其公共 IaaS 提供商提供的服务感兴趣，包括已属于 PaaS 层的存储、数据和排队等一些服务。我们向这些客户提供的建议是，将系统架构设计为严格分离 IaaS 服务与 PaaS 服务，这样可以保持这些服务的可移植性，以防他们需要将 PaaS 层和应用服务移至其他基础架构提供商提供的平台。

针对这些客户，我们选择的是采用 Cloud Foundry 的 PaaS 层，我们使用这样的层来支撑云应用程序体系结构模型。

图 1 – 我们云应用程序体系结构模型的 PaaS 层

Cloud Foundry 提供的服务界定了我们模型的 PaaS 层：

应用程序运行时服务，包括 Java on Spring、Ruby on Rails 和 node.js
应用程序管理服务，包括应用程序运行状况监视和警报、应用程序资源管理以及应用程序扩展和部署管理。
数据服务，包括 PostgreSQL、MySQL、MongoDB 和 Redis。相对于将数据持久保留到诸如 Rackspace Cloudfiles 或 AWS 关系数据服务 (RDS) 等基础架构级数据服务，在 PaaS 提供的数据服务内持久保留应用程序数据可以提高应用程序数据的可移植性。
消息传送与排队服务，包括 RabbitMQ。在同一环境内部署的多个云应用程序常常需要彼此通信。应用程序间的通信机制应利用 PaaS 消息传送与排队服务，这再度消除了对基础架构的依赖性。例如，多个应用程序绝不应使用环境变量来相互通信，否则将需要付出额外的努力才能在 IaaS 提供商之间迁移这种配置。

请在 PaaS 级别而非基础架构级别使用上述服务，这样其中的每一项服务都将是可移植的。每个 Cloud Foundry Core 实例包含相同发行版本的上述服务。如果您坚持使用“Core”服务，那么毫无疑问您的应用程序将可以在所有与 Cloud Foundry Core 兼容的提供商间移植。

图 2 – 我们选择的 PaaS 服务下的 IaaS 层

根据某些原型设计和性能测试结果，我们成功说服了我们的其中一家客户使用 PaaS 来获取数据和存储服务。这也有助于验证我们的应用程序体系结构模型。不到一年，这家客户就决定迁移到另一公共云基础架构提供商以降低他们的成本。这种分层体系结构通过在体系结构层面让 PaaS 提供商与 IaaS 提供商分开提供数据和存储服务，为这家客户节省了大量资金。我们唯一需要与该客户一起完成的活动就是，安装 Cloud Foundry 并将应用程序数据复制到新的 IaaS 提供商。这使我们仅用几天时间即可将应用程序、服务和数据（使用 Cloud Foundry 隧道）迁移到新的云基础架构提供商，这种迁移原本可能需要数月才能完成。

基于 AWS 的社交网络应用程序展示了服务集成

我们最近为一家需要以下应用程序层服务的初创型客户设计了一款社交网络应用程序：支付、短信收发、电子邮件以及 Facebook/Twitter 集成。该应用程序需使用 Cloud Foundry 部署在 Amazon EC2 上。对于上述每项服务，Amazon 也像第三方 SaaS 提供商那样提供了备选方案。

就像我们会根据功能、价格、性能和集成能力对任何第三方 SaaS 提供商提供的服务进行评估一样，我们也对这些应用程序级服务进行了评估，而不考虑它们是由 IaaS 提供商提供的还是由 PaaS 提供商提供的。需考虑对应用程序可移植性的影响。如果您采用 IaaS 供应商提供的其他应用程序服务而不是可在任何云上运行的第三方应用程序服务，那么从该供应商进行迁移是否更加困难？还要从技术、业务和合同方面考虑对可移植性的影响。

集成 SaaS 应用程序

将增值 SaaS 服务集成到您的应用程序中时，请确保应用程序与第三方 SaaS 提供商之间进行的是松散耦合，以便优化发行版管理、操作完整性和应用程序可移植性。最值得推荐的松散耦合实现机制是，确保第三方提供商支持基于 REST 的 API 以供您的应用程序使用，并确保您的应用程序提供基于 REST 的 API 以供您的客户使用。

例如，我们曾帮助我们的其中一家客户将他们的 SaaS 应用程序与 ServiceNow 和 Jira 这两项第三方云服务集成。该应用程序在这两项服务之间架起了桥梁，这样外部客户便可以使用 ServiceNow，工程人员便可以使用 Jira 作为缺陷跟踪工具。

Jira 提供了一个基于 REST 的 API，ServiceNow 则通过 Java JAR 提供了一个紧密耦合的接口。我们建议该客户将 SaaS 应用程序与 ServiceNow 之间的集成分离出来形成一个单独的“代理”应用程序。这样，无需对主应用程序进行任何更改，即可更改供应商的 JAR 文件。代理应用程序为主应用程序提供了一个一致、基于 REST 的 API，从而将该应用程序孤立起来，而不必再直接使用 Java JAR。