REST API 与企业服务总线以集成多个服务3-5 个服务的数量

编程问答 2022-04-30

问题描述

我需要集成 3-5 个由不同团队开发的现有和准备好的服务。这有点像集成几个独立的单体应用程序。

非常需要的功能是有一个中央通信组件，可以记录所有请求（或部分记录，以防它们有很大的负载），以便可以快速查看哪些服务发送了具有什么负载的请求以及何时发送请求出错了。

第二个任务是安全。需要保护服务间通信。

我已经研究这个话题好几天了。这就是我目前想到的：

  1. 使用企业服务总线 (ESB)
  2. 使用 Messagebroker（ActiveMQ、RabbitMQ、Kafka 等）
  3. 只需使用 REST API 通信

我已经阅读过有关 ESB 的内容，但不确定该解决方案是否可以使用。

来自维基百科的图片显示如下：

enter image description here

ESB 的问题在于它不仅实现了单独的独立服务之间的通信。 它还将通信本身从同步请求-响应模型更改为异步消息传递方式。目前，我们不需要异步消息传递（也许将来会，但现在不需要）。

ESB 允许进行请求-响应通信，但以一种非常不方便和复杂的方式生成关联 ID，创建临时响应主题和消费者。有了这个，我怀疑使用 ESB 及其超级复杂的请求-响应消息传递样式或简单地使用普通的旧 REST API 调用 (RPC) 是否具有更多优势。然而，使用 REST API 不可能有一个集中的组件来记录服务之间的所有通信。 Message broker 也存在类似的问题（因为它也涉及异步消息传递）。

是否有任何现成的解决方案/模式可以将多个服务（不是微服务）与集中式日志记录、安全配置以及易于实现的同步请求-响应模型（如果需要，稍后可以添加消息传递）进行集成？

>

解决方法

通过代理来处理这些问题，让您的服务相互通信（早在 2007 年我称之为“edge-component”，但今天它被称为 sidecar pattern）

一种常见的方法是将您的服务容器化，部署到 Kubernetes 并使用服务网格（如 Console 或 istio 等）

enterprise-integrationesbmessagebrokerrestrestsoasoa