ToB企服应用市场:ToB评测及商务社交产业平台

标题: Seata 的可观测实践 [打印本页]

作者: 郭卫东 时间: 2024-12-10 15:08
标题: Seata 的可观测实践
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 的一套技术栈，我们更多是将开销成本、接入复杂度、生态繁荣度等作为考量。
日志格式设计

这里拿 Seata-Server 的一个日志格式作为案例：

线程池规范命名：当线程池、线程比较多时，规范的线程命名能将无序执行的线程执行次序清晰展示
方法全类名可追溯：快速定位到具体的代码块
重点运行时信息透出：重点突出关键日志，不关键的日志不打印，减少日志冗余
消息格式可扩展：通过扩展消息类的输出格式，减少日志的代码修改量

总结&猜测

Metrics
总结：根本实现分布式事务的可量化、可观测。猜测：更细粒度的指标、更广阔的生态兼容。
Tracing
总结：分布式事务全链路的可追溯。猜测：根据 xid 追溯事务链路，异常链路根因快速定位。
Logging
总结：结构化的日志格式。猜测：日志可观测体系演进。
作者：察溯
原文链接
本文为阿里云原创内容，未经允许不得转载。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)