将各个附属机构统一在云端，以创建一个全局的 API

在现代商业中，许多组织为了在不同的领域有所作为，采取了收购其它公司的方式，并因此在全球范围内留下了深刻的足迹。这些被收购的公司有时可以保持基本完全独立，而有时则成为将各种业务整合在一起的一个重要组成部分。在这一问题空间内的最大的一项挑战是：你或许打算将这些公司整合在一起，以展现出整个公司组织的一个单一的全局视图，使客户与合作伙伴们能更方便地与你的组织进行整合。

本文中，我们将以一个基于真实世界场景的虚构示例作为研究对象，观察一些典型的挑战，并详细分析一些为了使这个解决方案获得成功应实现的良好实践。

业务背景

在本示例中，我们将观察一个名为 Acme Employee Assistance Group 的公司，简称 Acme。作为一家大公司，Acme 在全球各处都拥有着数量庞大的本地业务，它的发展策略还包括在新开发的国家中收购其它商业机构。他们的核心业务是为其它公司的员工在全球范围内外出旅游时提供支持服务。Acme 与来自许多国家的公司签订了合同，而合同的执行由 Acme 在当地的商业机构进行管理。由于每个国家都有一些特别的管理需求，这意味着创建一个管理所有客户的全局应用程序不是一件简单的事，并且 Acme 的大多数业务都依赖于一个非常陈旧的遗留 IT 系统。

当 Acme 的客户中的某个员工在外出旅行时需要帮助时，一项很大的挑战就出现了。他们会联系当地的 Acme 办公室，随后办公室就会为该员工提供各种支持所必要的帮助。这意味着当地的 Acme 办公室必须能够访问该员工的本处地的系统。

下图的例子表示，当一名来自英国的员工正在澳大利亚寻求帮助时系统的处理过程。

虽然这个初始的例子看起来并不是太复杂，但如果将 Acme 在全球的商业机构数量相乘，那系统就会很快变成意大利面条式的一团糟了。

传统的解决方案模型

当你首次考虑这个解决方案的需求时，作为一名整合构架师（Integration Architect），你或者会很快回想起那种老式的意大利面条式整合图，你应该会在那些缺乏集中式整合能力的企业的某些应用中看到过那种图形。而当前的问题领域类似于那些过去曾遇到过的挑战，只是它已经扩展到了全球的范围。

下图显示了你对这个解决方案模型的一种可能的理解方式。

新的解决方案模型

在当今的云服务时代，在同一个问题上你拥有了一些比过去更多的架构选择。你可以将云服务当作你的集线器，并且使用一个基于平台即服务（Paas）的消息传递系统作为这个架构的核心，这也意味着你所关注的挑战将从每个商业机构相互间的直接连接，转移到让这些商业机构连接到云服务的功能上。

下图展示了这种轴辐式模式在全球范围的应用。

这种类型的项目中依然有着巨大的障碍需要你去克服，但现如今类似于 Windows Azure 这样的云提供商允许你在非常短的时间内将你的数据中心连接到某个云端的消息系统，而且对基础架构方面的需求也很小。这种方式造就了在整个组织内传递消息的能力，它的成功也指导了我们如何以最佳的方式将这种消息传递能力暴露给我们的客户与合作伙伴。

为了实现这一点，我们在架构中需要 3 个关键级别的能力。首先，我们需要建立起本地商业机构的企业应用整合（EAI）能力，它能够连接云端的消息系统，并能够与业务线应用程序进行整合。

处于架构中间的是一个整合平台，它包含了消息传递的能力，并且为所有我们有可能需要整合的第三方系统提供了 EAI 的能力。

最后一级是面向公众的终端，在这里我们有一套 API 以及用户界面，它们将开放给那些需要与 Acme 进行整合的系统，如下图所示：

(点击图像放大)

从这张功能图中可以看出，系统首先通过一组 REST API 为应用整合公开的必需的接口，此外还为那些需要用户手动查看数据的、技术能力较低的合作伙伴创建一个专门的网站。

在接下来的一张图中，你将看到以上所列举的各项能力将怎样与每个商业机构中的实际系统相关联。你将看到每个商业机构都建立了一个整合产品，它能够连接消息系统，而这个消息系统又能够与整个业务线应用程序相整合。这种整合系统的示例有 BizTalk 及 Websphere。

(点击图像放大)

希望到了目前这个阶段，你已经能够清晰地看到一个潜在的架构，它能够在这个全球的混合式整合模式中交付所需的功能。这个项目依然会面临许多挑战，但由云端提供的这一新的解决方案途径意味着我们能够以一种与过去不同的方式处理这个系统了。

接下来我们将分析一些你需要考虑的关键因素，以及你需要遵循的某些实践，按照我的经验来看，这些实践是你要达到成功所必需的知识。

考虑因素与良好的实践

