微服务方法中的 API 与事件

Question

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

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

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

Answer 1

我们这样做：

• 所有命令都作为具有基于类型的路由的持久队列中的消息发出
• 处理在隔离的处理程序中进行
• REST POST 和 PUT 仅为应可从旧版/外部系统访问的 API 创建
• 这些“命令”样式的 REST 端点仅将命令形成为消息并通过消息总线发送
• REST GET 非常适合获取数据，并且我们不使用消息传递，尽管我们可以使用一些消息处理程序来检索只能使用消息的长时间运行进程的数据
• 命令（消息）处理程序总是发布有关他们已完成或未完成的操作的事件
• 下游事件处理可以通过订阅这些事件来为所欲为