通过事件总线桥将事件从客户端直接推送到服务器端顶点的优缺点是什么？换句话说，在客户端应用和服务器参与者之间共享事件总线有什么好处？
如您所知，Vert.x 是一个事件循环，它敦促您使用类似 smth 的 actor 模型。单独的参与者（顶点）可以在EventBus的帮助下相互通信。
通用方法
AFAIK，安排客户端-服务器通信的常用方法是使用下一个方案：
- 公开将接受来自客户端的请求的 Web 服务（路由器）
- 网络服务将事件发送到眩晕/参与者。
- 顶点/参与者进行计算并返回结果
- Web 服务获取计算结果并将其发送回客户端
Vert.x 事件总线桥接方法
让我纠结的是，客户端Javascript可以直接与服务器端的每个actor/verticle进行通信：
- 客户端在浏览器中初始化事件总线
const eb = new EventBus('http://localhost:8080/eventbus') - 客户端将事件直接发送到特定的服务器端参与者
eb.send('some-address', {name: 'tim', age: 587}); - 客户端从特定服务器端参与者接收应答
eb.registerHandler('some-address', (error, message) => { ... })
问题
- 使用直接的客户-参与者沟通而不是传统的沟通有什么好处？
- 安全性如何？现在每个顶点都应该是安全的吗？
- 代码简单性如何？从一方面，事情变得容易一些，但你不再有单一的入口点。对于具有复杂后端的不平凡的应用程序，这种新方法是否可以接受？
- 你会推荐哪一个？
首先，这取决于 - 一如既往。异步和非阻塞通信比同步通信更具弹性。呼叫者未被阻止，通信是松散耦合的。使用事件总线，您还可以从发布/订阅通信（以及其他消息传递模式）中受益。有一本关于 Reactive Messaging Patterns with the Actor Model 的好书，来自 V. Vernon。
关于安全性，您只允许某些队列可供客户端使用。Vert.x 调用这些入站和出站地址。您不需要"保护"每个 Verticle ，因为客户端无法直接访问它们。
如果您有"实时"用例，从某种意义上说，客户端需要尽快收到通知而无需按重新加载，那么我会使用事件总线通信（例如聊天等）。但谁说你只能做一件事呢？您可以通过事件总线通知重要更改（没有数据），并让客户端通过简单明了的 Web 服务端点检索更改的数据。
有关Actor模型的更多见解，我建议阅读可扩展Web体系结构的并发编程或七周内七个并发模型一书。
编辑普通 WebSocket 与事件总线桥：
Vert.x Web带有一个基于SockJS的事件总线桥。它集成了Web客户端和Vert.x事件总线。 SockJS甚至可以通过长轮询等技术在旧浏览器中实现类似WebSocket的通信：
在后台，SockJS首先尝试使用本机WebSockets。如果那样的话失败 它可以使用各种特定于浏览器的传输协议和通过类似 WebSocket 的抽象来呈现它们。
Vert.x 指出：
类似WebSocket的界面，它只是工作。
因此，基本上 Vert.x 事件总线桥使用 WebSocket（如果它在客户端浏览器中可用）。因此，我更喜欢事件总线桥而不是自己的 WebSocket 实现。