乐趣区

关于阿里云:Seata-的可观测实践

jiezi

作者：察溯

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 维度

设计思路

  1. Seata 作为一个被集成的数据一致性框架，Metrics 模块将尽可能少的应用第三方依赖以升高发生冲突的危险
  2. Metrics 模块将极力争取更高的度量性能和更低的资源开销，尽可能升高开启后带来的副作用
  3. 配置时，Metrics 是否激活、数据如何公布，取决于对应的配置；开启配置则主动启用，并默认将度量数据通过 prometheusexporter 的模式公布
  4. 不应用 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 模块的工作流，其工作流程如下：

  1. 利用 SPI 机制，依据配置加载 Exporter 和 Registry 的实现类
  2. 基于音讯订阅与告诉机制，监听所有全局事务的状态变更事件，并 publish 到 EventBus
  3. 事件订阅者生产事件，并将生成的 metrics 写入 Registry
  4. 监控零碎（如 prometheus）从 Exporter 中拉取数据

TC 外围指标

TM 外围指标

RM 外围指标

大盘展现

Tracing 维度

Seata 为什么须要 tracing？

  1. 对业务侧而言，引入 Seata 后，对业务性能会带来多大损耗？次要工夫耗费在什么中央？如何针对性的优化业务逻辑？这些都是未知的。
  2. Seata 的所有音讯记录都通过日志长久化落盘，但对不理解 Seata 的用户而言，日志十分不敌对。是否通过接入 Tracing，晋升事务链路排查效率？
  3. 对于老手用户，可通过 Tracing 记录，疾速理解 Seata 的工作原理，升高 Seata 应用门槛。

Seata 的 tracing 解决方案

  • Seata 在自定义的 RPC 音讯协定中定义了 Header 信息
  • SkyWalking 拦挡指定的 RPC 音讯，并注入 tracing 相干的 span 信息
  • 以 RPC 音讯的收回 & 接管为临界点，定义了 span 的生命周期范畴

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

tracing 成果

  • 基于的 demo 场景：
  1. 用户申请交易服务
  2. 交易服务锁定库存
  3. 交易服务创立账单
  4. 账单服务进行扣款
  • GlobalCommit 胜利的事务链路（事例）

Logging 维度

设计思路

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

日志格局设计

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

  • 线程池标准命名：当线程池、线程比拟多时，标准的线程命名能将无序执行的线程执行秩序清晰展现
  • 办法全类名可追溯：疾速定位到具体的代码块
  • 重点运行时信息透出：重点突出要害日志，不要害的日志不打印，缩小日志冗余
  • 音讯格局可扩大：通过扩大音讯类的输入格局，缩小日志的代码批改量

总结 & 瞻望

Metrics

总结：根本实现分布式事务的可量化、可观测。瞻望：更细粒度的指标、更广大的生态兼容。

Tracing

总结：分布式事务全链路的可追溯。瞻望：依据 xid 追溯事务链路，异样链路根因疾速定位。

Logging

总结：结构化的日志格局。瞻望：日志可观测体系演进。Seata-go 是 Seata 的多语言布局的重要一环，目前处在高速倒退期间，欢送大家一起退出建设。如果你对 Seata 有任何问题，欢送通过钉钉搜寻群号退出咱们。（钉钉群号：33069364）

相干链接：

[1] 为 [Seata 利用 | Seata-server] 接入 Skywalking

https://seata.io/zh-cn/docs/user/apm/skywalking.html

退出移动版