通过客户端->Api->ESB->Service 从客户端到服务通信的额外层答案

【问题标题】：Extra layer for communication from client to Service via client ->Api->ESB->Service通过客户端->Api->ESB->Service 从客户端到服务通信的额外层
【发布时间】：2020-01-14 23:38:47
【问题描述】：

我们正在构建一个新系统，其中 ESB 是服务通信的中心通道。因为我们不希望我们的 HTML/js 客户端直接与总线交互，所以我们决定引入 Api (ReST-API) 层，客户端将向 Api 发布请求，而不是 API 将消息放入 ESB，相应的服务将订阅该特定消息并将对其进行处理。

所以它会像 UI -> 休息 -> ESB -> 服务

据我所知，没有其他服务会对此特定消息不感兴趣。所以只是想知道我们不能在下面做吗？？

UI->Rest-> 服务并保持 ESB 仅用于服务间通信，而不是从 UI 到服务路径。考虑到将有 1000 个 UI 来服务通信。

【问题讨论】：

为了进一步了解您的问题，您的问题中的“休息”和“服务”有什么区别。理想情况下，后端服务可以是 REST 服务或 SOAP 服务或 Graph QL 服务等，基本上就是您公开服务的方式。
你可以认为Rest只是一个客户端的网关，它没有任何业务逻辑，它的职责仅限于请求验证、认证和构建响应，一旦验证它就会通过请求主要用于业务逻辑的进一步处理。
好的，这完全取决于有多少订阅者（服务）需要来自 UI 的这条消息。到目前为止，您只确定了一项需要此数据的服务。引入 ESB 层将解耦“Rest”和“Service”层，并且将来如果有更多服务需要此消息，ESB 层的一点改变就足以满足您未来的需求，而不会干扰“Rest”和“服务”。如果没有 ESB，您最终会陷入紧密耦合的模式。此外，如果将来该服务得到增强，ESB 可以在数据转换中发挥作用。
如果有此信息，请发表评论。帮助你

标签： asp.net-web-api design-patterns architecture microservices esb

【解决方案1】：

这完全取决于有多少订阅者（服务）需要来自 UI 的这条消息。到目前为止，您只确定了一项需要此数据的服务。引入 ESB 层将解耦“Rest”和“Service”层，并且将来如果有更多服务需要此消息，ESB 层的一点改变就足以满足您未来的需求，而不会干扰“Rest”和“服务”。如果没有 ESB，您最终会陷入紧密耦合的模式。此外，如果将来该服务得到增强，ESB 可以在数据转换中发挥作用。

【讨论】：