Question

我正在寻求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，并希望充分利用它的潜力。提前致谢。如果需要更清晰，请告诉我

Answer 1

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

请注意，从服务外部化此行为的anohter替代方法是使用Orchestration。 Orchestration使得更容易查看和监控预定义的业务流程，代价是偶然性和一些灵活性（相对于saga）。它还可以鼓励nano-services

基于主题的服务

1 个答案: