微服务架构 - 是否需要每个服务 API
Microservice Architecture - is there a Need to have API per service
我一直在探索微服务架构，尽管我使用的技术属于微软领域，但问题是通用的。
我想到了 API 网关 esp 用于身份验证之类的事情。我大致遵循的模式是基于 CQRS + Event Sourcing
Request-> Command ##CommandBus##->CommandHandler -> Change Aggregate State->Store Events-> PublishDomainEvents ->Publish Integration events ##Event Bus## -----> 更新读取模型
很多时候初始命令将由 ProcessManager（消费者）处理以编排工作流。
所有微服务应用层都使用来自总线的命令并致力于改变聚合状态。完成后，读取模型存储将更新。目前，只有一个读取数据库被更新
当我开始使用命令总线时，每个微服务的 REST API 主要用于 Get 请求（读取），它将与所有其他服务进入相同的读取数据库，其余用于接受来自网关的命令。
根据我当前的场景，每个微服务都有 REST API 是否有逻辑？
我知道我们可以使用 Rest 异步 API 来推送命令，但是当我已经在使用总线时有什么意义呢？
但现在我正在考虑不为每个服务提供 API，而是根据使用情况提供 API。然后它不限于单个网关，而是几个网关 API 项目。
这种方法有什么缺点/陷阱吗？
编辑2--
**如果它提供上下文则尝试改写**
我的微服务结构非常相似（与@mrdnk 评论的一样）。如您所见，我将介绍技术以使其更加清晰。我使用 RabbitMQ 上的 Mass transit 进行服务间通信。
截至目前，我有 API 客户端应用程序使用的网关，然后调用适当的微服务 API 来推送命令对象。 API 方法本身充当命令处理程序（充当应用程序层）调用聚合并使其进行更改。基于更改的域事件在 Mediatr 的流程中发布。
外部（微服务）世界需要知道的任何事件都发布在总线上。
我开始查看通信并自言自语为什么不将总线也用于命令（作为命令总线）。这样我就可以有更多的弹性和异步过程。
应用层会听取命令并适当处理。这样我感觉服务更封装了。
在 API 端（个人微服务），我不需要公开任何其余 api 供网关使用。 API 在网关中将监听请求并创建命令对象。这将排队等候公共汽车。微服务上的消费者（命令处理程序）将消费命令等。
目前所有的写入都是事件源的（mongodb）。读取到 SQL 服务器。
我可以只为读取端的查询创建 API。不再需要来自微服务的 Http API。
我知道技术上它会起作用，但不知道是否有任何陷阱。
此致，
3月
我认为让微服务彼此异步通信是个好主意，在实践中，我也根据用例将这种方法与编排和编排结合使用。
关于您通过 Internet 向您的客户（例如 Web 客户端）公开的 public API，它实际上取决于决定因素和您提供的选项。如果您的客户 需要 基于 REST 的通信，我建议通过仅提供它通过的信息来同步 对客户端的快速响应 某种独特的 ID。
因此，如果您想到在线商店的订单请求，API 网关会将请求转发到订单微服务（通过 REST 或在您的情况下通过消息传递和一些从异步响应到同步响应的转换在 API 网关层）。无论如何，应该有某种 对客户端 订单服务可以提供的即时响应，它可以简单地包含新订单的 ID。处理订单的所有其他事情都将完全通过基于事件的编排（由 OrderRequestReceived 事件或适合领域语言的任何名称开始）或通过订单服务编排的某种工作流（但仍使用异步消息传递）异步发生.
然后客户端始终可以使用订单 ID 查询订单的当前状态，然后您将根据您正在构建的读取模型提供该订单。
如果您可以自由地以想要的方式实现客户端，您还可以查看 WebSockets，使用 HTTP/2 允许推送状态更改，而不是要求客户端轮询当前状态。或者您甚至可以查看 gRPC...
我一直在探索微服务架构，尽管我使用的技术属于微软领域，但问题是通用的。
我想到了 API 网关 esp 用于身份验证之类的事情。我大致遵循的模式是基于 CQRS + Event Sourcing
Request-> Command ##CommandBus##->CommandHandler -> Change Aggregate State->Store Events-> PublishDomainEvents ->Publish Integration events ##Event Bus## -----> 更新读取模型
很多时候初始命令将由 ProcessManager（消费者）处理以编排工作流。
所有微服务应用层都使用来自总线的命令并致力于改变聚合状态。完成后，读取模型存储将更新。目前，只有一个读取数据库被更新
当我开始使用命令总线时，每个微服务的 REST API 主要用于 Get 请求（读取），它将与所有其他服务进入相同的读取数据库，其余用于接受来自网关的命令。
根据我当前的场景，每个微服务都有 REST API 是否有逻辑？ 我知道我们可以使用 Rest 异步 API 来推送命令，但是当我已经在使用总线时有什么意义呢？
但现在我正在考虑不为每个服务提供 API，而是根据使用情况提供 API。然后它不限于单个网关，而是几个网关 API 项目。
这种方法有什么缺点/陷阱吗？
编辑2-- **如果它提供上下文则尝试改写** 我的微服务结构非常相似（与@mrdnk 评论的一样）。如您所见，我将介绍技术以使其更加清晰。我使用 RabbitMQ 上的 Mass transit 进行服务间通信。
截至目前，我有 API 客户端应用程序使用的网关，然后调用适当的微服务 API 来推送命令对象。 API 方法本身充当命令处理程序（充当应用程序层）调用聚合并使其进行更改。基于更改的域事件在 Mediatr 的流程中发布。 外部（微服务）世界需要知道的任何事件都发布在总线上。 我开始查看通信并自言自语为什么不将总线也用于命令（作为命令总线）。这样我就可以有更多的弹性和异步过程。
应用层会听取命令并适当处理。这样我感觉服务更封装了。 在 API 端（个人微服务），我不需要公开任何其余 api 供网关使用。 API 在网关中将监听请求并创建命令对象。这将排队等候公共汽车。微服务上的消费者（命令处理程序）将消费命令等。
目前所有的写入都是事件源的（mongodb）。读取到 SQL 服务器。 我可以只为读取端的查询创建 API。不再需要来自微服务的 Http API。
我知道技术上它会起作用，但不知道是否有任何陷阱。
此致， 3月
我认为让微服务彼此异步通信是个好主意，在实践中，我也根据用例将这种方法与编排和编排结合使用。
关于您通过 Internet 向您的客户（例如 Web 客户端）公开的 public API，它实际上取决于决定因素和您提供的选项。如果您的客户 需要 基于 REST 的通信，我建议通过仅提供它通过的信息来同步 对客户端的快速响应 某种独特的 ID。
因此，如果您想到在线商店的订单请求，API 网关会将请求转发到订单微服务（通过 REST 或在您的情况下通过消息传递和一些从异步响应到同步响应的转换在 API 网关层）。无论如何，应该有某种 对客户端 订单服务可以提供的即时响应，它可以简单地包含新订单的 ID。处理订单的所有其他事情都将完全通过基于事件的编排（由 OrderRequestReceived 事件或适合领域语言的任何名称开始）或通过订单服务编排的某种工作流（但仍使用异步消息传递）异步发生.
然后客户端始终可以使用订单 ID 查询订单的当前状态，然后您将根据您正在构建的读取模型提供该订单。
如果您可以自由地以想要的方式实现客户端，您还可以查看 WebSockets，使用 HTTP/2 允许推送状态更改，而不是要求客户端轮询当前状态。或者您甚至可以查看 gRPC...