Seata-微服务架构开发的必备利器 | 学习笔记

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 快速学习 Seata-微服务架构开发的必备利器

开发者学堂课程【2022阿里云云原生中间件开发者大会集锦Seata-微服务架构开发的必备利器学习笔记,与课程紧密连接,让用户快速学习知识。

课程地址https://developer.aliyun.com/learning/course/1053/detail/15288


Seata-微服务架构开发的必备利器


内容介绍:

一、社区介绍

二、议题一

三、议题二

本课程分享的主题的话会有两个小的议题,第一个议题是 Seata 社区最近刚刚发布了 Seata1.5.0,在这个版本里有哪些的特性,第二个议题是我们进入 Seata1.5.0的开源版本发布了 Seata1的企业版,企业版如何帮助企业快速的实现迁移上云。


一、社区介绍

首先我们进入第一个议题在进入第一个议题之前的话,我们还是首先来了解一下这个最大社区,Seata1最早是从二零一九年一月正式开园

image.png

Seata1的定位是一款开源的分布式事务解决方案致力于微服务架构下提供高性能或简单易用的分布式事务服务,目前的话更有四种事务模式,其中包括AT事务模式,TCC事务模式,Saga实务模式还有XA事务模式,基本上囊括了市面上大部分的事务模式,可以说是一站式的分布式事务解决方案,那其中的AT事务模式是阿里独创的生物模式,那Saga的话,对市面上主流的RPC框架、数据库都做了一个广泛的集成和支持,也被很多的第三方的社区做了主动或被动地集成,那目前的话还要支持像Java go PHP Python服务员,那目前还有Seata1已经被上千家企业在他们的业务系统中应用,同时的话,在金融领域的话,他们在也在纷纷世界用Seata1去处理他们核心账务问题。

那四大社区的话,到目前为止的话,应该是收获有接近22K的Seata1,有300家的computer是参与了四大社区的代码的提交,那同时的话,那跟其他社区做了非常多的这个集成与被动集成,还有等等的一些框架。


二、议题一

还是回到问题的本身,Seata是为了解决什么样的一个问题?那大家可以想一下,就是最近几年炒得比较火的词就是微服务架构,在微服务架构我们会受到哪些这个复旧一致性的这样一些困扰了?那我下边儿划了有五种场景,比如说在第一种场景中。我们从单纯的应用拆分成若干个微幅

image.png

比如说有abc三个微服务,那这三个微服务比如说有各自不同的团队去维护,那这时候可能是说这个Seata1微服务正在这个发货部署,但是从a这个业务入口的话,他可能有这个相应的一些业务流量的效应,那这时候可能去调c的话,它是调不通的,那这时候一旦说调用不通,可能就会存在这种数据一致性的问题,第二个的话就是说这个c节点同样的可能是出现这些宕机之类的这样一些状况,第三种情况的话,就是可能说是因为这个c的这种负载比较高之类的,或者说是网络抖动的问题,然后一直掉C的时候,出现这种come out这种exception,那这时候对于开发者来说是比较头疼的一个问题,因为你不知道这个C的业务逻辑,他有没有真正的被执行,换句话说就是说我这个C的数据,他到底有没有去落库,有没有落库其实就涉及到了就跟a.节点跟B节点他们的业务数据的一个相对一致性的这样一个问题。

那第四种情况的话,就是可能在这个服务链路里边都有各自的技术站,那不同的技术栈可能有不同的这种,就是基础组件的这种依赖,像比如说我C节点可能像有这种red is的组建了这样的依赖,那可能我去掉ready不疼了,那怎么去整个保证我这个ABC整个服务列入的业务逻辑数据的这样一个相对一致性。那第五种情况下的话,就是这边可能是遇到了一个业务异常,那这个业务异常的话就是可能我对你过来的这个业务逻辑,可能是认为你是一个非法的走不下去的这样的一个业务异常,那这时候我抛出一个异常,应该对于ab来说,还是要去做这个数据的一些回归到,这样才能保证整个数据的账号一致性。但是的话就是如果说是没有这些要逻辑的话,其实是比较难处理,也比较难以保证这个列入恶为服务节点之间的这样的一些数据一致性。

