使用微服务实现SOA - 如何规范化/转换消息

Question

我们正在开发一种方案，将消息模式和微服务相结合以定义和运行业务流程。

它应该具备以下组件：

- 网关：用于启动事务，带有给定的流程 ID， - BPM：用于存储规则（为给定流程调用哪些服务）， - 服务选择器：一种处理器，它从网关获取请求，获取流程定义，然后逐个调用适当的服务， - 功能服务。

我们应该能够定义多个流程，其中每一步都是调用不同的服务。

一个服务的输出可能是另一个服务的输入。问题在于它们可以具有不同的架构，因此需要进行转换/归一化处理。

但是哪部分应负责执行这样的转换？它应该是可配置的，因为我们希望添加新的流程而无需重新部署。

第一个想法是存储每个服务的响应，然后每个步骤将使用 XSLT 转换将前面的响应生成输入 XML。但是，这可能是配置地狱，因为创建和测试这样的 XSLT 不会很容易。

您有任何建议如何正确解决这个问题吗？

- smolarek999

Answer 1

假设您有多个提供服务的系统，请使用规范数据模型来避免在中间件中嵌入转换。这是Gregor Hohpe企业集成模式网站关于规范模型的链接。

引用： 使用与任何特定应用程序无关的规范数据模型。要求每个应用程序以此通用格式生成和消费消息。

这个想法是，服务使用约定标准进行互操作。通常，每个提供服务的系统都有自己的内部数据模型，不同于规范模型。这是因为更改旧系统太过繁琐，或者规范模型不适合系统对数据的内部表示。然后，每个系统都负责将其内部架构转换为规范模型以进行服务I/O。

每个系统团队可以使用任何工具来执行转换：XSLT、Python脚本、Java或来自Oracle或Microsoft的所见即所得工具。总之，任何内部数据模型与规范模型不完全相同的系统都必须执行某些映射。这是不可避免的。

- ahoffer

---

这种通用模型的规范化应该由单独的服务处理吗？还是它应该成为功能服务或服务选择器的一部分？我知道这可能会有所不同...但我很好奇哪种方法最有效。 - smolarek999

我的观点是让功能系统负责转换。为什么？因为功能系统团队拥有本地数据模型的知识。我并没有立即看到将其抽象成单独层的任何好处。我认为额外的复杂性并没有带来任何好处。但我只是一个有意见的人，提供免费建议。买方自负。 - ahoffer

还有一件事。我没有足够的实践经验来推荐特定的技术或工具进行转换，这可能是你一开始寻找的东西。 - ahoffer

Answer 2

如果您正在处理由多个独立编写的组件处理的长消息流，则应使用特定于组件的数据格式。

由于康威定律，您的组件应属于具有不同领域模型观点的不同业务实体。例如，“订单”可以意味着完全不同的事情，并且需要为不同部门提供不同的数据。

至于您的问题-每个组件都应发送特定于其业务实体的消息。接收方知道不同业务世界之间的边缘，应对传入消息进行转换和增强以进行进一步处理。

当然，需要其他服务拥有字典和配置来提供附加数据以进行增强。

P.S. “添加新的流程而无需重新部署”是许多项目失败的主要原因。首先，在现代架构中没有理由害怕重新部署-所有服务必须集群化并能够优雅地处理故障。其次，您应严格定义可以通过更改配置/规则等来完成哪些工作，无法完成哪些工作。更重要的是，谁可以做出这些变化。默认情况下不要指望商业人士编写商业规则 :-)

- Sergey Alaev

Answer 3

我发现这篇论文对我的思考有所帮助，它可能也对你有所帮助。

第21页，但在阅读此页之前，请先阅读论文以了解上下文。

解决方案架构的实用SOA

- MetalLemon