您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

京东架构师分享:微服务分布式一致性模式

时间:2019-09-04 08:57:12  来源:  作者:

微服务拆分后遇到的一个麻烦是分布后的一致性问题。单体架构的业务处理和数据都在一个进程里面,一致性保障很成熟,开发人员基本上不用关心。当把业务系统拆分到不同进程时,就遇到了技术性一致性问题。这带来了纠结,我们希望有一颗银弹,一把解决问题。但由于分布式一致性在(CAP)理论上没有完美的解决方案,我们所能选择的方案是在特定业务场景下的选择。

我们这里讨论的分布是指业务逻辑上做了拆分导致的分布,而不是数据量特别大导致的分布。

如果业务上不拆分,数据量特别大需要做分布,可以选择支持大数据的分布式数据库。可以选择Cassandra, MongoDB等NoSQL,或者TiDB这类支持SQL的分布式方案。

京东架构师分享:微服务分布式一致性模式

 

如果业务上进行了拆分,不论选什么数据库都不能解决分布式一致性问题。把数据库或者分布式数据库看成是一个系统,能处理一个外部请求在数据库内部的分布式问题,但不能处理多个外部请求的一致性问题。

分布式强一致的数据库不能解决业务逻辑拆分带来的分布式一致性问题,我们还得继续纠结如何解决业务分布式一致性的问题。

首先我把微服务分布式一致性问题分为数据共享一致性和业务交易一致性问题。

数据共享一致性

在单体架构的时候用同一个数据库,不存在数据共享问题。微服务强调要独立数据库,引起数据如何共享的问题。

数据共享分为拉和推两种模式,拉指消费者去供应商那边拉数据,推指供应商主动把数据推到消费者面前。

拉-视图共享

对于一般的企业信息系统,数据量不大,并发需求也不大,我建议所有的微服务用同一个数据库实例,但是拆分在不同的Schema。这样的好处是在业务逻辑上数据库是独立的,也可以独立演进。然后数据库又可以集中管理。 这个方案对于大型遗留系统拆分尤其适用,因为原本就是在一个库里面,为了业务更好的独立演进进行数据库Schema拆分,又能延续原有的数据库实例管理技术。由于不同的微服务实际运行在同一个数据库实例上,可以简单的建视图进行数据共享。 需要注意的是,不要拉整个表出去,根据需要选择几个字段。这种模式技术上简单,坏处有两个:一是由于视图同步的数据是实时的,应用可能基于实时同步数据的假设进行设计,会导致以后做分布式扩展的时候特别困难;二是视图很容易暴露出表结构,这需要特别加强对视图的设计和结构管理,让暴露出去的视图不要直接绑定在现有的表结构上。视图所需的字段是外部需要,而不是表上面有什么。这样视图就是接口,只不过是强耦合在特定的数据库实例上。

拉-API获取

微服务最推荐的方式是服务方提供数据API,消费者需要的时候去拉取。好处是消费者和供应方技术上完全解耦,坏处是提高了开发成本。如果消费者使用API方式获取所需数据,建议使用异步Stream方式进行编程。 如果一次业务请求需要拉取多个数据源,不建议用同步的方式调用,因为会延长处理时间。建议使用reactiveX模式 进行异步拉取和组装 。

推-事件消息

发生事件时发送消息是DDD CQRS模式,即解决了消费者要拥有数据用的爽快的问题(根据需要建立本地数据结构、获取性能和方式), 也解决了数据库技术异构的问题。带来的问题是需要一个消息平台,并且消费者或者供应方都要耦合在一个消息平台技术上。对于大型遗留系统改造不是很友好,一方面遗留系统的消息平台往往不符合高并发大数据量的性能要求,另一方面对于新的微服务也不想依赖老的消息平台,而想要用Kafka这样的互联网高并发轻量的消息平台。

数据共享一致性选择总结:

对于依赖系统改造和数据量不大(日交易量不超过百万)的应用,建议使用不同微服务创建不同Schema,但用同一个数据库实例,然后通过视图的方式进行数据共享。

如果有些业务数据量非常大又需要共享,使用API共享,利用异步Stream编程进行数据共享。

如果微服务平台技术设施成熟,可以使用推送事件消息模式, 即解决共享数据消费便利性问题,又解决数据结构解耦,并且使用轻量消息平台(Kafka)只是有轻度的技术耦合。

业务交易分布式一致性

业务交易分布式一致性指一次请求,但分布在不同的微服务系统处理,引发一致性协调的问题。