作为本文的一部分，我打算介绍一些我对某些关键考虑因素与良好实践的想法，它们与成功地交付这种解决方案是密不可分的。其中的某些部分特定于云服务，而某些部分则是整合解决方案中较为常见的。为了将这些考虑因素与实践分解成不同的区域，我们将从以下角度对他们进行分析：

• 组织
• 设计

此外还有一些方面或者你也会考虑到，例如交付以及解决方案的运维方面的问题，不过这部分就留到以后再讨论吧

组织方面的考虑因素

这一部分会讨论一些组织方面的关键问题，但这或许会成为一个很大的主题，因此我还是会让这一部分尽量保持简短，并让各位专注于之后的偏技术领域的部分。

通用数据模型

为了给整个组织展现一个通用的 API 集合，必需要有一个通用的、与商业机构无关的数据模型。如果该组织并没有一个现有的数据模型，那这或者会成为整个项目中最困难的部分。一个通用的数据模型意味着组织外的那些人对某个实体有着通用的认识，无论该实体来自于哪个商业机构。这个通用的数据模型可以展现为权威的消息。

让本地商业机构处理本地的问题

每个商业机构都会面临独一无二的挑战，这些挑战都应该由这些商业机构自行处理，因为他们在相关的领域有着专业特长。至于之前所说的通用数据模型的部分，对于一个本地商业机构来说，它所面临的一个挑战是如何将它自己的数据映射到通用数据格式中。

80/20 原则

很难在一开始就预见到所有的业务场景，而且每个商业机构都有可能会面临完全不同的某些场景，这种场景就不太值得去实现。在这种例外情况下，某个顾问可以选择给适当的商业机构直接打电话。

共享的与本地的运行成本

这个项目的成本模型或者会变得非常有趣。本地商业机构的 EAI 成本与它们通常的运行成本应该非常接近，或者它们需要扩展某些系统，但它们应该已经了解如何去处理这一部分成本了。而他们很可能不太了解的那部分新成本将来自于云端的 REST API 以及消息系统。你将面临的挑战为那部分潜在的跨多个商业机构的成本设计出一种分解方案。在这种情况下，你的组织应该选择接受一份 Windows Azure 企业协议，这样的话总体运行成本就会非常低了。

技能与经验

成功实现该项目的一个关键因素就是确保你的团队中具有熟悉整合经验的人才。组织经常会落入某个陷阱中，即认为任何开发者都能够处理整合的问题，但在类似于这样的大型复杂项目中，专业技能与经验会显得非常有价值。

设计

下面将讨论一些专注于设计的考虑因素：

协议与消息通道

在这个架构中，我们选择了 Windows Azure 消息总线（Service Bus）作为中央消息集线器，它为我们提供了消息系统的各种便利。并且它支持多种不同的协议，意味着我们可以使用多种不同的技术连接到它。除了在 Windows Azure 网站上为主要编程语言提供的类库之外，Windows Azure 消息总线还支持 REST 与 AMQP。

将 EAI 工作保持在边缘地带

这个云端的混合架构有一个较低层次的考虑因素，即应该在哪里进行 EAI。EAI 应该尽可能实现在本地商业机构内，而不是实现在云端整合平台上。这种方式尤其适合于那些具有良好水平的 IT 支持并且具有现成的整合平台的商业机构内，不过对一些技术水平较低的商业机构也可以采用一些其它选择，例如在云端搭建一个 BizTalk 的实例，让它处理各种 EAI 的挑战。

REST API 的入口点

在这个架构中，我们选择为客户端应用程序暴露一个基于资源的模型，和一组 REST API。这组 REST API 可以在一定程度上将客户端从消息系统中解耦，这为它们提供了一个简化的资源模型，但它也允许我们在云端包含一些逻辑，以帮助实现一些 API 可能需要的特性。这组 REST API 更允许我们在其中对资源访问进行集中控制。

版本控制

消息与 API 的版本控制很可能成为这个解决方案中的一个重要的考虑因素。像这样的项目很可能在整个项目的生命周期内对数据进行大量的改动。我们应该在此架构中实现常见的 API 与消息的版本控制技术。

异步消息

在适当的地方使用异步模式对整个解决方案中的多个领域有所帮助，包括性能和伸缩性。在实际中我发现许多项目都尽量避免使用异步消息，但这一功能对这个案例来说非常重要。

Azure 消息总线命名空间

为基于云端的消息传递使用一个单独的消息总线命名空间将有助于 Acme 简化对消息传递的管理。这意味着队列与订阅将会集中在某一地点。

使用最新的 Windows Azure 消息总线 Paired Namespace 特性也将有助于你改善系统的可用性。

消息传递的格式

API 中的消息传入与传出可以按照常见的 REST 模式进行设计，但是在 Windows Azure 消息总线中进行传递的消息的格式必须与其它所有 Acme 本地商业机构的消息格式相兼容。理想的情况是 Acme 使用 JSON 消息格式以限制消息的大小，但它也取决于终端应用的能力。

