华为资深架构师：Cloud Native架构一致性问题及解决方案

时间 2019-12-13

标签华为资深架构师 cloud native 架构一致性问题解决方案栏目云服务繁體版

原文原文链接

内容来源：2017年12月2日，华为资深架构师王启军在“NJSD互联网架构峰会”进行《Cloud Native架构一致性问题及解决方案》演讲分享。IT 大咖说（微信id：itdakashuo）做为独家视频合做方，经主办方和讲者审阅受权发布。
数据库

阅读字数：2092 | 6分钟阅读微信

嘉宾演讲视频及PPT回顾：suo.im/tPQXc
架构

摘要

在开发或软件架构的过程当中，常常会遇到一致性的问题，那么如何去解决权衡。咱们先从理论入手，而后进一步讨论强一致性和最终一致性的解决方案。并发

关于这个概念不少人都有不一样的见解，我认为Cloud Native主要是由架构、组织、工程三部分组成的。大部分公司可能主要是关注架构部分，其实组织方面也是很是重要的，它的价值在于可以实现更快的速度、更好的用户交互体验以及更妥当的系统。分布式

Cloud Native架构主要包含两部分，一个是基础设施这块，另外一个是微服务架构方面。围绕着微服务又扩展出了可用性、一致性以及扩展性部分。微服务

在学术界通常将一致性分为两类，一类是以数据为中心，一类以用户为中心。以数据为中心的，不管有多少个节点都是从总体上来看一致性。而以用户为中心，是从客户端的节点来看待一致性的。性能

严格一致性要求任何写操做都能马上同步到其余全部进程，任何读操做都能读取到最新的修改。好比说有三个节点，当某一个节点的数据a变成1的时候，另外两个节点的a就须要同步改变。调试

严格一致性须要有一个全局时钟才能实现，可是这个全局时钟是很难实现的。因而顺序一致性放弃了它，转而改用分布式逻辑时钟来实现。日志

顺序一致性是指全部的进程以相同的顺序看到全部的修改，读操做未必能及时获得此前其余进程对同一数据的写更新，可是每一个进程读到的该数据的不一样值得顺序是一致的。orm

因果一致性是一种弱化的顺序一致性，若是两个数据之间存在因果关系，那么在后续的全部操做都应该基于这一关系。全部的进程必须以相同的顺序看到具备潜在因果关系的写操做。不一样进程能够以不一样的顺序看到并发的写操做。

提到强一致性，相信你们首先想到的就是两阶段提交。也就是整个交互过程分为两个阶段。第一阶段协调者先向参与者提问是否能够提交，同时锁定数据，第二阶段参与者提交。

这里面存在几个问题，第一阶段锁定数据以后，若是协调者挂掉了，将没有角色去通知参与者是否应该提交，这个数据会被一致锁定。若是第二阶段参与者1提交成功，参与者2提交失败，此时协调者不知道该如何处理，由于参与者1已经提交成功，外部能够访问了。

三阶段提交实际上是把两阶段提交的第一阶段分为了两个阶段，这是为了下降原来第一阶段的死锁的几率。三阶段的第一阶段在询问是否提交的时候并无锁定数据，而是在准备提交的时候才锁定数据。

实际上使用三阶段提交，性能上会有更多的消耗，交互会愈来愈多，可扩展性也不好。

假设有一个服务M须要去调用另外的两个服务A、B，在调用的过程当中失败了话，最多见的作法就是重试。这时就须要去考虑重试的次数、超时时间、间隔时间以及间隔时间的衰减度，而重试没有作好的话就很容易形成系统的负担。

其实彻底能够添加一个日志，而且能够收集到远端。经过收集系统收集到分布式文件系统内，这样就能够不断的去检测这个系统是否有问题。

还有一种解决方案——可靠事件，服务在调用失败后，经过另外一种方式将数据传输到消息队列，而后要被调用的服务去读取消息队列。

对于最终一致性来讲，要么所有成功，要么所有失败。

这须要在写消息的同时，去写一个事件日志。若是一旦失败的能够经过补偿服务不断的遍历事件的这张表，最终拿到消息再去发送时间

Sgae是一个比较早期的事务模型，它的核心思想是将一个长事务拆分为多个本地事务。而process manageer就是负责处理事务拆封的，而后再去调用不一样的服务。

这是一个具体的事务处理流程，这里面须要定时的去作检查判断是否失败，失败了就要发送消息，正向调用时写回退日志。

在作系统的时候你会发现服务是很容易的去扩展的，数据库每每会出现瓶颈，那么如何去平衡压力，有不少的解决方案，TCC就是其中的一种。

TCC的优点在于将数据库的操做，放到业务层处理，平衡了数据库的压力。但同时也付出了必定代价，它增长了业务的复杂度，须要提供相应的Try、Confirm、Cancel接口，并且接口仍是幂等性的。

第一种就是经过数据加锁的方式，第二种是分布式锁，不过这种锁不能保障绝对一致性，第三种方案能够去作惟一约束，在惟一约束无效的状况下能够增长流水表这也是第四种方案。