架构杂谈《三》

架构杂谈《三》

一致性问题

　　前面的《架构杂谈一》和《架构杂谈二》 杂谈了从服务化到微服务架构的演进，并确定了服务化和微服务架构是一脉相承的。微服务在服务化架构的基础上，对服务化的细节和方案进行了优化和细化，重点突出了无中心化管理的微服务架构，经过对服务进行有效的拆分来实现敏捷开发和自动化部署，并在海量用户的请求下，提升了微服务架构下较细粒度的水平伸缩能力。

　　然而，微服务架构并非万能的它能够说就是一把双刃剑，咱们在享受它带来的便利的同时，也会遇到数据和服务之间不一致性的问题，在为服务架构下多个服务经过非可靠的网络通讯，如何让服务之间高效的通讯和协做，如何解决系统之间状态不一致等问题，这能够说是咱们在使用微服务架构后不得不面对的问题。

一、什么是一致性

　　一致性是一个抽象的概念，在不一样的场景下有不一样的含义，在传统IT时代，一致性一般指强一致性，在杂谈互联网时代的一致性以前，咱们先了解一下互联网时代的特色：

• 互联网时代信息量大，须要很是强大的计算能力
• 互联网时代要求对用户的响应速度快，还要求吞吐量指标向外扩展（水平伸缩）

　　经过这些个互联网时代的特色分析后，咱们发现单节点的服务器没法知足人们的需求，服务节点开始池化。可是池化不是越多越好的（常言说，人多不必定能解决全部问题），还得有序、合理的分配任务，并有效的进行管理，因而在互联网时代讨论最多的话题就是拆分。拆分又通常分为水平和垂直，这不单指对数据库或者缓存的拆分，主要是表达一种分而治之的思想和逻辑

　水平拆分：因为单一节点没法知足性能的需求，须要扩展成多个节点，多个节点之间具备一致的功能，组成一个服务池，一个节点服务一部分的请求量，全部节点共同处理大规模的高并发的请求量。

　垂直拆分：按照功能进行拆分，把一个复杂的功能拆分红多个单1、简单的功能，因为每一个功能职责单1、简单，使得维护和变动变的更容易、简单和安全，因此更易于产品迭代，还可以快速地进行敏捷发布和上线。

　　在这样的一个互联网时代，一致性指分布式服务化之间的弱一致性，包括应用系统的一致性和数据的一致性。

　　不管是水平仍是垂直拆分，都解决了特定场景下的特定问题，然而，拆分后的系统或者服务化的系统的最大问题就是一致性问题。

二、解决一致性问题的思路

　　一、ACID

　　　　如何保证一致性问题呢？咱们在学习关系性数据库时都学习了ACID原理，这里简单的对ACID作个介绍。

　　　　A：原子性

　　　　C：一致性

　　　　 I：隔离性

　　　　D：持久性

　　　　具备ACID特性的数据库支持强一致性，强一致性表明数据库自己不会出现不一致，每一个事务都是原子的（要么成功要么失败），事务间是隔离的，互相不受影响。最终状态是持久的。所以，数据库会从一个明确的状态过渡到另一个明确的状态，中间的临时状态是不会出现的。若是出现也会及时地自动修复，所以是强一致性的。然而，前面提到，互联网项目大多数具备大规模、高并发的特性，必须使用拆分的理念。即便使用关系型数据库，单机是难以知足存储和吞吐量上的性能需求。因为业务规则的限制，咱们没法将相关数据分到同一个数据库分片，这时就须要实现最终一致性。

　　二、CAP　

　　因为对系统或者数据进行了拆分，咱们的系统再也不是单机系统，而是分布式系统。针对分布式系统的CAP原理有三个元素。

　　C：一致性。在分布式系统中的全部数据备份，在统一时刻具备相同的值，全部节点在同一时刻读取的数据都是最新的数据副本。（Consistency）

　　A：可用性，好的响应性能。彻底的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成并进行响应。（Availability）

　　P：分区容忍性。尽管网络上有部分消息丢失，但系统仍然可继续工做。（Partition tolerance）

　　CAP原理说明，任何分布式系统只可知足以上两点，没法三者兼顾。因为关系型数据库是单节点无复制的，所以不具备分区容忍性，可是具备一致性和可用性。而分布式的服务化系统都须要知足分区容忍性，这就须要咱们在一致性和可用性二者中进行权衡选择。

　　三、BASE

　　eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论，BASE理论是对CAP理论的延伸，核心思想是即便没法作到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用能够采用适合的方式达到最终一致性（Eventual Consitency）。（BASE 思想解决了CAP提出的分布式系统的一致性和可用性不可兼得的问题）

　　BASE思想与ACID原理大相径庭，它知足CAP原理，经过牺牲强一致性得到可用性，通常应用于服务化系统的应用层或者大数据处理系统中，经过达到最终一致性来尽可能知足业务的绝大多数需求。

　　BASE思想的三个元素。

　　BA：基本可用（Basically Available）。

　　S：软状态，状态能够在一段时间内不一样步（Soft State）。

　　E：最终一致性，在必定的时间内，最终数据达成一致性便可。（Eventually Consistent）

　　软状态是实现BASE思想的方法，基本可用和最终一致性是目标。以BASE 思想实现的系统因为不保证强一致性，因此系统在处理请求的过程当中能够存在短暂的不一致，在短暂的不一致的时间内，请求处理处于临时状态中，系统在进行每步操做时，经过记录每一个临时状态，在系统出现故障时能够从这些中间状态继续处理未完成的请求或者退回到原始状态，最终达到一致状态 。

　　有了BASE 思想做为基础，咱们对复杂的分布式事务进行拆解，对其中的每一个步骤记录其状态，有问题能够根据记录的状态来继续执行任务，达到最终一致性。

说明：

　　一、参考书籍：《分布式服务架构：原理、设计与实战》

　　二、若有不合适的地方请反馈。综合后更改。