陈晨：
Github ID：
chenmudu
，SOFATracer Committer ， 专注于基础服务和可观察性方向。
SOFATracer 是蚂蚁集团开源的基于 OpenTracing 规范的分布式链路跟踪系统组件，其核心理念就是通过一个全局的 TraceId 将分布在各个服务节点上的同一次请求串联起来。通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来同时也提供远程汇报到 Zipkin /Jaeger 进行展示的能力，以此达到透视化网络调用的目的。
我们选择了将 SOFATracer 作为公司云原生架构下分布式应用透传的核心组件，并依此构建了我们公司内部的众多的产品。其中最重要的是：借助其全局透传能力，将上下游及其相关中间件 Client 端串联起来，为我们内部应用可观察性相关指标做了重要的补充。以此丰富了公司应用维度的相关指标，为我们应用级问题定位、应用链路诊断以及中间件运行期分析提供了重要的能力。所以今天想和大家分享一下分布式链路组件 SOFATracer 在亿通内部落地的相关情况。
SOFATracer：
https://github.com/sofastack/sofa-tracer
在公司内，我们将 Spring Cloud 全家桶和 Apache Dubbo 作为微服务解决方案和服务通讯框架。由于微服务下分布式应用之间的调用关系开始变得复杂起来，不仅在开发过程中，在后续的测试和发布过程都会存在问题排查过难；同时我们需要开始构建一些其他平台，用于满足我们日益增长的业务需求和其他需求。
由于公司内技术栈的更新迭代和业务增长等背景，我们急需一套应用级系统透传的组件作为基础服务，并在此基础上，为公司内部其他相关平台赋能。经过大量对比以及考虑到团队内技术栈分布和所需中间件产品的需求，我们选择了 SOFATracer 作为首选的透传组件，以下则是我们选择的重要原因。
选择 JavaAgent 这种非侵入式的透传组件诚然是一件省力和简单的事儿，业内也有许多优秀的产品。但是我们的目标是寻找核心的 SDK 作为一部分微服务应用的基础组件，并不直接使用，借助 SOFATracer 完成公司内平台所需的相关需求，构建一整套的分布式应用链路跟踪解决方案；同时我们还考虑团队内技术栈分布情况。由于在调研期间已大致学习和观摩过 SOFATracer 相关源码，确定其代码清晰、实现轻巧及利于后期扩展等特点，使得我们最终选择了 SOFATracer 作为应用透传的基础组件。
由于我们最初的目标是一整套分布式全链路应用相关的解决方案，我们需要其具备易于扩展和可插拔的能力。
相信熟悉 SOFATracer 的同学已经了解其设计和相关架构，在 plugins 目录下存放众多中间件 Client 端的增强，如果有需要定制化则可自行扩展，同时基于 SOFABoot Starters 下的初始化也使得其增强 具备可插拔性。如果不太熟悉的同学，可以寻找往期介绍 SOFATracer 的相关文章。
SOFAStack 作为业内金融级云原生架构的标杆，其开源的组件是金融场景里锤炼出来的优秀实践。由于公司内部 云原生架构下的中间件需要具备动态性、安全性和合规性等特点，所以我们内部定制的中间件 Client 端在 SOFATracer 清晰和具备扩展性的代码下完成了超过 10 余种 Client 端动态能力的增强。感谢蚂蚁集团开源出如此优秀的金融级云原生组件。
问题定位及应用性能优化，并补全云原生下可观察性遗失的相关指标
借助于 SOFATracer 的全链路透传和借助高性能内存队列 Disruptor 关联数据落盘等功能，我们在内部的可观察性平台上帮助业务应用快速定位问题，分析问题和对部分应用做相关优化，补全了公司云原生架构下关于应用可观察性的相关指标的短板。包括不仅限于业务应用级 Logs , 应用级 Traces , 及其相关中间件 Client 端的 Metrics 指标，同其他监控平台一同构建了云原生下企业级的的可观察性平台。
例如：我们利用 SOFATracer 全局透传的 TraceId 将此次请求涉及到的所有的应用日志数据串联起来，以此确定整个链路发生的所有情况。问题发生时，确定动态系统数据产生的瞬时状态，为问题定位、还原业务场景提供重要能力。
这样我们可以通过全局的 TraceId 筛选出某一次请求调用过程中，途径的所有应用日志数据，将复杂冗余的调用情况及其数据转换为可观察的线性数据，以此更方便的去排查问题。
而且我们借助 Logs 与 Traces 共有的 TraceId 和 SpanId，将业务日志数据与链路追踪进行渲染和关联，将问题定位的范围由应用级到核心代码层级，将可观察性下的关键指标 Logs 与 Traces 进行关联，不断缩小问题的定位范围。
同时我们将定时上报的统计指标信息用于反馈应用内中间件 Client 端所使用的性能，并不断优化相关 Client 和 Server 端的相关性能参数。
例如下图，我们内部定义了接口响应时间的步长为 50 ms，用不同颜色去区分不同接口在不同时间内的响应速度，借此可以清晰的确定某些 Rest 接口的响应时间，以便有利于调整相关 Rest Client 端连接参数和优化对应 Http Server 的性能。
最后，我们将上报的 Metrics 同其他相关指标信息，一起用在我们平台内应用入口做对应的 入口流量检测、系统健康反馈、出口流量以及基础依赖的分析。确保当问题发生的时候，我们可以从整体到局部，从宏观到微观的去探测软件内部黑盒的状态。以便更好的定位问题、分析问题、解决问题，为基础服务和业务提供技术保障。
至此，很大程度上为公司内 应用拓扑发现、跨应用追踪、全链路的日志关联以及相关应用指标及趋势分析等提供了技术支持。当然这是我们内部平台在可观察性下展现的部分能力，关于更多则涉及到公司隐私，就不在此进行讨论。
我们后期可能会打算借助 SOFATracer 作为应用透传系统的核心，打造出其他各式各样满足业务发展的平台产品。再一次感谢 SOFA 社区开源出如此优秀的追踪组件。
良好的社区生态除了官方的不断迭代演进和运营之外，更需要更多的人进行参与。当有越来越多的场景落地，产品才会越来越成熟，才会更好的回馈广大开发者，对此我们也积极的参与了 SOFAStack 的建设和发展：
我们内部将其作为应用间透传的基本组件，用于服务其他平台，并反哺至业务。
同时将部分特殊用法案例以及相关插件的使用指南补充在了 SOFA 的 Guides 项目内，为其他开发者提供便利。包括不仅限于 SpringData Mongo Client 、SpringData Redis Client、Spring Kafka、Spring Amqp (Rabbit)及监听采样的数据控制等。
使用过程中，由于我们部分服务的特殊性，致使官方代码出现兼容性问题，我们反哺给上游分支，并修复部分开源代码。包括不仅限于 RDB 增强端对于 Oracle 数据库的 TNS 模式的匹配、 Http Server 端错误标志的统一和信息填充以及一些小问题的Bug修复。
同时由于我们开发了多个内部中间件的插件，我们将具备通用性的相关代码贡献至官方，作为回报给开源社区，以此表达开源社区为我们带来便利的感谢。贡献的插件包括不仅限于 Spring Kafka、Spring Amqp(Rabbit) 等。关于相关插件代码，详情请关注 SOFATracer 3.X 分支。
最后，非常感谢蚂蚁集团开源出的各个组件，让我们的基础服务插上翅膀，补全了公司在可观察性下的遗漏的应用级指标，为我们的业务应用提供保驾护航的能力。后续，我们将持续关注 SOFA 生态，为社区尽可能的贡献自己微薄的力量。
