Architecture 微服务架构-是否需要每个服务都有API

我一直在探索微服务体系结构，尽管我使用的技术是在Microsoft领域，但问题是通用的

我想到了API网关esp用于身份验证之类的事情。我大致遵循的模式是基于CQRS+事件源的

请求->命令##命令总线##->命令处理程序->更改聚合状态->存储事件->PublishDomainEvents->发布集成事件##事件总线-->更新读取模型

ProcessManager（使用者）会多次处理初始命令以协调工作流

所有微服务应用层都使用来自总线的命令，并致力于更改聚合状态。完成后，将更新读取模型存储。目前，只有一个已更新的读取数据库

当我开始使用命令总线时，每个微服务的RESTAPI主要用于Get请求（Read），它将与所有其他服务一样进入相同的Read数据库，REST用于接受来自网关的命令

根据我当前的场景，每个微服务都有RESTAPI有逻辑吗？ 我知道我们可以使用RESTAPI异步推送命令，但当我已经在使用总线时，这又有什么意义呢

但现在我考虑的不是每个服务都有API，而是基于使用情况的API。因此，它不仅限于单个网关，而且很少有网关API项目

这种方法是否存在缺点/缺陷

编辑2-- **如果给出上下文，尝试重新措辞** 我的微服务结构非常相似（与@mrdnk评论的内容相似）。正如你们所说，我将介绍技术，使其更加清晰。我使用RabbitMQ上的公共交通进行服务间通信

到目前为止，客户端应用程序使用了API网关，然后它将调用适当的microsservice API来推送命令对象。API方法本身充当命令处理程序（充当应用程序层）调用聚合并使其进行更改。基于更改的域事件将通过Mediatr在流程中发布。 外部（微服务）世界需要知道的任何事件都会发布在总线上。 我开始查看通信，并对自己说，为什么不将总线也用于命令（作为命令总线）。这样我就可以拥有更多的ReseClient和异步进程

应用层将监听命令并进行适当的处理。这样，我觉得服务更加封装。 在API方面（单个微服务），我不需要公开任何RESTAPI供网关使用。网关中的API将侦听请求并创建命令对象。这将排队等待总线。Microservice上的使用者（命令处理程序）将使用命令等

目前，所有写入都是事件源代码（mongodb）。读取转到SQL Server。 我可以为读取端的查询创建API。再也不需要从Microservice获得Http API了

我知道从技术上讲它会起作用，但不知道是否有任何陷阱

问候,，

---

Mar

我认为让微服务彼此异步通信是一个好主意，在实践中，我也使用这种方法，根据用例将编排和编排结合起来

关于通过互联网向客户（如web客户）公开的公共API，这实际上取决于决定因素和提供的选项。如果您的客户需要基于REST的通信，我建议您同步地提供对客户机的快速响应，只需提供客户机通过的信息和某种唯一id即可

因此，如果您想到在线商店的订单请求，API网关会将请求转发给order Microservice（通过REST，或者在您的情况下，通过消息传递和API网关层从异步到同步响应的转换）。无论如何，应该有某种即时响应给客户订单服务可以提供，它可以简单地包含新订单的id。除此之外，处理订单的其他一切都将通过基于事件的编排（由OrderRequestReceived事件或符合域语言的任何名称启动）或通过订单服务编排的某种工作流（但仍使用异步消息传递）异步进行

然后，客户机可以始终使用订单id查询订单的当前状态，然后根据正在构建的读取模型提供订单

---

如果您可以按照希望的方式自由地实现客户端，那么您也可以查看WebSocket，使用HTTP/2允许推送状态更改，而不是要求客户端轮询当前状态。或者你甚至可以研究gRPC…

我认为让微服务彼此异步通信是一个好主意，在实践中，我也使用这种方法，根据用例将编排和编排结合起来

关于通过互联网向客户（如web客户）公开的公共API，这实际上取决于决定因素和提供的选项。如果您的客户需要基于REST的通信，我建议您同步地提供对客户机的快速响应，只需提供客户机通过的信息和某种唯一id即可

因此，如果您想到在线商店的订单请求，API网关会将请求转发给order Microservice（通过REST，或者在您的情况下，通过消息传递和API网关层从异步到同步响应的转换）。无论如何，应该有某种即时响应给客户订单服务可以提供，它可以简单地包含新订单的id。除此之外，处理订单的其他一切都将通过基于事件的编排（由OrderRequestReceived启动）异步进行