数据库与微服务的一致性

本文介绍了数据库与微服务的一致性的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

在基于微服务的系统中实现数据库一致性的最佳方法是什么?

What is the best way to achieve DB consistency in microservice-based systems?

在柏林的 GOTO 中，马丁·福勒(Martin Fowler)在谈论微服务和一项规则" 他提到要保留每个服务"数据库，这意味着服务无法直接连接到另一个服务拥有"的数据库.

At the GOTO in Berlin, Martin Fowler was talking about microservices and one "rule" he mentioned was to keep "per-service" databases, which means that services cannot directly connect to a DB "owned" by another service.

这是非常漂亮和优雅的，但实际上它变得有些棘手.假设您有一些服务:

This is super-nice and elegant but in practice it becomes a bit tricky. Suppose that you have a few services:

• 前端
• 订单管理服务
• 会员计划服务

现在，客户在您的前端进行购买，这将称为订单管理服务，该服务将把所有内容保存在数据库中-没问题.此时，还将有一个忠诚度计划服务呼叫，以便它从您的帐户中贷记/借记点.

Now, a customer make a purchase on your frontend, which will call the order management service, which will save everything in the DB -- no problem. At this point, there will also be a call to the loyalty-program service so that it credits / debits points from your account.

现在，当所有内容都在同一台DB/DB服务器上时，一切都变得容易了，因为您可以在一个事务中运行所有内容:如果忠诚度计划服务未能写入数据库，我们可以将整个过程回滚.

Now, when everything is on the same DB / DB server it all becomes easy since you can run everything in one transaction: if the loyalty program service fails to write to the DB we can roll the whole thing back.

当我们在多种服务中进行数据库操作时，这是不可能的，因为我们不依赖于一个连接，也不利用运行单个事务的优势. 保持事物一致，过上幸福生活的最佳方式是什么?

When we do DB operations throughout multiple services this isn't possible, as we don't rely on one connection / take advantage of running a single transaction. What are the best patterns to keep things consistent and live a happy life?

我非常渴望听到您的建议！..并预先感谢！

I'm quite eager to hear your suggestions!..and thanks in advance!

推荐答案

这是非常漂亮和优雅的，但是在实践中会变得有些棘手

This is super-nice and elegant but in practice it becomes a bit tricky

在实践中"的含义是，您需要按照以下规则设计微服务，以便在实现必要的业务一致性时能够做到:

What it means "in practice" is that you need to design your microservices in such a way that the necessary business consistency is fulfilled when following the rule:

该服务不能直接连接到另一个服务拥有"的数据库.

that services cannot directly connect to a DB "owned" by another service.

换句话说-不要对它们的职责做任何假设，并根据需要更改边界，直到您找到一种使之起作用的方法为止.

In other words - don't make any assumptions about their responsibilities and change the boundaries as needed until you can find a way to make that work.

现在，您的问题:

什么是使事物保持一致并过幸福生活的最佳模式?

What are the best patterns to keep things consistent and live a happy life?

对于不需要即时一致性的事情，并且更新忠诚度积分似乎属于该类别，您可以使用可靠的pub/sub模式从一个微服务中分发事件，并由其他微服务处理.可靠的一点是，您需要事件处理方面的重试，回滚和幂等性(或事务性).

For things that don't require immediate consistency, and updating loyalty points seems to fall in that category, you could use a reliable pub/sub pattern to dispatch events from one microservice to be processed by others. The reliable bit is that you'd want good retries, rollback, and idempotence (or transactionality) for the event processing stuff.

如果您在.NET上运行，则一些支持这种可靠性的基础结构示例包括 NServiceBus 和 MassTransit .全面披露-我是NServiceBus的创始人.

If you're running on .NET some examples of infrastructure that support this kind of reliability include NServiceBus and MassTransit. Full disclosure - I'm the founder of NServiceBus.

更新:以下是有关忠诚度积分问题的评论:如果延迟处理余额更新，则客户实际上可能能够订购超出其积分的商品".

Update: Following comments regarding concerns about the loyalty points: "if balance updates are processed with delay, a customer may actually be able to order more items than they have points for".

许多人都在为强一致性而满足这些要求.问题是，通常可以通过引入其他规则来处理这类情况，例如，如果用户最终获得负的忠诚度积分，则可以通知他们.如果T过去了，而忠诚度积分却没有整理出来，请通知用户他们将根据某种转化率向他们收取M的费用.客户使用积分购买商品时，该政策应该对客户可见.

Many people struggle with these kinds of requirements for strong consistency. The thing is that these kinds of scenarios can usually be dealt with by introducing additional rules, like if a user ends up with negative loyalty points notify them. If T goes by without the loyalty points being sorted out, notify the user that they will be charged M based on some conversion rate. This policy should be visible to customers when they use points to purchase stuff.