5

就不同类型的请求而言，智能端点和哑管道呢？

读完之后，我认为订阅一些事件并处理它就足够了。但现在我意识到有时你应该打开 API（也许不是为最终客户，而是为 API 网关等）。这个可以吗？或者你应该“事件化”（转化为事件）任何来到微服务云的请求？

例如，您有发票和订单服务。很明显，在创建订单时，您可能会使用可能被 Invoice 服务使用的事件来创建发票。很明显，为了接收最后一个用户的订单列表，您可以在订单服务端使用 CQRS，甚至只是创建新服务 LastOrders，这将只保留所需数据的投影。但是这个请求是否应该转换为事件或 LastOrders 应该为此提供 API 并监听事件以更新它自己的数据库？

4

1 回答 1

4

我们这样做：

  • 所有命令都作为消息在具有基于类型的路由的持久队列中发出
  • 处理发生在独立的处理程序中
  • REST POST 和 PUT 仅针对应可从遗留/外部系统访问的 API 创建
  • 这些“命令”风格的 REST 端点仅将命令形成为消息并通过消息总线发送
  • REST GET 非常适合获取数据，我们不在那里使用消息传递，尽管我们可以有一些消息处理程序来为只能使用消息的长时间运行的进程检索数据
  • 命令（消息）处理程序总是发布有关他们已完成或未完成的事件
  • 下游事件处理可以通过订阅这些事件为所欲为
于 2016-06-10T06:43:43.107 回答