演化架构和紧急设计: 演化架构 - 编程入门网

这里有个例子。在传统的 SOAP 式集成中，使用的协议类型是 Remote Procedure Call (RPC)，并用 WSDL 来定义两个应用程序间通话的详细信息，如图 5 所示：

图 5. 在应用程序间使用 RPC 式调用

演化架构和紧急设计: 演化架构(5)

RPC 式集成使用 WSDL 来进行一个 “常规” 方法调用，并将其抽象出来发送到 SOAP。这样，每个类 都映射到 WSDL 中的一个类型，包括其所有参数的类型。这种方法将通信双方强烈耦合到一起，因为它们 都依赖 WSDL 来定义发送的内容和预期接收的内容。问题源于这种严格的定义。如果您需要修改其中一个 应用程序来采用不同的参数或者改变现有的类型，且不能同时更改这两个应用程序，那又该怎么办呢？该 如何对端点进行版本控制？有几个方法是可行的，但所有这些方法都有严重的妥协之处。例如，您可以用 新的 WSDL 定义创建另外一个端点。如果原始端点命名为 addOrder，那么您可以创建另一个端点，命名 为 addOrder2。您会看到这种方法前景不妙。不久，您就会有数十个稍有不同、到处包含重复代码的端点 来处理一次性情况，因为一旦发布，就很难预测人们会怎么应用这些集成点。您也可以使用 Universal Description, Discovery, and Integration (UDDI)（或者仅仅是哈希图）这样的工具来欺骗端点，但那 并不会有很好的效果。根本问题就是端点间的严格耦合，那会阻止其按自然、独立的速度发展演变。

一种替代方法就是把集成端点当做宽松类型对待，如图 6 所示：

图 6. 在集成端点采用宽松类型控制

通过将有趣的端点信息传送到一个文档内，您可以在通信双方任意一方主要升级和次要升级过程中保 持端点定义不变。您可以灵活选择，而不是依赖 WSDL 来严格定义预期的内容。现在，端点总是接收一个 封装该端点所需类型的文档。

要解决端点的版本控制问题，端点要做的第一步就是把文档解开，确定已经传输的内容，并用预期的 内容与之协调。我通常联合使用 Factory 和 Strategy 设计模式来确定是否正在获得预期的内容，如图 7 所示：

图 7. 在端点内解开内容来确定类型

端点的首要工作就是查看文档的清单，确定它包含的内容。然后，它用一个库来实例化适当的策略， 将那些信息从文档中抽出。一旦所有部分都通过验证（必要时可用 WSDL），反序列化的对象就被传递， 用于业务处理。

这种方法有几个好处。首先，拥有一个带有两个正交作业的机制是个坏主意，然而那正是传统 RPC 所 假设的：端点既要负责提供已发布的集成 API，又要负责验证类型。因为其有两个行为，所以您可能会弄 混代码，使其更难理解和维护。其次，现在这个端点可以有多个用户，每个用户使用稍有差异的版本。只 要您有一个策略，您就能够用相同的端点支持任何版本（包括那些更新缓慢的应用程序的老版本）。这允 许您根据需要进行改变，不用担心这会迫使企业内应用程序的其他部分和您的改变保持一致 —— 它们可 以根据自己的进度改变并使用新的文档版本。

目前没有任何工具或者框架允许您轻松地实现这种方法，但是一些额外的前期工作提供了之前提到过 的好处。您可以使用 SOAP 或 REST 来实现这个样式（不过在 REST 中会更容易，因为它本身就是以文档 为中心的）。通过创建一个宽松类型的生态系统，您可以使不同的开发小组按自己的节奏开展工作，从而 使整个企业的应用程序使用以最小的摩擦前进。这就是演化架构的精髓：奠定一个基础来支持尽快实施无 摩擦的、不损害功能的变革。

结束语

架构是个庞大且复杂的软

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!