8

我最近一直在做很多关于 SOA 和 ESB 等的研究。

我现在正在重新设计一些工作中的遗留系统，并希望使用比目前更多的 SOA 架构来构建它。我们在大约 5 个网站中使用这些服务，而我们目前在遗留系统中遇到的最大问题之一是，几乎在我们进行错误修复或更新时，我们需要重新部署我们的 5 个网站，这可能是相当耗时的过程。

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

我需要能够在不破坏或更新其任何依赖项的情况下扩展现有服务接口。你们中有人遇到过这个问题吗？你是怎么解决的？

4

5 回答 5

3

我建议您寻找与您迄今为止所做的不同风格的服务。考虑使用事件而不是请求/响应来相互协作的服务。多年来，我一直在与各个垂直领域的客户一起使用这种方法，并取得了巨大的成功。在过去的 4 年里，我写了很多关于这些主题的文章。这是您可以开始的地方：

http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/

希望有帮助。

于 2010-03-24T13:55:13.877 回答
2

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

或者，我们使用的另一个（首选）解决方案是版本控制。服务的版本遵循特定的模式/接口。当模式改变时（例如接口被扩展或修改），我们创建一个新版本的服务。在任何时候，我们都可能随时有 2 或 3 个版本。随着时间的推移，我们弃用并删除旧版本，同时最终将相关代码迁移到新版本。这样，那些依赖服务的人可以继续使用现有版本的服务，而某些特定的依赖可以“升级”到新版本。调用哪个版本的服务在依赖代码的配置文件中定义。请注意，不仅是模式被版本化，而且所有底层实现代码也是如此。

希望这可以帮助。

于 2010-03-24T14:10:24.310 回答
0

你问的不是一个简单的话题。有很多方法可以让你的面向服务的架构松耦合。

我建议查看 Thomas Erl 的SOA 系列丛书。它非常清楚和深入地解释了一切。

于 2010-03-23T19:48:57.757 回答
0

有一些常见的做法可以实现服务的松散耦合。

  1. 使用 doc/literal 样式的 web 服务，考虑数据（有线格式）而不是 RPC，避免基于模式的数据绑定。

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

  3. 使用 ESB 并避免服务之间的任何直接点对点通信。

于 2010-03-25T09:00:17.027 回答
0

这是一个粗略的清单，用于评估您的 SOA 是否实施松散耦合：

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

  • 接收者数量：应用程序是否指定哪些系统是服务调用的接收者？松散耦合的组合不会指定特定的系统，但会将其消息的传递留给服务合同实现层。紧密耦合的应用程序将按顺序显式调用接收系统；松散耦合的应用程序只需调用服务接口，并允许服务合同实现层处理将消息传递到正确系统的细节。

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

  • 数据格式：应用程序是否重用后端系统提供的数据格式，或者您是否使用独立于被调用应用程序中使用的类型系统的规范数据类型系统？如果您正在重用后端系统的数据类型，您可能不得不在应用程序中进行数据类型转换，这不是一种非常松散耦合的方法。

  • 响应时间：应用程序是否要求被调用系统在特定时间范围内响应，或者应用程序是否可以在几分钟、几小时甚至几天后收到答复？

于 2014-08-18T08:58:59.727 回答