总结来说,我们常见的其实数据一致性的查证就分为两种情况,出现数据一致性场景,一定是说出现了这种异常的常用,但这个异常的话又可以分为是系统异常还是业务异常,那对于系统异常的话,就是刚才我们整概括总结一下,就是说比如说服务不可达,那服务不可达的话,这一块儿就可能出现,比如说像网络宕机,服务上下线,或者说人在下流等等这些突发的导致的这个服务不可达,那第二种就是服务的超时导致的,业务异常来说的话,他可能是第一种就是说,你给我传递过来的这个业务参数,它是一个非法,第二个是一些运行时的这样一些异常,这整体来说就是说出现异常导致数据一致性的这样的一些场景,那这也是我们厂商给我们微服务架构下开发带来的一些很大的困扰,就是Seata1的本身的这样的一个出发点,去解决这种微服务架构下的这种不一致性的困扰。

image.png

那我们总结一下就是分布式事务产生的主要原因是什么,那我主要概括了有四大类,第一类的话其实就是怕数据库的操作,那随着您业务规模的增长的话,其实单固的无论是容量或者是联系数其实都是难以满足我的这样的一个业务的需求,他就会出现这种分布的情况,一旦出现分布,就会出现这种分布式业务场景,那第二个就是跨系统的事务,那跨系统的测试失误的话其实又可以分为就是说你是跟第三方的系统,比如说你去调这个第三方的支付那可能是不同的系统之间会产生这个分布式事务的问题,那另外的话就是说可能是你们企业内部的这样一些系统,比如说我去做这个交易的时候,首先是要去做过这个风控的这样的系统,那这时候其实系统跟系统之间的交互他也会产生这样的一个就是分布式事务这样的一个问题,第三个的话就是在微服务常见的就是一个跨服的根本事物场景,那一旦说你这个业务服务化之后,资源跟客户端的吊顶其实是结合的,那同时的话其实我又要保证多个微服务间的变化它是一个强一致的,那这时候就可能出现这个业务数据不完整,中间状态的这样的一些问题,所以这时候也是需要这样一个分布式事务,那第四种的话就是往往就是说我们在右系统可能有这种发消息的这样一个场景,那这时候就产生了就是说我多个DB跟这个消息之间要保证一个相对的数据一致性,那总结来说的话就是他们是不是产生的主要原因是怕数据库操作跨系统的上面事务,还有跨服的百分之一以及跨数据库分销系统的这样一个失误,这是几个常见的产生专门事务的这样一些原因,当然还有其他的一些可能是产生的原因,比如说其他的一些比如说非数据库非消息等等,和其他的一些依赖。

image.png


三、议题二

介绍一下就是 Seata1.5.0的一些特性,我们之后我们去做了一个总结复盘,我们统计了有六十家的控制 beauty 是参与了整个 Seata1.5.0代码的提交,一点儿五点儿零戴上就让一个踢掉贡献6万多代码,删除近有1万号的代码,它是累计修改了文件有872个,那累计合并了Pr数有230个,其中的话就是包含新特性有30多个,修复的问题的话是有60多个,那还有一些优化测试承购之类的,那这些PR的话是有100多个,那在这些修改中的话,主要一些新增的特性是什么?

首先新增的特性是就是我们支持了用户仲裁,那这个是大家期待已久的这样的一个功能,就是我右边第一张图是一个千呼万唤始出来的这样一个四大平台。那第二个的话就是我们支持了像这个scar working that raising集成,大家都知道就是Seata的话,它其实定位。

也是一款数据证券,对于数据证券的ATM的监控来说是至关重要的,那同时的话,在新的竞争,我们也支持像BRCHF等等这样的一些RPC框架,那同时的话就是也解决了困扰大家已久使用。那在之前的话都是有业务自己去保证这些些问题。

在Seata1.5.0是通过框架的层面去自动的去保证TCC幂等,还有悬挂的这样一些问题。那这就是大大降低了开发者使用信息。新模式的这样入门的一个难度啊,同时的话我们再向server这一块儿的话,是也支持着他们这样的一个调动,这对我们的性能开销是减轻了很多,但同时的话,我们也是支持相类似redis存储lua模式。

支持了ON DUPLICATE KEY UPDATA这样的等等一些语法解析。

image.png

那这个的话我是截图了我们Seata1.5.0的业务控制台的一个页面是左上方,在这个界面儿里边能看到就是那个server后端存储连接的通道的信息,还有这个分支事务的信息,以及分支事务对应的这个全球所的这样的一些信息。

