邯郸制作网站的公司,杭州知名网页设计服务商,奉贤青岛网站建设,网站制作预算一致性问题前面的《架构杂谈一》和《架构杂谈二》 杂谈了从服务化到微服务架构的演进#xff0c;并肯定了服务化和微服务架构是一脉相承的。微服务在服务化架构的基础上#xff0c;对服务化的细节和方案进行了优化和细化#xff0c;重点突出了无中心化管理的微服务架构… 一致性问题 前面的《架构杂谈一》和《架构杂谈二》 杂谈了从服务化到微服务架构的演进并肯定了服务化和微服务架构是一脉相承的。微服务在服务化架构的基础上对服务化的细节和方案进行了优化和细化重点突出了无中心化管理的微服务架构通过对服务进行有效的拆分来实现敏捷开发和自动化部署并在海量用户的请求下提高了微服务架构下较细粒度的水平伸缩能力。 然而微服务架构并不是万能的它可以说就是一把双刃剑我们在享受它带来的便利的同时也会遇到数据和服务之间不一致性的问题在为服务架构下多个服务通过非可靠的网络通信如何让服务之间高效的通信和协作如何解决系统之间状态不一致等问题这可以说是我们在使用微服务架构后不得不面对的问题。1、什么是一致性 一致性是一个抽象的概念在不同的场景下有不同的含义在传统IT时代一致性通常指强一致性在杂谈互联网时代的一致性之前我们先了解一下互联网时代的特点互联网时代信息量大需要非常强大的计算能力互联网时代要求对用户的响应速度快还要求吞吐量指标向外扩展水平伸缩 通过这些个互联网时代的特点分析后我们发现单节点的服务器无法满足人们的需求服务节点开始池化。但是池化不是越多越好的常言说人多不一定能解决所有问题还得有序、合理的分配任务并有效的进行管理于是在互联网时代讨论最多的话题就是拆分。拆分又一般分为水平和垂直这不单指对数据库或者缓存的拆分主要是表达一种分而治之的思想和逻辑 水平拆分由于单一节点无法满足性能的需求需要扩展成多个节点多个节点之间具有一致的功能组成一个服务池一个节点服务一部分的请求量所有节点共同处理大规模的高并发的请求量。 垂直拆分按照功能进行拆分把一个复杂的功能拆分成多个单一、简单的功能由于每个功能职责单一、简单使得维护和变更变的更容易、简单和安全所以更易于产品迭代还能够快速地进行敏捷发布和上线。 在这样的一个互联网时代一致性指分布式服务化之间的弱一致性包括应用系统的一致性和数据的一致性。 无论是水平还是垂直拆分都解决了特定场景下的特定问题然而拆分后的系统或者服务化的系统的最大问题就是一致性问题。2、解决一致性问题的思路 1、ACID 如何保证一致性问题呢我们在学习关系性数据库时都学习了ACID原理这里简单的对ACID做个介绍。 A原子性 C一致性 I隔离性 D持久性 具有ACID特性的数据库支持强一致性强一致性代表数据库本身不会出现不一致每个事务都是原子的要么成功要么失败事务间是隔离的互相不受影响。最终状态是持久的。因此数据库会从一个明确的状态过渡到另外一个明确的状态中间的临时状态是不会出现的。如果出现也会及时地自动修复因此是强一致性的。然而前面提到互联网项目大多数具有大规模、高并发的特性必须使用拆分的理念。即使使用关系型数据库单机是难以满足存储和吞吐量上的性能需求。由于业务规则的限制我们无法将相关数据分到同一个数据库分片这时就需要实现最终一致性。 2、CAP 由于对系统或者数据进行了拆分我们的系统不再是单机系统而是分布式系统。针对分布式系统的CAP原理有三个元素。 C一致性。在分布式系统中的所有数据备份在统一时刻具有相同的值所有节点在同一时刻读取的数据都是最新的数据副本。Consistency A可用性好的响应性能。完全的可用性指的是在任何故障模型下服务都会在有限的时间内处理完成并进行响应。Availability P分区容忍性。尽管网络上有部分消息丢失但系统仍然可继续工作。Partition tolerance CAP原理说明任何分布式系统只可满足以上两点无法三者兼顾。由于关系型数据库是单节点无复制的因此不具有分区容忍性但是具有一致性和可用性。而分布式的服务化系统都需要满足分区容忍性这就需要我们在一致性和可用性两者中进行权衡选择。 3、BASE eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结在ACM上发表文章提出BASE理论BASE理论是对CAP理论的延伸核心思想是即使无法做到强一致性Strong ConsistencyCAP的一致性就是强一致性但应用可以采用适合的方式达到最终一致性Eventual Consitency。BASE 思想解决了CAP提出的分布式系统的一致性和可用性不可兼得的问题 BASE思想与ACID原理截然不同它满足CAP原理通过牺牲强一致性获得可用性一般应用于服务化系统的应用层或者大数据处理系统中通过达到最终一致性来尽量满足业务的绝大多数需求。 BASE思想的三个元素。 BA基本可用Basically Available。 S软状态状态可以在一段时间内不同步Soft State。 E最终一致性在一定的时间内最终数据达成一致性即可。Eventually Consistent 软状态是实现BASE思想的方法基本可用和最终一致性是目标。以BASE 思想实现的系统由于不保证强一致性所以系统在处理请求的过程中可以存在短暂的不一致在短暂的不一致的时间内请求处理处于临时状态中系统在进行每步操作时通过记录每个临时状态在系统出现故障时可以从这些中间状态继续处理未完成的请求或者退回到原始状态最终达到一致状态 。 有了BASE 思想作为基础我们对复杂的分布式事务进行拆解对其中的每个步骤记录其状态有问题可以根据记录的状态来继续执行任务达到最终一致性。说明 1、参考书籍《分布式服务架构原理、设计与实战》 2、如有不合适的地方请反馈。综合后更改。
