【SpringCloud】设计原则之数据一致性与设计模式

一、设计原则之数据一致性

数据一致性分以下几种情况。 

• 强一致性

当更新操作完成之后，任何多个后续进程或线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。

• 弱一致性

系统并不保证后续进程或线程的访问都护II返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体地承诺多久之后可以读到。

• 最终一致性 

弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间只要受通信延迟、系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。

在工程实践上，为了保障系统的可用性，系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性来保证数据的最终一致性。 

微服务架构下，完整交易跨越多个系统运行，事务一致性是一个极具挑战的话题。依据 CAP 理论，必须在可用性和一致性之间做出选择。我们认为在微服务架构下应选择可用性，然后保证数据的最终一致性。

在实践中有三种模式： 

• 可靠事件模式

可靠事件模式属于事件驱动架构，当某件重要事情发生时，例如，更新一个业务实体，微服务会向消息代理发布一个事件，消息代理向订阅事件的微服务推送事件，当订阅这些事件的微服务接收此事件时，就可以完成自己的业务，可能会引发更多的事件发布。

• 业务补偿模式

补偿模式使用一个额外的协调服务来协调各个需要保证一致性的工作服务，协调服务按顺序调用各个工作服务，如果某个工作服务调用失败，则撤销之前所有已经完成的工作服务。要求需要保证一致性的工作服务提供补偿操作。

• TCC 模式 

一个完整的 TCC 业务由一个主业务服务和若干个从业务服务组成，主业务服务发起并完成整个业务活动，TCC 模式要求从服务提供三个接口 —— Try（负责资源检测）、Confirm（真正执行业务）和 Cancel（释放 Try 阶段预留的资源）。 

二、设计原则之设计模式

微服务设计模式主要有以下几种：

• 链式设计模式

链式设计模式是最常见的一种设计模式，用于微服务之间的调用，应该请求通过网关到达第一个微服务，微服务经过基础业务处理，发现不能满足要求，继续调用第二个服务，然后将多个服务的结果统一返回到请求中，如图所示。

• 聚合器设计模式

聚合器设计模式是将请求统一由网关路由到聚合器，聚合器向下路由到指定的微服务中获取结果，并且完全聚合，如图所示。首页展示、分类搜索和个人中心等通常都使用这种设计。

• 数据共享模式 

数据共享模式也是微服务设计模式的一种。应用通过网关调用多个服务，微服务之间的数据共享通过同一个数据库，这样能有效的减少请求次数，并且对于某些数据量小的情况非常适用，如图所示。

• 异步消息设计模式

异步消息设计模式乍看起来跟聚合器设计模式很像，唯一的区别就是网关和微服务之间的通信是通过消息队列而不是聚合器的方式来进行的，采用的是异步交互的方式，如图所示。 

参考资料：《微服务架构实战》—— 张锋 

一  叶  知  秋，奥  妙  玄  心