都可以从做这个控制台里面去按照条件筛选去展示,那当时的话,刚才提到就是在1.5.0的版本的话,其实我们跟scar working做了一个生态这样的一个继承。那在左下角的话是大家能看到是一个应用拓扑图,包括可以非常清楚的了解我们整个应用的一个拓扑。那还有一个就是说我们在右边的话,能看到我们整个服务链路的它的一个过程,比如说你这个服务是怎么调用的,对于Seata1.5.0这块的RBC,它是怎么去交互,它这个就是推送的,这个交互的话是一直会传递到其他Seataserver的话,能通过Seata server这一块的话,就是它的GBC的一个过程是怎么交付的,每一个过程的一些耗时之类的,都能通过这个Tracy的这个链路,有一个直观的一个体现。非常感谢这个start working对我们下社区的一个帮助和支持。

那第二个议题的话是就是基于Seata1.5.0的这样一个版本,正式发布了Seata1的企业版,那四大企业版也是在上个月中下旬的时候,我们正式宣布了一个更侧,那四大企业版这一块它如何帮助用户去做一个平凡的迁移上云。

image.png

那目前的话就是Seata1企业版,它提供了一种就是免运维高性能的企业级的专门是解决方案,还是100%能够去兼容开源的。那目前的话就是他在那个阿里云的北京区域正式上线公测了,那他的这个入口是在那个微服务引擎sd控制台的入口,有一个分布式事物的这样一个菜单,大家通过这个菜单可以去做免费的一个开灯,左下角的话是Seata1企业版整体一个架构

它的架构其实是跟这个开源版是完全一致的。那它有哪些不一样的点?其实就是说大家看到这个Seata这样的一个就是逻辑架构图的话,它除了就是我左边画的这个user APP,跟随他相关的这些角色,就是Tm2的角色,因为大家知道这个角色其实是位于Seata里边儿的这个大包里边这样一个逻辑角色,那剩余的这一块的话,就是像这个Seata依赖的这个注册中心,配置中心,以及Seata本身的节点,以及他后端的存储,那目前指向这个几率readings,像右边的这整个部分,其实他都是一个就是托管的,就是用户完全不需要去操心,那用户有一个什么样的好处就是你直接在这个sd控制台里面全部是我这里边去点创建Seata实力,那他后端的整个的就是依赖的负责中心四大节点,因为它后端参数它会一件给你拉起来一会儿完全不需要去手动搭建这个先搭建后端的存储,然后去拉起这个server的人气,注入一些这个元数据、环境变量,然后去把相关的依赖的一些配置推到这个配置中心,然后同时的话,这个拉起在搜索界面然后注册到这个注册中心,然后给客户端做这个服务的发现,这个其实是一个非常繁琐的一个过程,那相比的话,就是Seata的企业本跟私建的这个其它版本儿它有哪些优势?

们做了一个简单的这样的一个对比。那首先是咱们这个效率跟性价比上来说的话,就是最大的企业版,就是像我刚才说的,他的资源其实是全托管的,免运维的,同时的话,它内置了依赖了主体中心,配置中心,支持故障节点的这样一个自动下线,计算版本的话,其实这一块儿就需要用户自己去购买各种资源去搭建他们的系统,运维升级的话是需要投入精力,人工成本的话其实是相对比较高。那对于这大企业版来说的话就是整个的它是一个白屏化的一个可视化的这样一个运维操作,那对于四件的这个Seata版本的话它其实是不支持一个格式化的操作,比如说你去拉起,需要这种配件画的一些命令行操作,包括是上传配置脚本等等,对于这个字典版本的话,另外的话他就是你需要比如会支持很多的这种不同类型的不同更新,那这时候就要根据不同的配置出现更新的类型手动的去添加这个事物规则,还有事物路由的一些配置,去手动的修改节点,那这时候会涉及很多的这个元数据的修改,不同的节节点又多,那这时候其实是非常的容易出错,第二个的话是关于这个性能上的一个对比,对性能上面带这个Seata企业版的话,他是做了一个深度的这样一个调优,它整体的话比Seata1.5.x的这样一个内存性能是提升了百分之三十,这是纯粹这个内核代码层面的这个提升,Seata这个四件版本的话就是需要用户去这个自行的去做那个若干参数的调优,大家知道就是Seata给他做了其实很多的这种产业化的支持,但是不同的插件化的支持,它是需要比如说像这个序列化之类的这样的压缩等等这样一些操作,第三个的话就是最大的企业版它是其中的一个非常完善或者专业的可观测性,它是基于这个就是普罗米修斯卡罗拉大盘,给用户提供了像很多维度的,比如说像实物量、正常异常事务、事务的这个gps等等一些非常专业指标的这样一些监控,那自建其他版本的话,就是需要用户自己去搭建报警体系,另外从高可用应上来说的话,就是Seata企业这块是支持一个多培养区的一个部署,它有这个故障的自动检测和恢复机制,自建版本的话就是需要人工去处理,然后自行去设计这样一些高可用策略,那在安全这一块的话是最大企业版它是支持了像这个rom的健全,那么用户可以通过room用户去管理实际的这样一些访问的这样一些权限,那自建版本它是没有这个健全的这样一个实践,需要用户自己去对于健全或者是安全这块做一个二次开发,那这个是我通过一个就是简单的压测去比较了一下就是四大企业版跟开源版的这样一个性能对比,那上面的话是一个基于Seata1.5.0版本去深度定制了一个企业版的1.5.0的这个版本,

