Seata简介
Seata的前身是阿里巴巴集团内大规模使用保证分布式事务一致性的中间件,Seata是其开源产品,由社区维护。在介绍Seata前,先与大家讨论下我们业务发展过程中经常遇到的一些问题场景。
业务场景
我们业务在发展的过程中,基本上都是从一个简单的应用,逐渐过渡到规模庞大、业务复杂的应用。这些复杂的场景难免遇到分布式事务管理问题,Seata的出现正是解决这些分布式场景下的事务管理问题。介绍下其中几个经典的场景:
场景一:分库分表场景下的分布式事务
起初我们的业务规模小、轻量化,单一数据库就能保障我们的数据链路。但随着业务规模不断扩大、业务不断复杂化,通常单一数据库在容量、性能上会遭遇瓶颈。通常的解决方案是向分库、分表的架构演进。此时,即引入了分库分表场景下的分布式事务场景。
场景二:跨服务场景下的分布式事务
降低单体应用复杂度的方案:应用微服务化拆分。拆分后,我们的产品由多个功能各异的微 服务组件构成,每个微服务都使用独立的数据库资源。在涉及到跨服务调用的数据一致性场景时,就引入了跨服务场景下的分布式事务。
Seata架构
其核心组件主要如下:
- Transaction Coordinator(TC)
事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚。
- Transaction Manager(TM)
控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议,TM定义全局事务的边界。
- Resource Manager(RM)
控制分支事务,负责分支注册、状态汇报,并接收事务协调器的指令,驱动分支(本地)事务的提交和回滚。RM负责定义分支事务的边界和行为。
Seata的可观测实践
为什么需要可观测?
- 分布式事务消息链路较复杂
Seata在解决了用户易用性和分布式事务一致性这些问题的同时,需要多次TC与TM、RM之间的交互,尤其当 微服务的链路变复杂时,Seata的交互链路也会呈正相关性增加。这种情况下,其实我们就需要引入可观测的能力来观察、分析事物链路。
- 异常链路、故障排查难定位,性能优化无从下手
在排查Seata的异常事务链路时,传统的方法需要看日志,这样检索起来比较麻烦。在引入可观测能力后,帮助我们直观的分析链路,快速定位问题;为优化耗时的事务链路提供依据。
- 可视化、数据可量化
可视化能力可让用户对事务执行情况有直观的感受;借助可量化的数据,可帮助用户评估资源消耗、规划预算。
可观测能力概览
可观测维度 | seata期望的能力 | 技术选型参考 |
---|---|---|
Metrics | 功能层面:可按业务分组隔离,采集事务总量、耗时等重要指标 | |
性能层面:高度量性能,插件按需加载 | ||
架构层面:减少第三方依赖,服务端、客户端能够采用统一的架构,减少技术复杂度 | ||
兼容性层面:至少兼容Prometheus生态 | Prometheus:指标存储和查询等领域有着业界领先的地位 | |
OpenTelemetry:可观测数据采集和规范的事实标准。但自身并不负责数据的存储,展示和分析 | ||
Tracing | 功能层面:全链路追踪分布式事务生命周期,反应分布式事务执行性能消耗 | |
易用性方面:对使用seata的用户而言简单易接入 | SkyWalking:利用Java的Agent探针技术,效率高,简单易用。 | |
Logging | 功能层面:记录服务端、客户端全部生命周期信息 | |
易用性层面:能根据XID快速匹配全局事务对应链路日志 | Alibaba Cloud Service | |
ELK |
Metrics维度
设计思路
- Seata作为一个被集成的数据一致性框架,Metrics模块将尽可能少的使用第三方依赖以降低发生冲突的风险
- Metrics模块将竭力争取更高的度量性能和更低的资源开销,尽可能降低开启后带来的副作用
- 配置时,Metrics是否激活、数据如何发布,取决于对应的配置;开启配置则自动启用,并默认将度量数据通过prometheusexporter的形式发布
- 不使用Spring,使用SPI(Service Provider Interface)加载扩展
模块设计
- seata-metrics-core:Metrics核心模块,根据配置组织(加载)1个Registry和N个Exporter;
- seata-metrics-api:定义了Meter指标接口,Registry指标注册中心接口;
- seata-metrics-exporter-prometheus:内置的prometheus-exporter实现;
- seata-metrics-registry-compact:内置的Registry实现,并轻量级实现了Gauge、Counter、Summay、Timer指标;
metrics模块工作流
上图是metrics模块的工作流,其工作流程如下:
- 利用SPI机制,根据配置加载Exporter和Registry的实现类;
- 基于消息订阅与通知机制,监听所有全局事务的状态变更事件,并publish到EventBus;
- 事件订阅者消费事件,并将生成的metrics写入Registry;
- 监控系统(如prometheus)从Exporter中拉取数据。