微服务方法中的API与事件

Question

就不同类型的请求而言，Smart endpoints and dumb pipes怎么样？

在阅读之后我认为它足以订阅某些事件并处理它。但现在我已经意识到有时你应该打开API（可能不是针对最终客户，而是针对API网关等）。这个可以吗？或者你应该＆＃34; eventize＆＃34; （转换为事件）任何进入微服务云的请求？

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

Answer 1

我们这样做：

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