对 Acme 中采用了 BizTalk 的商业机构来说，有许多来自社区的文章详细分析了如何在 BizTalk 中对 JSON 消息进行解码。

Azure 消息总线安全性

Windows Azure 消息总线在内部使用 Windows Azure 活动目录访问控制（ACS）或者 Shared Access Secrets 特性来保护对队列 / 主题的访问，并控制你对它们的操作权限。这一级别的安全性对集中式配置访问权限会有所帮助，它可以允许任何一个本地商业机构的访问。

队列及主题配置

这个解决方案的队列及主题配置可能会依赖于你打算实现的消息传递模式。在这个解决方案中，我们有可能会大量用到主题以允许使用订阅规则，以此决定各消息将传递给哪个本地商业机构。

我们用到最多的模式是一个路由 RPC 模式，其中一个主题会将一个消息路由至某个订阅中，随后本地的商业机构就会将一个响应消息发送至某个包含会话信息的响应队列中。此外还用到了一种单向路由模式。

消息路由规则

这个架构中的多数跌幅规则都基于一个上下文属性，它指出某位员工是属于哪个国家或者本地商务机构。由于这一商业用例的本质，我们随时都能够从这位寻求帮助的员工与顾问之间的首次对话了解这一信息。

这一上下文属性随后加入到消息中，而在 Windows Azure 服务总线中我们可以使用一个简单的基于该属性的订阅过滤器，将消息路由给正确的本地商业机构。

引用数据

在这个架构中，一个常见的数据方面的问题就是数据的交互引用，一个商业机构到另一个之间存在多种代码映射。在这个场景中，最佳的方式就是为所有这些引用数据字段创建一个集中式的总数据表，然后沿用之前将 EAI 工作推到边缘的设计原则，让每个商务机构自行负责将中央商业数据映射到它们自己的特定商业数据。

如果可能的话，使用工业标准代码会带来很大的帮助。例如使用 ISO 国家代码以指代某个国家，对于表示与商业机构无关的国家代码就是一个好的选择。

和通用数据模型一样，这一领域也可能成为最难解决的问题之一。

结构化与非结构化数据

在定义通用的数据模型时，想要对所有字段达成一致的认识通常是很难的。而我推荐的方式是考虑数据的使用方式。某些数据是明显的实体，例如一个名称或者地址，它们的结构通常已经很清楚了。而另一些数据将成为某一流程中能够作出某些决定的关键属性。这种数据需要进行良好的定义，并且便于开发者在消息中指出该数据，使这些数据可以在系统中使用。另外有些数据或许是用户需要阅读的重要数据，但并不需要以某种方式进行结构化，开发者只需要将其显示给用户而不需要做其它任何处理。在这种情况下，或许可以为这个数据模型建立一个非结构化的部分，让某个本地商业机构可以任意加载他们所需或与他们相关的数据。这种方式对显示特定于业务的额外信息也是种有效的方法，这些额外信息往往对于每个本地商业机构来说都有所不同。

消息大小

当使用基于队列的消息系统时，考虑消息的大小是非常重要的。在起初我还对消息的大小有所担心，但在实际过程中消息的尺寸限制帮助我们更好地专注于消息，确保不会创造出包含了许多无用数据的过大的响应消息，这一点是过去经常遇到的问题。使用 JSON 格式也能够在很大程度上帮助你将消息的大小限制在较小的范围内。

虽然有些技术可以使你利用会话以应对大尺寸消息的处理，但在我们的案例中，我们一直尝试将尺寸限制作为一种制约，它促使我们设计较小的有效信息以处理某些特别的情况。由于这个架构保留着横向扩展的可能性，如果我们打算将数据聚焦为一个较大的资源并返回客户端，这个架构也允许我们发送多条并行的消息以传递各种不同的信息。

结论

我希望本文让你了解到云服务以及基于云服务的消息传递能够为你交付那些在过去看来过于复杂的项目提供了某些方法。这一项目的关键在于，很大程度上对基础设施的需求已经改变了，或是已经完全消除了，你可以以一个很低的成本快速地这对种类型的项目做一些概念式的实验。而在过去，基础设施方面的需求会带来很大的成本要求与项目实施的复杂度，这使得项目的成功实施非常困难。

请记住以下这重要的一点：虽然该项目中的某些挑战是不会改变的，它仍然是一个复杂的整合项目，但希望我的想法对这些考虑因素及实践能对你的成功有所帮助。

关于作者

Michael Stephenson 是一位来自英国的独立开发者与云技术专家。他主要专注于微软整合平台上的整合技术，例如 BizTalk 与 Windows Azure。Michael 有多年的技术领导与教练的经验，他为客户交付了大量复杂的、真实世界的混合整合应用。Michael 近期在提倡 BizTalk 成熟度评估。他会定期更新他的博客，此外也可以通过 Twitter 或者 Linked In 找到他。

查看英文原文： Bridging Subsidiaries With the Cloud to Create a Global API