交易分布式一致性分为补偿模式,二次提交模式和Saga模式。

补偿模式

补偿模式主要是通过重试达到最后的成功,仅适用于交易请求在业务上必须没有失败的场景。

补偿模式用的最普遍的是消息投递,假设给A发消息,如果没有收到A确认消息已收到,就继续发送,直到A确认收到消息为止。

有很多业务可以变成必须成功的交易。比如下订单付款,如果先确认订单再去扣款,就有可能因为账户没钱扣款不成功,导致业务上的失败。如果业务改成先扣款再去确认订单,那可以认为订单必须要确认成功。通过业务顺序的调整来实现一个交易必须成功的情境。在技术实现上比较简单,利用一个任务队列跟踪任务的完成状态,来决定重试。补偿模式对API的要求是必须要幂等,因为有可能任务已经成功了,但消费者不知道,再次发出任务请求。

二次提交模式

由于补偿模式需要对业务进行调整,适用范围也比较小,我们还是希望有个通用的分布式一致性方案。

最有名的应该是二次提交模式,更具体点是TCC(Try,Confirm,Cancel)。先发起try请求让业务任务参与方做好处理准备,等所有的参与方都做好准备后,再发出confirm进行确认。因为所有的业务参与方都事前做好了准备,在confirm阶段可以确保一次性成功。如果有某个参与方识别,则发cancel进行回滚。这种模式和数据的事务管理基本一样,像JAVA的JTA实现Automikos就是从支持数据库事务,也支持REST API。二次提交虽然能解决事务一致性问题,但成本比较高。一个业务处理必须要拆分为准备和确认执行两个阶段,对业务设计要求和开发成本都比较高。

Sagas模式

Sagas模式在补偿模式和二次提交模式,既简单又能广泛支持分布式事务场景。二次提交模式基于悲观锁,所以先要求任务参与方都做好准备,然后再做执行。Saga和补偿模式是基于乐观锁,先让任务参与方执行,如果执行没响应则要求再次执行。Saga给参与方发出任务后会记录一个event(Saga的中文翻译可以是事迹),所有event都。如果某个参与方执行失败,再发出cancel请求要求所有参与方回退。因为大部分交易请求是成功,这种基于乐观锁的协调机制能达成一致性目的,并降低了开发成本,业务设计上也比较容易理解。目前支持Saga的Java框架有华为开源的servicecomb saga,京东已经有些线上系统用了。还有做CQRS的框架axoniq也实现了saga。



