Seata 简介

Seata 的前身是阿里巴巴集团内大规模使用保证分布式事务一致性的中间件，Seata 是其开源产品，由社区维护。在介绍 Seata 前，先与大家讨论下我们业务发展过程中经常遇到的一些问题场景。

(资料图片仅供参考)

业务场景

我们业务在发展的过程中，基本上都是从一个简单的应用，逐渐过渡到规模庞大、业务复杂的应用。这些复杂的场景难免遇到分布式事务管理问题，Seata 的出现正是解决这些分布式场景下的事务管理问题。介绍下其中几个经典的场景：

场景一：分库分表场景下的分布式事务

起初我们的业务规模小、轻量化，单一数据库就能保障我们的数据链路。但随着业务规模不断扩大、业务不断复杂化，通常单一数据库在容量、性能上会遭遇瓶颈。通常的解决方案是向分库、分表的架构演进。此时，即引入了分库分表场景下的分布式事务场景。

场景二：跨服务场景下的分布式事务

降低单体应用复杂度的方案：应用微服务化拆分。拆分后，我们的产品由多个功能各异的微服务组件构成，每个微服务都使用独立的数据库资源。在涉及到跨服务调用的数据一致性场景时，就引入了跨服务场景下的分布式事务。

Seata 架构

Transaction Coordinator（TC）事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
Transaction Manager（TM）控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议，TM 定义全局事务的边界。
Resource Manager（RM）控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。RM 负责定义分支事务的边界和行为。

Seata 的可观测实践

为什么需要可观测？

分布式事务消息链路较复杂Seata 在解决了用户易用性和分布式事务一致性这些问题的同时，需要多次 TC 与 TM、RM 之间的交互，尤其当微服务的链路变复杂时，Seata 的交互链路也会呈正相关性增加。这种情况下，其实我们就需要引入可观测的能力来观察、分析事物链路。
异常链路、故障排查难定位，性能优化无从下手在排查 Seata 的异常事务链路时，传统的方法需要看日志，这样检索起来比较麻烦。在引入可观测能力后，帮助我们直观的分析链路，快速定位问题；为优化耗时的事务链路提供依据。
可视化、数据可量化可视化能力可让用户对事务执行情况有直观的感受；借助可量化的数据，可帮助用户评估资源消耗、规划预算。

可观测能力概览

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 中拉取数据

TC 核心指标

TM 核心指标

RM 核心指标

大盘展示

Tracing维度

Seata 为什么需要 tracing？

对业务侧而言，引入 Seata 后，对业务性能会带来多大损耗？主要时间消耗在什么地方？如何针对性的优化业务逻辑？这些都是未知的。
Seata 的所有消息记录都通过日志持久化落盘，但对不了解 Seata 的用户而言，日志非常不友好。能否通过接入 Tracing，提升事务链路排查效率？
对于新手用户，可通过 Tracing 记录，快速了解 Seata 的工作原理，降低 Seata 使用门槛。

Seata 的 tracing 解决方案

Seata 在自定义的 RPC 消息协议中定义了 Header 信息
SkyWalking 拦截指定的 RPC 消息，并注入 tracing 相关的 span 信息
以 RPC 消息的发出&接收为临界点，定义了 span 的生命周期范围

基于上述的方式，Seata 实现了事务全链路的 tracing，具体接入可参考为[Seata 应用 | Seata-server]接入 Skywalking[1]。

tracing 效果

基于的 demo 场景：

用户请求交易服务
交易服务锁定库存
交易服务创建账单
账单服务进行扣款

GlobalCommit 成功的事务链路（事例）

Logging 维度

设计思路

Logging 这一块其实承担的是可观测这几个维度当中的兜底角色。放在最底层的，其实就是我们日志格式的设计，只有好日志格式，我们才能对它进行更好的采集、模块化的存储和展示。在其之上，是日志的采集、存储、监控、告警、数据可视化，这些模块更多的是有现成的工具，比如阿里的 SLS 日志服务、还有 ELK 的一套技术栈，我们更多是将开销成本、接入复杂度、生态繁荣度等作为考量。