soa - API 与微服务中的事件方法

Question

怎么样Smart endpoints and dumb pipes在不同类型的请求方面？

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

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

Answer 1

我们这样做:

所有命令都作为基于类型路由的持久队列中的消息发出

处理发生在隔离的处理程序中

REST POST 和 PUT 仅为应可从遗留/外部系统访问的 API 创建

这些“命令”样式的 REST 端点仅将命令作为消息形成并通过消息总线发送

REST GET 非常适合获取数据，我们不使用消息传递，尽管我们可以有一些消息处理程序来为只能使用消息的长时间运行的进程检索数据

命令(消息)处理程序总是发布关于他们已完成或未完成的事件

下游事件处理可以通过订阅这些事件来为所欲为