Tags:微服务   点击:()  评论:()
声明:本站部分内容来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除,谢谢。
▌相关评论
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
▌相关推荐
作者:人月神话,新浪博客同名简介:多年SOA规划建设,私有云PaaS平台架构设计经验,长期从事一线项目实践今天我准备重新讲解下微服务的基础概念,关键组件和组件间关系等核心逻辑。这...【详细内容】
2020-07-10   微服务  点击:(0)  评论:(0)  加入收藏
很多程序员每项技术单独拿出来有可能很厉害,例如:springcloud、springboot、redis、nginx、mysql、rabbitMq等,但是普遍缺乏将所有的这些技术整合到一起,从前端到后端,从开发到部...【详细内容】
2020-07-08   微服务  点击:(0)  评论:(0)  加入收藏
1、Spring Cloud介绍Spring Cloud家族有许多成员:Spring Cloud Config - 配置管理工具包,集中化管理集群配置,目前支持本地存储、Git 以及 Subversion;Spring Cloud Bus - 事件、...【详细内容】
2020-06-21   微服务  点击:(1)  评论:(0)  加入收藏
今天我们来讨论微服务架构中的自我恢复能力。通常情况下,服务间会通过同步或异步的方式进行通信。我们假定把一个庞大的系统分解成一个个的小块能将各个服务解耦。管理服务内...【详细内容】
2020-06-14   微服务  点击:(0)  评论:(0)  加入收藏
微服务是什么?抛去教条性质的解释,从巨石应用到微服务应用,耦合度是其中最大的变化。图片来自 Pexels或是将多个模块中重复的部分进行拆分,或是纯粹为了拆分膨胀的单体应用,这些...【详细内容】
2020-06-12   微服务  点击:(1)  评论:(0)  加入收藏
开发排查系统问题用得最多的手段就是查看系统日志,在分布式环境中一般使用ELK来统一收集日志,但是在并发大时使用日志定位问题还是比较麻烦,我们来看下面的图 上图一个用户请...【详细内容】
2020-06-09   微服务  点击:(1)  评论:(0)  加入收藏
IOE架构对于金融业来说,涉及信息安全和成本过高的问题之外,还有许多技术上的问题。IOE架构的本质是“集中式计算+闭源商用系统”,程序运行在少数主机服务器上,底层代码无从得知,...【详细内容】
2020-06-01   微服务  点击:(9)  评论:(0)  加入收藏
微服务现在是一个很火的话题,好像不管项目的大小,适用范围都在往微服务上去靠。这也使得现在如果不会微服务出去都没法和别人聊了。仅从我自己的工作经历来看,尽管我们的项目也...【详细内容】
2020-05-17   微服务  点击:(0)  评论:(0)  加入收藏
基于SpringCloud(Hoxton.SR3) + SpringBoot(2.2.6.RELEASE) 的 SaaS型微服务脚手架,具备用户管理、资源权限管理、网关统一鉴权、Xss防跨站攻击、自动代码生成、多存储系统、...【详细内容】
2020-05-17   微服务  点击:(60)  评论:(0)  加入收藏
当前,传统企业的 IT 系统以单体架构为主,在面对互联网业务的冲击时,系统架构的性能瓶颈逐渐显现。云计算、Docker、DevOps、持续交付等概念的深入人心,以 Spring Cloud 为代表的...【详细内容】
2020-05-10   微服务  点击:(5)  评论:(0)  加入收藏
镜像简介它是一个创建Docker 容器的只读模板,通过DockerFile可以自定义镜像。它也是一个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些...【详细内容】
2020-04-27   微服务  点击:(7)  评论:(0)  加入收藏
docker 镜像操作常用命令(1)、搜索镜像(在dockerhub仓库中查找centos的镜像)[root@localhost docker]#docker search centos找出一堆centos镜像 镜像的结构: registry_name/r...【详细内容】
2020-04-26   微服务  点击:(8)  评论:(0)  加入收藏
1 系统设计1.1 总体框架1.1.1 功能架构微服务平台主要由服务支撑层、基础服务层、通用服务及业务服务层组成,系统总体功能架构图如下: 1) 基础设施微服务平台的基础设施包...【详细内容】
2020-04-19   微服务  点击:(14)  评论:(0)  加入收藏
随着企业数据量持续增长、业务系统日趋复杂、市场竞争日趋激烈,用户需求需要得到越来越及时的响应,用户服务需要不间断地进行。但采用的传统的云计算服务模式,即按照传统模式开...【详细内容】
2020-04-02   微服务  点击:(8)  评论:(0)  加入收藏
1. 前言3 月 10 日,Linux 基金会宣布旗下项目 TARS 正式成立 TARS 基金会,宣称致力于构建微服务。该项目是腾讯公司捐献给 Linux 基金会的一个项目,据称该项目在腾讯已经使用...【详细内容】
2020-03-27   微服务  点击:(7)  评论:(0)  加入收藏
《深入理解Java虚拟机》但要想真的深入理解虚拟机一问肯定远远不够的,但是本文中分三部分对JVM有深入的解析。第1章 走近Java第2章 Java内存区域与内存溢出异常第3章 垃圾收...【详细内容】
2020-03-16   微服务  点击:(17)  评论:(0)  加入收藏
1、Spring BootJava 构建 Spring 应用程序已经有很长一段时间了,Spring Boot 是 Spring 的一个特定版本,它通过对配置细节的处理,使微服务构建更加简便。创建 Spring Boot 旨在...【详细内容】
2020-03-16   微服务  点击:(2)  评论:(0)  加入收藏
在微服务时代,服务数量及规模越来越大,服务的部署及运维的模式如果仍然采用传统方式就会大大增加运维成本。所以微服务时代的运维方式一定是Devops模式,通过构建自动化运维发...【详细内容】
2020-03-16   微服务  点击:(6)  评论:(0)  加入收藏
Java天天 2020-03-11 16:28:57 微服务已成为在 Node.js 中构建可扩展且强大的云应用的主流方法。同时也存在一些门槛,其中一些难点需要你在以下方面做出决策: 组织项目结构...【详细内容】
2020-03-15   微服务  点击:(10)  评论:(0)  加入收藏
一:最初的需求几年前,小明和小皮一起创业做网上超市。小明负责程序开发,小皮负责其他事宜。当时互联网还不发达,网上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求...【详细内容】
2020-03-14   微服务  点击:(82)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条