由于Microservices中缺乏ACID交易属性，跨多个Microservices API管理交易的数据完整性是一个巨大的挑战。本文分享了解决此问题的方法。
在单体应用程序中，单个数据库由各种应用程序模块共享。所以，通过ACID交易管理，数据完整性很容易维护。
以Microservices的方式对单体应用进行再造，将它们分解成许多单个且独立的服务。每个服务都有自己的数据库。这使得数据完整性管理异常困难。
有几种方法可以解决这个问题。其中一种方法是在Kafka, RibbitMQ或ActiveMQ等消息代理中使用发布和订阅模型。
在这里，我们将讨论这种方法如何解决基于Microservices的应用程序中的分布式交易管理及其优缺点。
只读交易
当API"X"收到读取请求时，它会将同步的读取事件推送到消息队列中。订阅事件的API会从队列中检索消息，从自己的数据库中读取相应的数据，然后将结果推送到返回队列中。 由于这是一个同步调用，API“X”将等待直到收到所有返回消息，然后它将整体结果返回给它的使用者。如果在收到所有返回消息之前超时，它将向使用者返回带有部分结果的错误。 该方法的优点是可扩展性。通过启动更多的读取API实例，您可以在高负载环境下保持系统吞吐量。缺点是解决方案的复杂性和成本。
CRUD交易
CURD (创建、更新、读取、删除) 交易类似于只读交易。当API"X"收到CRUD请求时，它会将同步或异步的CRUD交易推送到消息队列中。那些订阅事件的API将检索消息并在他们自己的数据库中执行CRUD交易。
对于同步的CRUD交易，这些下游API通过返回队列将结果推送回API"X"。API"X"将等待所有事件状态直到超时，并向其使用者返回成功或失败的状态。
对于异步CRUD交易，API"X"不会等待交易完成，一旦它将所有CRUD事件推送到消息队列中，它就会向其使用者返回完成状态。
这种方法的优点是实现简单，可扩展性强。但是，它的缺点是可能由于服务故障而导致数据完整性问题。
最终一致性
显然，当任何CRUD服务失败时，所描述的方法可能会导致数据完整性问题。因此，我们需要一个错误恢复过程来维护最终一致性。 基本的恢复解决方案是定期跨不同数据库运行的数据协调过程。核对过程将标记出所有存在数据完整性问题的记录和字段。 另一种解决方案是日志扫描和分析。这个解决方案需要分布式日志和监控机制，我们在上一篇文章中已经讨论过。通过扫描和分析日志，我们可以识别所有失败的事务。
有了失败的交易信息或存在数据完整性问题的记录，我们可以手动或自动纠正数据。
最终一致性的优点是简单，而缺点是会存在数据不一致的时间窗口，这对于需要高度数据一致性的系统（例如汇款）是不能接受的。
在接下来的文章中，我们将讨论如何为需要高度数据一致性的系统处理分布式交易。敬请关注。
纬泓是香港、新加坡和中国的顶级金融科技企业。自1998年以来，我们一直在帮助金融机构实施全球银行解决方案。