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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 组织
• 设计

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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找到他。