0

我正在向 SOA/ESB 专家寻求一些架构设计方面的帮助。如果问题不是很清楚，请道歉。

我们有几个业务案例，我们目前正在使用 P2P 通信或大量代码块，例如

       if(...)
               Update System 1
               Then Update System 2
               Then Update System 3
       Else If (...)
                Update System 1 in a different Way
                 Don't Update 2 at all
                 Update 3 but differently

现在到处都是样板代码和数据库更新代码。有趣的是，我们从一个面向客户端的界面开始，然后继续添加更多并获得“快速获胜”，并不断复制代码。现在，当需要进行小改动时，它就变成了一项艰巨的任务。

这是一个典型的 ESB 类型案例恕我直言，我们正在考虑采用主题 - 发布 - 订阅模型来满足这种情况。这样所有参与的客户端都可以将消息发布到主题，然后我们只需在需要时随时随地连接订阅者。所有 Db 或系统更新代码将是通用的并用于单个集群部署。

但是，应该在所有系统中更新数据。例如，如果 1 个订阅者的更新失败，我们应该回滚其他系统中的更新，或者至少在失败的地方进行审计。实现上述目标的最佳方法是什么？有我们可以使用的标准工具/实用程序吗？

仅供参考 - 我们正在使用 Java 技术和 Mule ESB，并希望充分利用它的潜力。提前致谢。如果需要更清晰，请告诉我

4

1 回答 1

0

使用主题是一种将服务联系在一起的非常强大的方法。这是我称之为Saga的模式。你应该确保你的主题设计应该同时传达事件和上下文，因为同一事件可能需要根据上下文路由到不同的接收者（因此主题可能看起来像 context.evetnType 并且订阅者可以订阅所有类型 (*.eventType) 或仅在特定上下文中的事件）

请注意，将这种行为从服务外部化的另一种选择是使用Orchestration。编排使查看和监控预定义的业务流程变得更容易，但代价是偶然性和一定的灵活性（与 saga 相比）。它还可以鼓励纳米服务

于 2012-10-23T20:07:49.080 回答