image.png

那从这个图上来可以看到,就是说首先是从这个这一块儿来看看GPS,从上图的这个自建版本的话,大家能看到整个其实抖动非常的明显,但是对于企业感来说的话,是相对来说是比较平滑的,那他这个抖动的其实这个振幅是比较高的,对四件那这一块的话,我们是在那个企业版对深度去做了这个去毛刺的这样的一些处理。

那整体的我们接下来咱们这个gps来看的话,我企业版是整体时提升了由百分之三十以上,那另外的话是从这个单链路的这个事物的it的这样开销,我们大概呃测了一下,就是那在这个四年版本的这个对Seata1.5.0的话,它的平均的jsp是四十四横着,对于企业版这一块儿来说,它整体的这个it的话是三十四换掉,整体的话从这个ip上来看的话,就是企业版相比这个自建版开始降低了有百分之二十以上,同时也是我们能看到就是这个lt的话最简单的这个ip的话这个上下抖动也是比这个企业版的要振幅比较大了很多,这块的话我们就是做了去毛刺的一个处理,这个四大企业版的一个开通,其实四大企业版的开通就是非常简单的,一共是需要三部,那第一步的话就是进入刚才我说的就是这个VIVO s的这个控台里边,这个分配事物在这个世界列表里边去创建最大实力,那这个创建四大实力的话,就是目前的话是在公测阶段是完全免费的,那创建实例的话,会要求用户去填写一下这个Vicki、交换机等等一些信息。

然后输入这些参数之后,点创建那这个实力,就创建完成了,那这个过程是非常快,大概是一分钟,整个实力就创建完成了,那第二步的话就是我们创建完了Seata实力之后,接着要去创建这个四大社会分组,这个创建社会分组的时候我们潜入就是我们要使用的这个Seata事务分组的这样一个名称,然后它会自动会跟着上面这个四大实力去做一个关联映射,那了解Seata的同学大概对社会分组也有一个基本的一个概念就是十五分组它是一个软隔离多组的这样一个概念,它其实类似于像这个数据库实例下的这个库这样的概念,还有像这个q里边的这样的一些逻辑概念,这个概念的话它主要是提供了一个什么样的盾,就是提供了一个这个事务服务路由的这样一个信息,那他可以在这个比如说切换可以动态的去做这个项目路由的一个切换,那第三部的话就是我们主要只要复制相应的配置到这个应用里面去,就可以在我们的本地去跑起来,这会有一个显示配置,这样一种我们只需要把这些配置判断c rv复制到我们这个就是配置文件,来然后就跑起来了,整体的话就是非常的简单,这就是整个开通这个四大企业版的这样一个过程。

