构造BRS服务(Business Reconcilition Service)为你的微服务系统数据一致性保架护航

背景

在微服务架构下， 很好的定义了系统的边界，把许多系统的错误都做了很好的隔离。但是微服务系统架构也带来分布式系统下带来一些新的问题， 比如分布式事务的处理， 复杂的远程调用关系等，有非常高的概率会因为网络、硬件或其他系统问题造成业务处理异常。任何一个微服务组件故障都会影响到对该服务的消费者的业务完整性。

在些我推荐为我们的微服务系统构建一个BRS来监听，通知，检查， 以及修复业务异常，争取比用户更早得到异常通知，为我们运维人员争取更多的时间来定位及修复问题， 来提升我们系统运营效率。

常见数据一致性的处理方式

数据一致性的处理通常分为以ACID为特性的强一致性和以BASE为特性的最终一致性。

ACID vs Base
The key ACID guarantee is that it provides a safe environment in which to operate on your data. The ACID acronym stands for:

ACID定义:

• Atomic： All operations in a transaction succeed or every operation is rolled back.
• Consistent：On the completion of a transaction, the database is structurally sound.
• Isolated： Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially.
• Durable： The results of applying a transaction are permanent, even in the presence of failures.

BASE定义

• Basic Availability: The database appears to work most of the time.
• Soft-state: Stores don’t have to be write-consistent, nor do different replicas have to be mutually consistent all the time.
• Eventual consistency: Stores exhibit consistency at some later point (e.g., lazily at read time).

记录业务异常

在记录异常之前需要定义清楚什么是业务异常， 那在本文认为的业务异常的是指当时的计算资源及业务数据下无法满足业务规则而只能中断当次业务处理流程的异常， 这类异常大多在资源满足或数据补齐后可继续业务处理，而有少量的是无法进一步处理需要业务人员确认后进行人工干预。

通过消息中间件来解耦服务间依赖

微服务已经按业务领域划分各自边界， 那服务间的互动建议通过RabbitMQ这样的消息中间来传递，以解除微务间的强依赖。 以订单支付为例，当用户支付完成一笔订单，支付系统发出一条支付完成的消息给RabbitMQ, 订单服务和库存服务等相应的监听到该条支付成功进行后续的业务操作。

构建BRS服务监听，修复业务异常

还是以订单支付例， 当用户支付完成后，在订单服务收到支付完成的消息支更新订单状态是有可能发生错误的， 那当错误发生时需要同时往RabbitMQ发送一条业务异常消息，此消息应该包含发生错误时的详细信息以及当前处理的业务单据的所有上下文信息。
构建一个BRS服务从RabbitMQ里接收所有的业务异常消息， 并通知业务运营人员。当业务运营人员收到通知后，通过从BRS服务看到错误的信息及该笔业务单据的上下文信息，通过诊断可以做出处理决定是【重试业务处理】，【人工介入修复】【忽略些异常】。

最终实现序列图

ditributed-transation-sequence