Architecture 体系结构：通知机制

我正在考虑一个标准软件系统的几个架构选项。也许你愿意分享你的观点

系统： 我们有一个带有底层数据库的业务逻辑组件。直到今天，这个逻辑组件只由一个客户机使用，因此UI、逻辑和数据层都在一个可执行文件中。（工具A）

现在，该程序具有如此酷的特性，另一个已经存在的工具应该使用它（工具B）。工具B也应使用（或至少显示）工具A的一些数据，但它也保留自己的数据存储。我们的解决方法很简单： 我们拆分工具A。业务逻辑得到一个服务接口（可能是web服务，RESTful与否）。然后工具B可以访问工具A的业务逻辑，获取数据，执行计算，等等

现在，如果工具B显示工具A的数据，如果它能收到工具A中数据更改的通知就好了。我们的服务接口很好，但只是一个单向的故事（如果你不做一些技巧，比如在事件发生之前保持异步调用打开）

我们看到几个选择：

• a。工具B还获得一个服务接口。当它启动时，它向工具A注册，工具A将向工具B发送更改事件

• b。工具B正在轮询工具A的服务以获取更改

• c。我们引入了一个中间件，其中工具a发布事件，所有客户端都可以订阅这些事件

我们不喜欢b）。太慢，工具A需要一种方法来确定每个客户端的更改。 c） 有引入新组件的开销。 a） 将两个工具紧密耦合

进一步资料： 我们将在一台机器上拥有一个中央数据存储（+我们的业务逻辑组件）。在其他机器上可能是客户端（比如说，最多20个，不是100个，不是1000个，不是10000个）。 这是一个供应商提供的系统。我们不必为许多想要使用事件的第三方工具做好准备（这将是解决方案c的一个有力指标）

问题: i） 除了a）-c）之外，我们还有什么其他选择？ ii）你会走哪条路，为什么

（我）我脑子里想不出任何东西

---

（ii）选项（c），使用类似

的简单方法，感谢您链接到zeromq！