相关文章
|
1月前
|
消息中间件 API 持续交付
后端开发中的微服务架构实践####
【10月更文挑战第21天】 本文深入探讨了微服务架构在后端开发中的应用,从基本概念出发,详细阐述了微服务的核心优势、设计原则及关键技术。通过实际案例分析,揭示了微服务如何助力企业应对复杂业务需求,提升系统的可扩展性、灵活性与可靠性。同时,也指出了实施微服务过程中可能面临的挑战,并提供了相应的解决方案和最佳实践。 ####
31 3
|
10天前
|
机器学习/深度学习 前端开发 算法
婚恋交友系统平台 相亲交友平台系统 婚恋交友系统APP 婚恋系统源码 婚恋交友平台开发流程 婚恋交友系统架构设计 婚恋交友系统前端/后端开发 婚恋交友系统匹配推荐算法优化
婚恋交友系统平台通过线上互动帮助单身男女找到合适伴侣,提供用户注册、个人资料填写、匹配推荐、实时聊天、社区互动等功能。开发流程包括需求分析、技术选型、系统架构设计、功能实现、测试优化和上线运维。匹配推荐算法优化是核心,通过用户行为数据分析和机器学习提高匹配准确性。
38 3
|
8天前
|
前端开发 搜索推荐 安全
陪玩系统架构设计陪玩系统前后端开发,陪玩前端设计是如何让人眼前一亮的?
陪玩系统的架构设计、前后端开发及前端设计是构建吸引用户、功能完善的平台关键。架构需考虑用户需求、技术选型、安全性等,确保稳定性和扩展性。前端可选用React、Vue或Uniapp,后端用Spring Boot或Django,数据库结合MySQL和MongoDB。功能涵盖用户管理、陪玩者管理、订单处理、智能匹配与通讯。安全性方面采用SSL加密和定期漏洞扫描。前端设计注重美观、易用及个性化推荐,提升用户体验和平台粘性。
34 0
|
24天前
|
运维 监控 Java
后端开发中的微服务架构实践与挑战####
在数字化转型加速的今天,微服务架构凭借其高度的灵活性、可扩展性和可维护性,成为众多企业后端系统构建的首选方案。本文深入探讨了微服务架构的核心概念、实施步骤、关键技术考量以及面临的主要挑战,旨在为开发者提供一份实用的实践指南。通过案例分析,揭示微服务在实际项目中的应用效果,并针对常见问题提出解决策略,帮助读者更好地理解和应对微服务架构带来的复杂性与机遇。 ####
|
23天前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
35 1
|
28天前
|
监控 Serverless 云计算
探索Serverless架构:开发实践与优化策略
本文深入探讨了Serverless架构的核心概念、开发实践及优化策略。Serverless让开发者无需管理服务器即可运行代码,具有成本效益、高可扩展性和提升开发效率等优势。文章还详细介绍了函数设计、安全性、监控及性能和成本优化的最佳实践。
|
24天前
|
消息中间件 运维 API
后端开发中的微服务架构实践####
本文深入探讨了微服务架构在后端开发中的应用,从其定义、优势到实际案例分析,全面解析了如何有效实施微服务以提升系统的可维护性、扩展性和灵活性。不同于传统摘要的概述性质,本摘要旨在激发读者对微服务架构深度探索的兴趣,通过提出问题而非直接给出答案的方式,引导读者深入
43 1
|
25天前
|
负载均衡 监控 API
后端开发中的微服务架构实践与挑战
本文深入探讨了微服务架构在后端开发中的应用,分析了其优势和面临的挑战,并通过案例分析提出了相应的解决策略。微服务架构以其高度的可扩展性和灵活性,成为现代软件开发的重要趋势。然而,它同时也带来了服务间通信、数据一致性等问题。通过实际案例的剖析,本文旨在为开发者提供有效的微服务实施指导,以优化系统性能和用户体验。
|
1月前
|
消息中间件 运维 开发者
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在后端开发中的应用,从其核心概念、设计原则到实际部署过程中面临的挑战进行了全面剖析。不同于传统的单体应用,微服务通过将复杂系统拆解为一系列小型、独立的服务,提高了系统的灵活性和可维护性。然而,这种架构的转变也伴随着服务间通信、数据一致性、部署复杂性等新问题。本文旨在为开发者提供一套应对这些挑战的策略,同时分享一些成功案例,以期促进微服务架构的有效实施。 ####
|
1月前
|
缓存 负载均衡 API
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的可扩展性、灵活性及易于维护的特点,成为众多企业后端开发的首选架构模式。本文将深入探讨微服务架构的核心理念,通过具体案例分析其在实际应用中的实践策略与面临的挑战,为读者提供一份详尽的微服务架构实施指南。 ####