我一直在探索微服务体系结构，即使我使用的技术是在Microsoft Domain中，但问题是普遍的。
对于诸如身份验证之类的东西，我了解API Gateway的想法。我大致遵循的模式基于CQRS +事件源
请求->命令## CommandBus ##-> CommandHandler->更改聚合状态->存储事件-> PublishDomainEvents->发布集成事件## Event Bus ## ----->更新读取模型
许多初始命令将由ProcessManager（消费者）处理以编排工作流程。
所有微服务应用程序层都使用来自总线的命令，并致力于更改聚合状态。完成后，将更新读取模型存储。当前，只有一个读取数据库已更新
当我开始使用Command Bus时，每个微服务的REST API主要用于获取请求（Read），它将与所有其他服务一起放入同一Read Database中，其余部分用于接受来自网关的Command。
根据我当前的方案，每个微服务具有REST API是否有逻辑？ 我知道我们可以使用Rest API进行Async来推送命令，但是当我已经在使用Bus的时候又有什么意义呢？
但是现在我正在考虑不具有每个服务的API，而是基于使用情况的API。这样，它不仅限于单个Gateway，而很少有Gateway API项目。
这种方法是否存在弊端？
编辑2 - **尝试重新说明是否提供上下文** 我的微服务结构非常相似（类似于@mrdnk所评论的内容）。如您所愿，我将介绍技术以使其更加清晰。我使用RabbitMQ上的大众运输进行服务间通信。
到目前为止，我已经有客户端应用程序使用的API网关，然后它将调用适当的microsservice API来推送命令对象。 API方法本身充当命令处理程序（充当应用程序层）调用Aggregate，并对其进行更改。基于更改的域事件在Mediatr的过程中发布。 外部（微服务）需要知道的任何事件都在总线上发布。 我开始查看通讯内容，对自己说：为什么不同时将总线用于命令（作为命令总线）。这样，我可以进行更灵活和异步的处理。
应用程序层将侦听命令并进行适当处理。通过这种方式，我感觉到服务被更封装了。 在API方面（单个微服务），我不需要公开供网关使用的任何其他api。网关中的API将侦听请求并创建命令对象。这将排队到巴士。微服务上的使用者（命令处理程序）将使用Command等。
当前，所有Writes都是事件源（mongodb）。读去SQL Server。 我可以从Read端仅为查询创建API。完全不再需要来自Microservice的Http API。
从技术上讲，我知道它会起作用，但不知道是否有任何陷阱。
关于， 三月
答案 0 :(得分：0)
我认为让微服务彼此异步通信是一个好主意，在实践中，根据使用情况，我还会结合使用编排和编排来使用这种方法。
关于您通过Internet向客户端（例如Web客户端）公开的公共API，实际上取决于确定因素和提供的选项。如果您的客户需要基于REST的通信，我建议通过仅提供经过Ok的信息和某种唯一ID来同步提供快速响应给客户。
因此，如果您想到了网上商店的订单请求，那么API网关会将请求转发到订单微服务（通过REST或您的情况下通过消息传递，以及API网关层从异步到同步响应的某种转换） 。无论如何，订单服务可以提供对客户的立即响应，其中可以仅包含新订单的ID。然后，用于处理订单的所有其他一切将完全通过基于事件的编排（以OrderRequestReceived事件或与域语言相称的任何名称开始）或通过订单服务组织的某种工作流（但仍使用异步消息传递）完全异步进行。
然后，客户可以始终使用订单ID来查询您要构建的订单的当前状态，而不是根据所构建的读取模型来提供。
如果您可以按照自己的意愿随意实现客户端，则还可以使用HTTP / 2来查看WebSockets，以允许推送状态更改，而不是要求客户端轮询当前状态。或者甚至可以研究gRPC ...