分享事件总线btw客户端应用程序和服务器角色

Question

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

如你所知Vert.x是一个事件循环，它促使你像演员模型一样使用smth。在EventBus的帮助下，单独的演员（Verticle）可以相互通信。

常用方法

AFAIK，安排客户端 - 服务器通信的常用方法是使用下一个方案：

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

Vert.x事件总线桥接方法

让我感到困惑的是，客户端Javascript可以直接与服务器端的每个actor / Verticle进行通信：

1. 客户端在浏览器中初始化Event Bus const eb = new EventBus('http://localhost:8080/eventbus')
2. 客户端将事件直接发送给特定的服务器端actor eb.send('some-address', {name: 'tim', age: 587});
3. 客户端从特定服务器端actor接收答案 eb.registerHandler('some-address', (error, message) => { ... })

问题

1. 使用直接客户 - 演员沟通而不是传统沟通有什么好处？
2. 安全性怎么样？现在每个垂直都应该是安全的吗？
3. 代码简单性如何？从一个方面来看，事情变得有点容易，但你还没有获得单一的切入点。对于具有复杂后端的不重要应用程序，这种新方法是否可以接受？
4. 你会推荐哪一个？

Answer 1

首先，它取决于 - 一如既往。异步和非阻塞通信更resilient than synchronous communication。呼叫者没有被阻止，通信松散耦合。使用事件总线，您还可以从发布/订阅通信（以及其他消息传递模式）中受益。有一本关于反应性消息传递模式的好书，可以使用V. Vernon的Actor模型。

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

如果你有“实时”用例，从某种意义上说，客户需要尽快通知，而不是按重新加载，而不是我会使用事件总线通信（例如聊天等）。但谁说你只能做一件事？您可以通过事件总线通知重要的更改（没有数据），并让客户端通过简单的＆amp;简单的Web服务端点。

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

编辑Plain WebSocket与事件总线桥：

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

  

引擎盖下SockJS首先尝试使用本机WebSockets。如果说   失败，它可以使用各种浏览器特定的传输协议和   通过类似WebSocket的抽象来呈现它们。

Vert.x声明如下：

  

类似WebSocket的界面。

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