微服务客户端确认和事件来源 [英] Microservices client acknowledgement and Event Sourcing

问题描述

场景

我正在使用微服务构建快递服务系统.我不确定几件事，这是我的场景

I am building courier service system using Microservices. I am not sure of few things and here is my Scenario

1. Booking API-这是客户下订单的地方
2. 付款API-这是我们根据预订处理付款的地方
3. Notification API-一切完成后，有服务负责发送通知.

系统正在使用事件驱动的体系结构.当客户下订单时，我会在预订API中提交本地交易并发布事件.支付API和通知API已订阅各自的事件.完成付款和通知API后，需要确认返回到Booking API.

The system is using event-driven Architecture. When customer places booking order , i commit local transaction in booking API and publish event. Payment API and notification API are subscribed to their respective event . Once Done Payment and notification API need to acknowledge back to Booking API.

我的问题是

发布活动后，我的预订服务无法阻止该呼叫，并返回到客户端(前端).我的客户端应用程序将如何检查交易状态或知道交易已完成?每隔几秒钟会轮询一次吗?由于这是分布式事务，任何服务都可能中断并且无法确认.在这种情况下，我的客户(前端)将如何知道，因为它将一直等待.我正在考虑有关分布式交易的传奇.

After publishing the event my booking service can't block the call and goes back to the client (front end). How does my client app will have to check the status of transaction or it would know that transaction is completed? Does it poll every couple of seconds ? Since this is distributed transaction and any service can go down and won't be able to acknowledge back . In that case how do my client (front end) would know since it will keep on waiting. I am considering saga for distributed transactions.

实现所有这些的最佳方法是什么?

What's the best way to achieve all of this ?

事件来源

我想实施事件采购以跟踪预订订单的完整跟踪.我必须在活动商店的预订API中实现此功能吗?或者事件存储在服务之间共享，因为我应该从不同的服务中捕获所有事件.实现此目的的最佳方法是什么?

I want to implement Event sourcing to track the complete track of the booking order. Does i have to implement this in my booking API with event store ? Or event store are shared between services since i am supposed to catch all the events from different services . What's the best way to implement this ?

非常感谢，

推荐答案

我对此的可视化方式如下(受Martin Kleppmann的讲话影响

The way I visualize this is as follows (influenced by Martin Kleppmann's talk here and here).

1. 最终用户下订单.该订单已写入Kafka主题.由于Kafka具有日志结构的存储，因此将在最短的时间内保存订单详细信息.这是一个原子操作("ACID"中的"A")-全部或不包含
2. 现在，用户一旦下订单，用户便想读回它(读-写).为此，我们也可以将订单数据写入分布式缓存中.尽管双重写入通常不是一个好主意，因为它可能会导致部分失败(例如，写入Kafka成功，但是写入缓存失败)，但是我们可以通过确保其中一位Kafka使用者将数据写入数据库来减轻这种风险.因此，即使在极少数情况下发生缓存故障，用户也可以最终从数据库读回数据.
3. 创建订单时写入缓存的订单状态为进行中"
4. 然后使用一个或多个kafka消费者组按如下方式处理事件:付款和通知得到正确处理，最终状态将写回到缓存和数据库中

5. 然后，一个单独的Kafka使用者将从付款和通知api接收响应，并将更新写入缓存，数据库和Web套接字

1. The end user places an order. The order is written to a Kafka topic. Since Kafka has a log structured storage, the order details will be saved in the least possible time. It's an atomic operation ('A' in 'ACID') - all or nothing
2. Now as soon as the user places the order, the user would like to read it back (read-your-write). To acheive this we can write the order data in a distributed cache as well. Although dual write is not usually a good idea as it may cause partial failure (e.g. writing to Kafka is successful, but writing to cache fails), we can mitigate this risk by ensuring that one of the Kafka consumer writes the data in a database. So, even in a rare scenario of cache failure, the user can read the data back from DB eventually.
3. The status of the order in the cache as written at the time of order creation is "in progress"
4. One or more kafka consumer groups are then used to handle the events as follows: the payment and notification are handled properly and the final status will be written back to the cache and database

5. A separate Kafka consumer will then receive the response from the payment and notification apis and write the updates to cache, DB and a web socket

然后，网络套接字将更新UI模型，然后通过事件源将更改反映在UI中.

The websocket will then update the UI model and the changes would be then reflected in the UI through event sourcing.

基于评论的进一步说明

1. 这里的基本思想是，我们使用流技术为每个需要其数据的服务构建一个缓存.例如帐户服务需要付款和通知服务的反馈.因此，我们让这些服务将他们对某个Kafka主题的响应写回去，该主题使一些使用者将响应写回到订单服务的缓存中

1. The basic idea here is that we build a cache using streaming for every service with data they need. For e.g. the account service needs feedback from the payment and notification services. Therefore, we have these services write their response to some Kafka topic which has some consumers that write the response back to order service's cache

基于Kafka(或任何类似技术)的ACID属性，该消息将永远不会丢失.最终，我们将一无所有.那是原子性.如果订单服务无法写入订单，则会以同步方式将错误响应发送回客户端，并且用户可能会在一段时间后重试.如果订单服务成功，则对其他服务的响应必须最终流回到其缓存中.如果其中一项服务关闭一段时间，响应将被延迟，但最终将在服务恢复时发送

Based on the ACID properties of Kafka (or any similar technology), the message will never be lost. Eventually we will get all or nothing. That's atomicity. If the order service fails to write the order, an error response is sent back to the client in a synchronous way and the user probably retries after some time. If the order service is successful, the response to the other services must flow back to its cache eventually. If one of the services is down for some time, the response will be delayed, but it will be sent eventually when the service resumes

客户端不需要轮询.结果将通过使用websocket的流媒体传播到它. UI页面将侦听websocket，当使用者将反馈写入缓存时，它也可以写入websocket.这将通知UI.然后，如果您使用Angular或ReactJS之类的东西，则可以使用websocket上收到的值刷新UI的相应部分.在此之前，用户一直看到在创建订单时写入缓存的状态进行中".即使用户刷新页面，也会从缓存中检索相同的状态.如果缓存值到期并遵循LRU机制，则将从DB中提取相同的值，并将其写回到缓存中以服务将来的请求.一旦获得其他服务的反馈，将使用websocket传输新结果.在页面刷新时，可以从缓存或数据库中获得新状态

The clients need not poll. The result will be propagated to it through streaming using websocket. The UI page will listen to the websocket As the consumer writes the feedback in the cache, it can also write to the websocket. This will notify the UI. Then if you use something like Angular or ReactJS, the appropriate section of the UI can be refreshed with the value received at the websocket. Until that happens user keeps seeing the status "in progress" as was written to the cache at the time of order creation Even if the user refreshes the page, the same status is retrieved from the cache. If the cache value expires and follows a LRU mechanism, the same value will be fetched from the DB and wriitten back to the cache to serve future requests. Once the feedback from the other services are available, the new result will be streamed using websocket. On page refresh, new status would be available from the cache or DB

这篇关于微服务客户端确认和事件来源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！