architecture - 在客户端应用程序和服务器参与者之间共享事件总线

Question

通过 Event Bus Bridge 将事件直接从客户端推送到服务器端 verticle 的优点/缺点是什么？ ？换句话说，在客户端应用程序和服务器参与者之间共享事件总线有什么好处？

---

如您所知Vert.x是一个事件循环，敦促您使用类似 Actor 模型的东西。单独的参与者(verticle)可以在 EventBus 的帮助下相互通信。

常见方法

据我所知，安排客户端-服务器通信的常见方法是使用下一个方案:

1. 公开将接受客户端请求的 Web 服务(路由器)
2. Web 服务向 verticle/actor 发送事件。
3. Verticle/actor 进行计算并返回结果
4. Web 服务获取计算结果并将其发送回客户端

Vert.x 事件总线桥接方法

让我困惑的是客户端 Javascript 可以直接与服务器端的每个 actor/verticle 通信:

1. 客户端在浏览器中初始化事件总线 const eb = new EventBus('http://localhost:8080/eventbus')
2. 客户端直接将事件发送到特定的服务器端参与者 eb.send('some-address', {name: 'tim',age: 587});
3. 客户端接收来自特定服务器端参与者的应答 eb.registerHandler('some-address', (error, message) => { ... })

问题

1. 使用直接的客户与参与者沟通而非传统沟通有什么好处？
2. 安全性怎么样？现在每个垂直体都应该是安全的？
3. 代码简单性怎么样？从一方面来看，事情变得更容易了一些，但你不再有单一的入口点。对于具有复杂后端的重要应用程序来说，这种新方法是否可以接受？
4. 您会推荐哪一个？

Answer 1

首先，这取决于情况——一如既往。异步非阻塞通信更resilient than synchronous communication 。调用者不会被阻止，并且通信是松散耦合的。通过事件总线，您还可以从发布/订阅通信(以及其他消息传递模式)中受益。 V. Vernon 提供了一本关于 Reactive Messaging Patterns with the Actor Model 的好书。

关于安全性，您只会allow some queues to be available for clients 。 Vert.x 将这些称为 inbound and outbound addresses 。您不需要“保护”每个 Verticle，因为客户端无法直接访问它们。

如果您有“实时”用例，即需要尽快通知客户端而不按重新加载，那么我会使用事件总线通信(例如聊天等)。但谁说你只能做一件事？您可以通过事件总线通知重要更改(没有数据)，并让客户端通过简单的 Web 服务端点检索更改的数据。

有关 Actor 模型的更多见解，我建议阅读 Concurrency Programming for Scalable Web Architectures或《七周内的七个并发模型》一书。

编辑普通 WebSocket 与事件总线桥:

Vert.x Web 附带 Event Bus Bridge based on SockJS 。它将 Web 客户端与 Vert.x 事件总线集成。 SockJS 甚至可以通过长轮询等技术在旧版浏览器中实现类似 WebSocket 的通信:

Under the hood SockJS tries to use native WebSockets first. If that fails it can use a variety of browser-specific transport protocols and presents them through WebSocket-like abstractions.

Vert.x 声明为:

WebSocket-like interface which just works.

因此，基本上，Vert.x 事件总线桥使用 WebSocket(如果客户端浏览器中可用)。因此，我更喜欢事件总线桥而不是自己的 WebSocket 实现。