如何在SOA体系结构中实现松耦合

Question

最近我一直在研究关于SOA和ESB等方面的内容。

现在，我正在重新设计一些遗留系统，并希望将其构建为更具有SOA架构而不是当前的架构。我们在约5个网站中使用这些服务，我们目前遗留系统最大的问题之一就是几乎每次进行错误修复或更新时都需要重新部署我们的5个网站，这可能是一个耗时的过程。

我的目标是使服务之间的接口松散耦合，以便可以进行更改，而无需重新部署所有相关服务和网站。

我需要能够扩展已经存在的服务接口，而不会破坏或更新任何它所依赖的元素。你们中有没有人遇到过这个问题？你们是如何解决它的？

- user300183

---

你好，Brian。这是一个好问题，我也想学习。你能否更新一下这个问题，分享一些你觉得有用的在线资源呢？ - Ashish Gupta

Answer 1

我建议您考虑一些不同于目前所使用的服务风格。考虑使用事件进行协作的服务，而不是请求/响应式的服务。我已经在各种垂直领域与客户使用这种方法多年，并取得了巨大成功。我在过去的四年中写了很多关于这些主题的文章。以下是一个可以让您入门的地方：http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/希望这有所帮助。

- Udi Dahan

---

我从未想过那个。有趣的是，大约一周前我下载了你们的开源ESB nServiceBus的一个副本。只浏览了大约一个小时的代码，我就认为你们所做的事情不能解决我的问题。我看到了一堆在发布者/订阅者之间传递的类，这让我想到任何更改都会导致任何依赖关系被重建。在阅读了你发表的内容后，一切都变得清晰了。他们通过事件传递单个消息而不是整个服务接口。我可以添加新的消息而不破坏任何现有的代码。 - user300183

Answer 2

有几种方法可以采用。我们的SOA架构涉及发送到服务和从服务接收的XML消息。我们实现你所描述的功能的一种方式是避免使用数据绑定库来绑定我们的XML模式，并使用通用XML解析器仅获取您想要的数据节点，忽略那些您不感兴趣的节点。这样，服务可以向消息添加附加新节点，而不会破坏当前使用它的任何人。我们通常只在需要从较大的模式结构中获取一两个信息时才这样做。

另一种（首选）解决方案是版本控制。服务的某个版本遵循特定的模式/接口。当模式更改（例如接口扩展或修改）时，我们创建该服务的新版本。随时可能有2或3个版本正在运行。最终，我们将弃用并删除旧版本，同时迁移依赖代码到新版本。这样，那些依赖于服务的人可以继续使用现有版本的服务，而某些特定依赖关系可以“升级”到新版本。调用服务的哪些版本是由配置文件定义的。请注意，不仅模式会被分版本，所有基础实现代码也会被分版本。

希望这可以帮助你。

- Chris Knight

---

是的，这绝对是一个可行的解决方案。然而，我认为我在理解所有这些内容时遇到的最大问题是，当我考虑服务时，我认为它需要一个类似于WCF服务中使用的服务合同。当您将每个API函数分解并将其转换为自己的消息时，解决此问题变得更加容易。因为您可以向服务添加任意数量的消息，所以现在可以向服务添加其他版本和新消息。 - user300183

Answer 3

你所询问的并不是一个简单的话题。有许多方法可以使你的面向服务的架构松耦合。

我建议先看看Thomas Erl的SOA图书系列。它能很清晰地、深入地解释所有事情。

- Justin Niessner

---

感谢您的回复。我知道这不是一个容易的话题。似乎我已经研究了一个月了。我看了一些InfoQ的演示，也在网上看了一些书，所以我对最终产品需要看起来像什么有很好的理解，但是我很难从A点到B点。我会看看您建议的书，也许它能帮助我澄清一些事情。 - user300183

Justin，你知道有没有在线资源可以解答这个特定的问题吗？ - Ashish Gupta

Answer 4

有几种常见的实践方法可以实现服务之间的松耦合。

1. 使用文档/字面风格的Web服务，考虑数据（线路格式）而不是RPC，避免基于模式的数据绑定。

2. 在发送数据时严格遵守合同，但在处理传入数据时保持少量假设，xpath是一个很好的工具（松散进，紧密出）

3. 使用ESB，避免任何直接点对点通信。

- vtd-xml-author

---

是的，我决定使用一个ESB NServiceBus。它似乎解决了我的大部分问题。 - user300183

Answer 5

以下是一个初步的清单，用于评估您的SOA是否实现了松耦合：

• 被调用系统的位置（其物理地址）：您的应用程序是否使用直接URL访问系统，还是通过抽象层解耦，由该抽象层负责维护系统之间的连接？ SAP NetWeaver CE中使用的服务注册表和服务组范例是此类抽象的好例子。使用企业服务总线（ESB）是另一个例子。关键是应用程序不应该硬编码所调用系统的物理地址，以便真正地被视为松耦合。

• 接收方的数量：应用程序是否指定哪些系统是服务调用的接收方？松耦合的组合不会指定特定的系统，而是将其消息的传递留给服务合同实现层。紧密耦合的应用程序会明确调用接收系统以进行操作；而松耦合的应用程序只需调用服务接口，并允许服务合同实现层处理将消息传递到正确的系统的详细信息。

• 系统的可用性：您的应用程序是否要求您连接的所有系统始终处于运行状态？显然，这是一个非常困难的要求，尤其是如果您想连接到不受您控制的外部系统。如果答案是所有系统必须始终运行，则该应用程序在这方面是紧密耦合的。

• 数据格式：应用程序是否重用后端系统提供的数据格式，还是使用独立于所调用应用程序中使用的类型系统的规范数据类型系统？如果您正在重用后端系统的数据类型，则可能需要在应用程序中处理数据类型转换，而这不是一个非常松散的方法。

• 响应时间：应用程序是否要求被调用系统在特定时间内响应，或者应用程序接受几分钟、几小时甚至几天后才能收到答案？

- Debaprio B