关于分布式:一文看懂分布式链路监控系统

背景

传统的大型单体零碎随着业务体量的增大曾经很难满足市场对技术的需要，通过对将整块业务零碎拆分为多个互联依赖的子系统并针对子系统进行独立优化，可能无效晋升整个零碎的吞吐量。在进行零碎拆分之后，残缺的业务事务逻辑所对应的性能会部署在多个子系统上，此时用户的一次点击申请会触发若干子系统之间的互相性能调用，如何剖析一次用户申请所触发的屡次跨零碎的调用过程、如何定位存在响应问题的调用链路等等问题是链路追踪技术所要解决的问题。

举一个网络搜寻的示例，来阐明这样一个链路监控零碎须要解决的一些挑战。当用户在搜索引擎中输出一个关键词后，一个前端服务可能会将这次查问分发给数百个查问服务，每个查问服务在其本人的索引中进行搜寻。该查问还能够被发送到许多其余子系统，这些子系统能够解决敏感词汇、查看拼写、用户画像剖析或寻找特定畛域的后果，包含图像、视频、新闻等。所有这些服务的后果有选择地组合在一起，最终展现在搜寻后果页面中，咱们将这个模型称为一次残缺的搜寻过程。

在这样一次搜寻过程中，总共可能须要数千台机器和许多不同的服务来解决一个通用搜寻查问。此外，在网络搜寻场景中，用户的体验和提早严密相干，一次搜寻延时可能是因为任何子系统的性能不佳造成的。开发人员仅思考提早可能晓得整个零碎存在问题，但却无奈猜想哪个服务有问题，也无奈猜想其行为不良的起因。首先，开发人员可能无奈精确晓得正在应用哪些服务，随时都可能退出新服务和批改局部服务，以减少用户可见的性能，并改良性能和安全性等其余方面；其次，开发人员不可能是宏大零碎中每个外部微服务的专家，每一个微服务可能有不同团队构建和保护；另外，服务和机器能够由许多不同的客户端同时共享，因而性能问题可能是因为另一个利用的行为引起。

Dapper简介

在分布式链路追踪方面，Google早在2010年针对其外部的分布式链路跟踪零碎Dapper，发表了相干论文对分布式链路跟踪技术进行了介绍（强烈推荐浏览）。其中提出了两个根本要求。第一，领有宽泛的覆盖面。针对宏大的分布式系统，其中每个服务都须要被监控零碎笼罩，即便是整个零碎的一小部分没有被监控到，该链路追踪零碎也可能是不牢靠的。第二，提供继续的监控服务。对于链路监控零碎，须要7*24小时继续保障业务零碎的衰弱运行，保障任何时刻都能够及时发现零碎呈现的问题，并且通常状况下很多问题是难以复现的。依据这两个根本要求，分布式链路监控零碎的有如下几个设计指标：

利用级通明

链路监控组件应该以根底通用组件的形式提供给用户，以进步稳定性，利用开发者不须要关怀它们。对于Java语言来说，办法能够说是调用的最小单位，想要实现对调用链的监控埋点势必对办法进行加强。Java中对办法加强的形式有很多，比方间接硬编码、动静代理、字节码加强等等。利用级通明其实是一个比拟绝对的概念，透明度越高意味着难度越大，对于不同的场景能够采纳不同的形式。

低开销

低开销是链路监控零碎最重要的关注点，分布式系统对于资源和性能的要求自身就很刻薄，因而监控组件必须对原服务的影响足够小，将对业务主链路的影响降到最低。链路监控组件对于资源的耗费主除了体现在加强办法的耗费上，其次还有网络传输和数据存储的耗费，因为对于链路监控零碎来说，想要监控一次申请势必会产生出申请自身外的额定数据，并且在申请过程中，这些额定的数据不仅会临时保留在内存中，在分布式场景中还会随同着该申请从上游服务传输至上游服务，这就要求产生的额定数据尽可能地少，并且在随同申请进行网络传输的时候只保留大量必要的数据。

扩展性和开放性

无论是何种软件系统，可扩展性和开放性都是掂量其品质优劣的重要规范。对于链路监控零碎这样的根底服务零碎来说，上游业务零碎对于链路监控零碎来说是通明的，在一个规模较大的企业中，一个根底服务零碎往往会承载成千上万个上游业务零碎。每个业务零碎由不同的团队和开发人员负责，尽管应用的框架和中间件在同一个企业中有大抵的标准和要求，然而在各方面还是存在差别的。因而作为一个基础设施，链路监控零碎须要具备十分好的可扩展性，除了对企业中罕用中间件和框架的撑持外，还要可能不便开发人员针对非凡的业务场景进行定制化的开发。

数据模型

OpenTracing标准

Dapper将申请依照三个维度划分为Trace、Segment、Span三种模型，该模型曾经造成了OpenTracing标准。OpenTracing是为了形容分布式系统中事务的语义，而与特定上游跟踪或监控零碎的具体实现细节无关，因而形容这些事务不应受到任何特定后端数据展现或者解决的影响。大的概念就不多介绍了，重点看一下Trace、Segment、Span这三种模型到底是什么。

Trace

示意一整条调用链，包含跨过程、跨线程的所有Segment的汇合。

Segment

示意一个过程（JVM）或线程内的所有操作的汇合，即蕴含若干个Span。

Span

示意一个具体的操作。Span在不同的实现里可能有不同的划分形式，这里介绍一个比拟容易了解的定义形式：

Entry Span：入栈Span。Segment的入口，一个Segment有且仅有一个Entry Span，比方HTTP或者RPC的入口，或者MQ生产端的入口等。
Local Span：通常用于记录一个本地办法的调用。
Exit Span：出栈Span。Segment的进口，一个Segment能够有若干个Exit Span，比方HTTP或者RPC的进口，MQ生产端，或者DB、Cache的调用等。

依照下面的模型定义，一次用户申请的调用链路图如下所示：

惟一id

每个申请有惟一的id还是很必要的，那么在海量的申请下如何保障id的唯一性并且可能蕴含申请的信息？Eagleeye的traceId设计如下：

依据这个id，咱们能够晓得这个申请在2022-10-18 10:10:40收回，被11.15.148.83机器上过程号为14031的Nginx（对应标识位e）接管到。其中的四位原子递增数从0-9999，目标是为了避免单机并发造成traceId碰撞。

关系形容

将申请划分为Trace、Segment、Span三个档次的模型后，如何形容他们之间的关系？

从【OpenTracing标准】一节的调用链路图中能够看出，Trace、Segment能够作为整个调用链路中的逻辑构造，而Span才是真正串联起整个链路的单元，零碎能够通过若干个Span串联起整个调用链路。

在Java中，办法是以入栈、出栈的模式进行调用，那么零碎在记录Span的时候就能够通过模拟出栈、入栈的动作来记录Span的调用程序，不难发现最终一个链路中的所有Span出现树形关系，那么如何形容这棵Span树？Eagleeye中的设计很奇妙，EagleEye设计了RpcId来区别同一个调用链下多个网络调用的程序和嵌套档次。如下图所示：

RpcId用0.X1.X2.X3.....Xi来示意，根节点的RpcId固定从0开始，id的位数（"."的数量）示意了Span在这棵树中的层级，Id最初一位示意了Span在这一层级中的程序。那么给定同一个Trace中的所有RpcId，便能够很容易还原出一个实现的调用链：

- 0  - 0.1    - 0.1.1    - 0.1.2      - 0.1.2.1  - 0.2    - 0.2.1  - 0.3    - 0.3.1      - 0.3.1.1    - 0.3.2

跨过程传输

再进一步，在整个调用链的收集过程中，不可能将整个Trace信息随着申请携带到下个利用中，为了将跨过程传输的trace信息缩小到最小，每个利用（Segment）中的数据肯定是分段收集的，这样在Eagleeye的实现下跨Segment的过程只须要携带traceId和rpcid两个简短的信息即可。在服务端收集数据时，数据天然也是分段达到服务端的，但因为种种原因分段数据可能存在乱序和失落的状况：

如上图所示，收集到一个Trace的数据后，通过rpcid即可还原出一棵调用树，当呈现某个Segment数据缺失时，能够用第一个子节点代替。

数据埋点

如何进行办法加强（埋点）是分布式链路追零碎的关键因素，在Dapper提出的要求中能够看出，办法加强同时要满足利用级通明和低开销这两个要求。之前咱们提到利用级通明其实是一个比拟绝对的概念，透明度越高意味着难度越大，对于不同的场景能够采纳不同的形式。本文咱们介绍阿里的Eagleye和开源的SkyWalking来比拟两种埋点形式的优劣。

编码

阿里Eagleeye的埋点形式是间接编码的形式，通过中间件预留的扩大点实现。然而依照咱们通常的了解来说，编码对于Dapper提出的扩展性和开放性仿佛并不敌对，那为什Eagleye么要采纳这样的形式？集体认为有以下几点：

阿里有中间件的应用标准，不是想用什么就用什么，因而对于埋点的覆盖范围是无限的；
阿里有给力的中间件团队专门负责中间件的保护，中间件的埋点对于下层利用来说也是利用级通明的，对于埋点的笼罩是全面的；
阿里利用有接入Eagleye监控零碎的要求，因而对于可插拔的诉求并没有十分强烈。从下面几点来说，编码方式的埋点齐全能够满足Eagleye的须要，并且间接编码的形式在保护、性能耗费方面也是十分有劣势的。

字节码加强

相比于Eagleye，SkyWalking这样开源的分布式链路监控零碎，在开源环境下就没有这么好做了。开源环境下面临的问题其实和阿里团体外部的环境正好相同：

开源环境下每个开发者应用的中间件可能都不一样，想用什么就用什么，因而对于埋点的覆盖范围简直是有限的；
开源环境下，各种中间件都由不同组织或集体进行保护，甚至开发者还能够进行二次开发，不可能压服他们在代码中退出链路监控的埋点；
开源环境下，并不一定要接入链路监控体系，大多数集体开发者因为资源无限或其余起因没有接入链路监控零碎的需要。

从下面几点来说，编码方式的埋点必定是无奈满足SkyWalking的需要的。针对这样的状况，Skywalking采纳如下的开发模式：

Skywalking提供了外围的字节码加强能力和相干的扩大接口，对于零碎中应用到的中间件能够应用官网或社区提供的插件打包后植入利用进行埋点，如果没有的话甚至能够本人开发插件实现埋点。Skywalking采纳字节码加强的形式进行埋点，上面简略介绍字节码加强的相干常识和Skywalking的相干实现。

对Java利用实现字节码加强的形式有Attach和Javaagent两种，本文做一个简略的介绍。

Attach

Attach是一种绝对动静的形式，在阿尔萨斯（Arthas）这样的诊断系统中宽泛应用，利用JVM提供的Attach API能够实现一个JVM对另一个运行中的JVM的通信。用一个具体的场景举例：咱们要实现Attach JVM对一个运行中JVM的监控。如下图所示：

Attach JVM利用Attach API获取指标JVM的实例，底层会通过socketFile建设两个JVM间的通信；
Attach JVM指定指标JVM须要挂载的agent.jar包，挂载胜利后会执行agent包中的agentmain办法，此时就能够对指标JVM中类的字节码进行批改；
Attach JVM通过Socket向指标JVM发送命令，指标JVM收到后会进行响应，以达到监控的目标。

尽管Attach能够灵便地对正在运行中的JVM进行字节码批改，但在批改时也会受到一些限度，比方不能增减父类、不能减少接口、不能调整字段等。

Javaagent

Javaagent大家应该绝对相熟，他的启动形式是在启动命令中退出javaagent参数，指定须要挂载的agent：

java-javaagent:/path/agent.jar=key1=value1,key2=value2-jarmyJar.jar

Javaagent在IDE的Debug模式、链路监控零碎等场景中宽泛应用。它的外围是在指标JVM执行main办法前执行agent的premain办法，以插入前置逻辑：

指标JVM通过javaagent参数启动后找到指定的agent，执行agent的premain办法；
agent中通过JVM裸露的接口增加一个Transformer，顾名思义它能够Transform字节码；
指标JVM在类加载的时候会触发JVM内置的事件，回调Transformer以实现字节码的加强。

和Attach形式相比，Javaagent只能在main办法之前执行。然而在批改字节码时较为灵便，甚至能够批改JDK的外围类库。

字节码加强类库

Java提供了很多字节码加强类库，比方大家耳熟能详的cglib、Javassist，原生的Jdk Proxy还有底层的ASM等。在2014年，一款名为Byte Buddy的字节码加强类库横空出世，并在2015年取得Duke's Choice award。Byte Buddy兼顾高性能、易用、功能强大3个方面，上面是摘自其官网的一张常见字节码加强类库性能比拟图（单位: 纳秒）：

上图中的比照项咱们能够大抵分为两个方面：生成疾速代码（办法调用、父类办法调用）和疾速生成代码（简略类创立、接口实现、类型扩大），咱们理所应当要优先选择前者。从数据能够看出Byte Buddy在纳秒级的精度下，在办法调用和父类办法调用上和基线根本没有差距，而位于其后的是cglib。

Byte Buddy和cglib有较为杰出的性能得益于它们底层都是基于ASM构建，如果将ASM也退出比照那么它的性能肯定是最高的。然而用过ASM的同学尽管不肯定能感触到它的高性能，但肯定能感触到它噩梦般的开发体验：

mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;");mv.visitLdcInsn("begin of sayhello().");mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V", false);

Skywalking案例剖析

介绍了这么多，上面联合Skywalking中应用Byte Buddy的案例和大家一起体验下字节码加强的开发过程，其中只简略介绍相干主流程代码，各种细节就不介绍了。Skywalking为开发者提供了简略易用的插件接口，对于开发者来说不须要晓得怎么加强办法的字节码，只须要关怀以下几点：

要加强哪个类的哪个办法？

Skywalking提供了ClassMatch，反对各种类、办法的匹配形式。包含类名、前缀、正则、注解等形式的匹配，除此之外还提供了与、或、非逻辑链接，以反对用户通过各种形式精确定位到一个具体的办法。咱们看一个插件中的代码：

这段逻辑示意须要加强不带annotation1注解，并且带有annotaion2注解或annotaion3注解的办法的字节码。ClassMatch通过Builder模式提供用户流式编程的形式，最终Skywalking会将用户提供的一串ClassMatch构建出一个外部应用的类匹配逻辑。

须要增加/批改什么逻辑？

以实例办法为例，Skywalking提供了如下实例办法拦截器：

public interface InstanceMethodsAroundInterceptor {    // 办法执行前置扩大点    void beforeMethod(EnhancedInstance objInst, Method method, Object[] allArguments, Class<?>[] argumentsTypes,                      MethodInterceptResult result) throws Throwable;    // 办法执行后置扩大点    Object afterMethod(EnhancedInstance objInst, Method method, Object[] allArguments, Class<?>[] argumentsTypes,                       Object ret) throws Throwable;    // 办法抛出异样时扩大点    void handleMethodException(EnhancedInstance objInst, Method method, Object[] allArguments,                               Class<?>[] argumentsTypes, Throwable t);}

开发者通过实现该接口即可对一个实例办法进行逻辑扩大（字节码加强）。办法参数列表中的第一个类型为EnhancedInstance的参数其实就是以后对象（this），Skywalking中所有实例办法或构造方法被加强的类都会实现EnhancedInstance接口。

假如咱们有一个Controller，外面只有一个sayHello办法返回"Hello"，通过Skywalking加强后，反编译一下它被加强后的字节码文件：

能够看到：

Skywalking在其中插入了一个名为_$EnhancedClassField_ws的字段，开发者在某些场合能够正当利用该字段存储一些信息。比方存储Spring MVC中Controller的跟门路，或者Jedis、HttpClient链接中对端信息等。
原来的syHello办法名被批改了但仍保留下来，并且新生成了一个加强后的sayHello办法，动态代码块里将通过字节码加强后的sayHello办法存入缓存字段。

加强的前置条件是什么？

在某些时候，并不是只有引入了对应插件就肯定会对相干的代码进行字节码加强。比方咱们想对Spring MVC的Controller进行埋点，咱们应用的是Spring 4.x版本，然而插件却是 5.x 版本的，如果间接对源码进行加强可能会因为版本的差异带来意料之外的问题。Skywalking提供了一种witness机制，简略来说就是当咱们的代码中存在指定的类或形式时，以后插件才会进行字节码加强。比方Spring 4.x版本中须要witness这两个类：

如果粒度不够，还能够对办法进行witness。比方Elastic Search 6.x版本中witness了这个办法：

意思就是SearchHits类中必须有名为getTotalHits、参数列表为空并且返回long的办法。

除了下面的扩大点外，Skywalking还反对对jdk外围类库的字节码加强，比方对Callable和Runnable进行加强已反对异步模式下的埋点透传。这就须要和BootstrapClassLoader打交道了，Skywalking帮咱们实现了这些简单的逻辑。Skywalking Agent局部整体的模型如下图所示：

左侧SPI局部是Skywalking裸露的插件标准接口，开发者依据这些接口实现插件。右侧Core局部负责加载插件并且利用Byte Buddy提供的字节码加强逻辑对利用中指定类和办法的字节码进行加强。

源码剖析

介绍了Skywalking的插件模型后，上面从Javaagent的入口premain开始介绍下次要的流程：

public static void premain(String agentArgs, Instrumentation instrumentation) throws PluginException {    // 1. 加载所有的Skywalking插件     // 插件实现了Skywalking接口标准，包含须要加强哪个类、须要怎么加强这两个因素    final PluginFinder  = new PluginFinder(new PluginBootstrap().loadPlugins());    // 2. 构建ByteBuddy    // ByteBuddy提供了流式的API来指定ByteBuddy类库的行为（用于各种配置）    final ByteBuddy byteBuddy = new ByteBuddy().with(TypeValidation.of(Config.Agent.IS_OPEN_DEBUGGING_CLASS));    // 3. 构建AgentBuilder实例，须要疏忽的类    AgentBuilder agentBuilder = new AgentBuilder.Default(byteBuddy).ignore(        nameStartsWith("net.bytebuddy.")        .or(nameStartsWith("org.slf4j."))        .or(nameStartsWith("org.groovy."))        .or(nameContains("javassist"))        .or(nameContains(".asm."))        .or(nameContains(".reflectasm."))        .or(nameStartsWith("sun.reflect"))        .or(nameStartsWith("org.apache.skywalking.")            .and(not(nameStartsWith("org.apache.skywalking.apm.toolkit."))))        // 疏忽Java中的【Synthetic】        // Synthetic指所有存在于字节码文件中，然而不存在于源代码中的【结构】，即JVM帮咱们生产的货色        // 比方外部类指向外部类实例的this$0字段；外部类拜访外部类的公有变量时JDK帮咱们生产的办法等等        // JDK11后引入了NBAC机制，引入了新的嵌套类组织形式，不再生成Synthetic办法        .or(ElementMatchers.isSynthetic()));    // 4. 解决JDK9的module个性，解决跨模块类拜访的问题    // 5. 将AgentBuilder插桩在Instrumentation上    agentBuilder        // 依据插件的内容构建须要加强类的匹配器        .type(pluginFinder.buildMatch())        // Transformer就是字节码加强逻辑的次要入口        .transform(new Transformer(pluginFinder))        // Retransform模式：保留被批改的字节码        // Redifine模式：笼罩被批改的字节码        .with(AgentBuilder.RedefinitionStrategy.RETRANSFORMATION)        // 一些监听器        .with(new RedefinitionListener())        .with(new Listener())        // 将AgentBuilder插桩在JVM提供的Instrumentation上        .installOn(instrumentation);}

下面的流程次要做了两件事：

从指定的目录加载所有插件到内存中；
构建Byte Buddy外围的AgentBuilder插桩到JVM的Instrumentation API上，包含须要加强哪些类以及外围的加强逻辑Transformer。

private static class Transformer implements AgentBuilder.Transformer {    private PluginFinder pluginFinder;    Transformer(PluginFinder pluginFinder) {        this.pluginFinder = pluginFinder;    }    /**     * 这个办法在类加载的过程中会由JVM调用（Byte Buddy做了封装）     * @param builder          原始类的字节码构建器     * @param typeDescription  类形容信息     * @param classLoader      这个类的类加载器     * @param module           jdk9中模块信息     * @return                 批改后的类的字节码构建器     */    @Override    public DynamicType.Builder<?> transform(final DynamicType.Builder<?> builder,                                            final TypeDescription typeDescription,                                            final ClassLoader classLoader,                                            final JavaModule module) {        LoadedLibraryCollector.registerURLClassLoader(classLoader);        // 依据类信息找到针对这个类进行字节码加强的插件，可能有多个        List<AbstractClassEnhancePluginDefine> pluginDefines = pluginFinder.find(typeDescription);        if (pluginDefines.size() > 0) {            DynamicType.Builder<?> newBuilder = builder;            EnhanceContext context = new EnhanceContext();            for (AbstractClassEnhancePluginDefine define : pluginDefines) {                // 调用插件的define办法失去新的字节码                DynamicType.Builder<?> possibleNewBuilder = define.define(                    typeDescription, newBuilder, classLoader, context);                if (possibleNewBuilder != null) {                    newBuilder = possibleNewBuilder;                }            }            // 返回加强后的字节码给JVM，实现字节码加强            return newBuilder;        }        return builder;    }}

JVM在类加载的时候会触发JVM内置事件，回调Transformer传入原始类的字节码、类加载器等信息，从而实现对字节码的加强。其中的AbstractClassEnhancePluginDefine就是一个插件的形象。

public abstract class AbstractClassEnhancePluginDefine {    public DynamicType.Builder<?> define(TypeDescription typeDescription, DynamicType.Builder<?> builder,                                         ClassLoader classLoader, EnhanceContext context) throws PluginException {        // witness机制        WitnessFinder finder = WitnessFinder.INSTANCE;        //通过类加载器找witness类，没有就间接返回，不进行字节码的革新        String[] witnessClasses = witnessClasses();        if (witnessClasses != null) {            for (String witnessClass : witnessClasses) {                if (!finder.exist(witnessClass, classLoader)) {                    return null;                }            }        }        //通过类加载器找witness办法，没有就间接返回，不进行字节码的革新        List<WitnessMethod> witnessMethods = witnessMethods();        if (!CollectionUtil.isEmpty(witnessMethods)) {            for (WitnessMethod witnessMethod : witnessMethods) {                if (!finder.exist(witnessMethod, classLoader)) {                    return null;                }            }        }        // enhance开始批改字节码        DynamicType.Builder<?> newClassBuilder = this.enhance(typeDescription, builder, classLoader, context);        // 批改实现，返回新的字节码        context.initializationStageCompleted();        return newClassBuilder;    }    protected DynamicType.Builder<?> enhance(TypeDescription typeDescription, DynamicType.Builder<?> newClassBuilder,                                             ClassLoader classLoader, EnhanceContext context) throws PluginException {        // 加强静态方法        newClassBuilder = this.enhanceClass(typeDescription, newClassBuilder, classLoader);        // 加强实例办法& 构造方法        newClassBuilder = this.enhanceInstance(typeDescription, newClassBuilder, classLoader, context);        return newClassBuilder;    }}

通过witness机制检测满足条件后，对静态方法、实例办法和构造方法进行字节码加强。咱们以实例办法和构造方法为例：

public abstract class ClassEnhancePluginDefine extends AbstractClassEnhancePluginDefine {    protected DynamicType.Builder<?> enhanceInstance(TypeDescription typeDescription,                                                     DynamicType.Builder<?> newClassBuilder, ClassLoader classLoader,                                                     EnhanceContext context) throws PluginException {        // 获取插件定义的构造方法拦挡点ConstructorInterceptPoint        ConstructorInterceptPoint[] constructorInterceptPoints = getConstructorsInterceptPoints();        // 获取插件定义的实例办法拦挡点InstanceMethodsInterceptPoint        InstanceMethodsInterceptPoint[] instanceMethodsInterceptPoints = getInstanceMethodsInterceptPoints();        String enhanceOriginClassName = typeDescription.getTypeName();        // 非空校验        boolean existedConstructorInterceptPoint = false;        if (constructorInterceptPoints != null && constructorInterceptPoints.length > 0) {            existedConstructorInterceptPoint = true;        }        boolean existedMethodsInterceptPoints = false;        if (instanceMethodsInterceptPoints != null && instanceMethodsInterceptPoints.length > 0) {            existedMethodsInterceptPoints = true;        }        if (!existedConstructorInterceptPoint && !existedMethodsInterceptPoints) {            return newClassBuilder;        }        // 这里就是之前提到的让类实现EnhancedInstance接口，并增加_$EnhancedClassField_ws字段        if (!typeDescription.isAssignableTo(EnhancedInstance.class)) {            if (!context.isObjectExtended()) {                // Object类型、private volatie修饰符、提供办法进行拜访                newClassBuilder = newClassBuilder.defineField(                    "_$EnhancedClassField_ws", Object.class, ACC_PRIVATE | ACC_VOLATILE)                    .implement(EnhancedInstance.class)                    .intercept(FieldAccessor.ofField("_$EnhancedClassField_ws"));                context.extendObjectCompleted();            }        }        // 构造方法加强        if (existedConstructorInterceptPoint) {            for (ConstructorInterceptPoint constructorInterceptPoint : constructorInterceptPoints) {                // jdk外围类                if (isBootstrapInstrumentation()) {                    newClassBuilder = newClassBuilder.constructor(constructorInterceptPoint.getConstructorMatcher())                        .intercept(SuperMethodCall.INSTANCE.andThen(MethodDelegation.withDefaultConfiguration()                                                                    .to(BootstrapInstrumentBoost                                                                    .forInternalDelegateClass(constructorInterceptPoint                                                                                              // 非jdk外围类                                                                                                         .getConstructorInterceptor()))));                } else {                    // 找到对应的构造方法，并通过插件自定义的InstanceConstructorInterceptor进行加强                    newClassBuilder = newClassBuilder.constructor(constructorInterceptPoint.getConstructorMatcher())                        .intercept(SuperMethodCall.INSTANCE.andThen(MethodDelegation.withDefaultConfiguration()                                                                    .to(new ConstructorInter(constructorInterceptPoint                                                                                             .getConstructorInterceptor(), classLoader))));                }            }        }        // 实例办法加强        if (existedMethodsInterceptPoints) {            for (InstanceMethodsInterceptPoint instanceMethodsInterceptPoint : instanceMethodsInterceptPoints) {                // 找到插件自定义的实例办法拦截器InstanceMethodsAroundInterceptor                String interceptor = instanceMethodsInterceptPoint.getMethodsInterceptor();                // 这里在插件自定义的匹配条件上加了一个【不为静态方法】的条件                ElementMatcher.Junction<MethodDescription> junction = not(isStatic()).and(instanceMethodsInterceptPoint.getMethodsMatcher());                // 须要重写入参                if (instanceMethodsInterceptPoint.isOverrideArgs()) {                    // jdk外围类                    if (isBootstrapInstrumentation()) {                        newClassBuilder = newClassBuilder.method(junction)                            .intercept(MethodDelegation.withDefaultConfiguration()                                       .withBinders(Morph.Binder.install(OverrideCallable.class))                                       .to(BootstrapInstrumentBoost.forInternalDelegateClass(interceptor)));                    // 非jdk外围类                     } else {                            newClassBuilder = newClassBuilder.method(junction)                                .intercept(MethodDelegation.withDefaultConfiguration()                                           .withBinders(Morph.Binder.install(OverrideCallable.class))                                           .to(new InstMethodsInterWithOverrideArgs(interceptor, classLoader)));                    }                // 不须要重写入参                } else {                    // jdk外围类                        if (isBootstrapInstrumentation()) {                            newClassBuilder = newClassBuilder.method(junction)                                .intercept(MethodDelegation.withDefaultConfiguration()                                           .to(BootstrapInstrumentBoost.forInternalDelegateClass(interceptor)));                    // 非jdk外围类                                                                                      } else {                        // 找到对应的实例办法，并通过插件自定义的InstanceMethodsAroundInterceptor进行加强                        newClassBuilder = newClassBuilder.method(junction)                                .intercept(MethodDelegation.withDefaultConfiguration()                                           .to(new InstMethodsInter(interceptor, classLoader)));                    }                }            }        }        return newClassBuilder;    }}

依据是否要重写入参、是否是外围类走到不同的逻辑分支，大抵的加强逻辑大差不差，就是依据用户自定义的插件找到须要加强的办法和加强逻辑，利用Byte Buddy类库进行加强。

用户通过办法拦截器实现加强逻辑，然而它是面向用户的，并不能间接用来进行字节码加强，Skywalking加了一个中间层来连贯用户逻辑和Byte Buddy类库。上述代码中的XXXInter便是中间层，比方针对实例办法的InstMethodsInter：

InstMethodsInter封装用户自定义的逻辑，并且对接ByteBuddy的外围类库，当执行到被字节码加强的办法时会执行InstMethodsInter的intercept办法（能够和下面反编译被加强后类的字节码文件进行比照）：

public class InstMethodsInter {    private static final ILog LOGGER = LogManager.getLogger(InstMethodsInter.class);    // 用户在插件中定义的实例办法拦截器    private InstanceMethodsAroundInterceptor interceptor;    public InstMethodsInter(String instanceMethodsAroundInterceptorClassName, ClassLoader classLoader) {        try {            // 加载用户在插件中定义的实例办法拦截器            interceptor = InterceptorInstanceLoader.load(instanceMethodsAroundInterceptorClassName, classLoader);        } catch (Throwable t) {            throw new PluginException("Can't create InstanceMethodsAroundInterceptor.", t);        }    }    /**     * 当执行被加强办法时，会执行该intercept办法     *     * @param obj          实例对象（this）     * @param allArguments 办法入参     * @param method       参数形容     * @param zuper        原办法调用的句柄    *  @param method       被加强后的办法的援用      * @return             办法返回值     */    @RuntimeType    public Object intercept(@This Object obj, @AllArguments Object[] allArguments, @SuperCall Callable<?> zuper,        @Origin Method method) throws Throwable {        EnhancedInstance targetObject = (EnhancedInstance) obj;        MethodInterceptResult result = new MethodInterceptResult();        try {            // 拦截器前置逻辑            interceptor.beforeMethod(targetObject, method, allArguments, method.getParameterTypes(), result);        } catch (Throwable t) {            LOGGER.error(t, "class[{}] before method[{}] intercept failure", obj.getClass(), method.getName());        }        Object ret = null;        try {            // 是否中断办法执行            if (!result.isContinue()) {                ret = result._ret();            } else {                // 执行原办法                ret = zuper.call();                // 为什么不能走method.invoke？因为method曾经是被加强后办法，调用就死循环了！                // 能够回到之前的字节码文件查看起因，看一下该intercept执行的机会            }        } catch (Throwable t) {            try {                 // 拦截器异样时逻辑                interceptor.handleMethodException(targetObject, method, allArguments, method.getParameterTypes(), t);            } catch (Throwable t2) {                LOGGER.error(t2, "class[{}] handle method[{}] exception failure", obj.getClass(), method.getName());            }            throw t;        } finally {            try {                // 拦截器后置逻辑                ret = interceptor.afterMethod(targetObject, method, allArguments, method.getParameterTypes(), ret);            } catch (Throwable t) {                LOGGER.error(t, "class[{}] after method[{}] intercept failure", obj.getClass(), method.getName());            }        }        return ret;    }}

上述逻辑其实就是下图中红框中的逻辑：

Byte Buddy提供了申明式形式，通过几个注解就能够实现字节码加强逻辑。

数据收集

下一步就是将收集到的Trace数据发送到服务端。为了将对主链路的影响降到最小，个别都采纳先存本地、再异步采集的形式。Skywalking和Eagleeye的实现有所不同，咱们别离介绍：

存储

Eagleeye

鹰眼采纳并发环形队列存储Trace数据，如下图所示：

环形队列在很多日志框架的异步写入过程中很常见，其中次要包含读指针take，指向队列中的最初一条数据；写指针put，指向队列中下一个数据将寄存的地位，并且反对原子读、写数据。take和put指针朝一个时钟方向挪动，当生产数据的速度超过生产速度时，会呈现put指针“追上”take指针的状况（套圈），此时依据不同的策略能够抛弃行将写入的数据或将老数据笼罩。

Skywalking

Skywalking在实现上有所区别，采纳分区的QueueBuffer存储Trace数据，多个生产线程通过Driver平均分配到各个QueueBuffer上进行数据生产：

QueueBuffer有两种实现，除了基于JDK的阻塞队列外，还有一种一般数组+原子下标的形式。Skywalking对于这两种实现有不同的应用场景：基于JDK阻塞队列的实现用在服务端，而一般数组+原子下标的形式用在Agent端，因为后者更加轻量，性能更高。对于后者这里介绍一下其中比拟乏味的中央。

乏味的原子下标

一般的Oject数组是无奈反对并发的，但只有保障每个线程获取下标的过程是原子的，即可保障数组的线程平安。这须要保障：

多线程获取的下标是顺次递增的，从0开始到数组容量-1；
当某个线程获取的下标超过数组容量，须要从0开始从新获取。

这其实并不难实现，通过一个原子数和取模操作一行代码就能实现下面的两个性能。但咱们看Skywalking是如何实现这个性能的：

// 提供原子下标的类public class AtomicRangeInteger {    // JDK提供的原子数组    private AtomicIntegerArray values;    // 固定值15    private static final int VALUE_OFFSET = 15;    // 数组开始下标，固定为0    private int startValue;    // 数组最初一个元素的下标，固定为数组的最大长度-1    private int endValue;    public AtomicRangeInteger(int startValue, int maxValue) {        // 创立一个长度为31的原子数组        this.values = new AtomicIntegerArray(31);        // 将第15位设置为初始值0        this.values.set(VALUE_OFFSET, startValue);        this.startValue = startValue;        this.endValue = maxValue - 1;    }    // 外围办法，获取数组的下一个下标    public final int getAndIncrement() {        int next;        do {            // 原子递增            next = this.values.incrementAndGet(VALUE_OFFSET);            // 如果超过了数组范畴，CAS重制到0            if (next > endValue && this.values.compareAndSet(VALUE_OFFSET, next, startValue)) {                return endValue;            }        } while (next > endValue);        return next - 1;    }}

Skywalking用了一个长度固定为31的JDK原子数组的固定第15位进行相干原子操作，JDK8中的原子数组利用Unsafe通过偏移量间接对数组中的元素进行内存操作，那为什么要这么做呢？咱们先将其称为V1版本，再来看看V2版本，这是Skywalking晚期版本应用的代码：

public class AtomicRangeInteger {    private AtomicInteger value;    private int startValue;    private int endValue;    public AtomicRangeInteger(int startValue, int maxValue) {        this.value = new AtomicInteger(startValue);        this.startValue = startValue;        this.endValue = maxValue - 1;    }    public final int getAndIncrement() {        int current;        int next;        do {            // 获取以后下标            current = this.value.get();            // 如果超过最大范畴则从0开始            next = current >= this.endValue ? this.startValue : current + 1;            // CAS更新下标，失败则循环重试        } while (!this.value.compareAndSet(current, next));        return current;    }}

肉眼可见这段V2版本的代码逻辑不如V1版本，因为在V2中获取以后值和CAS更新这两个步骤是离开的，并不具备原子性，因而并发抵触的可能性更高，从而导致循环次数减少；而应用JDK提供的incrementAndGet办法效率更高。再看下V3版本：

public class AtomicRangeInteger extends Number implements Serializable {    // 用原子整型代替V1版本的原子数组    private AtomicInteger value;    private int startValue;    private int endValue;    public AtomicRangeInteger(int startValue, int maxValue) {        this.value = new AtomicInteger(startValue);        this.startValue = startValue;        this.endValue = maxValue - 1;    }    public final int getAndIncrement() {        int next;        do {            next = this.value.incrementAndGet();            if (next > endValue && this.value.compareAndSet(next, startValue)) {                return endValue;            }        }        while (next > endValue);        return next - 1;    }}

这个版本惟一的区别就是应用AtomicInteger代替原来的AtomicIntegerArray的第15位。还有最初一个最简略的V4版本，通过一个原子数和取模操作实现：

public class AtomicRangeInteger {    private AtomicLong value;    private int mask;    public AtomicRangeInteger(int startValue, int maxValue) {        this.value = new AtomicLong(startValue);        this.mask = maxValue - 1;    }    public final int getAndIncrement() {        return (int)(value.incrementAndGet() % mask);    }}

通过Benchmark压测数据来看看这几个版本的性能有什么差异，固定128线程，3轮预热、5轮正式，每轮10s。

Skywalking官网数据（数组大小100）：

本人在mac上测试的数据（数组大小100）：

本人在mac上测试的数据（数组大小128）：

Skywalking官网显示通过原子数组的固定第15位操作的V1版本体现最好，而在我本人本机环境测试中V3版本通过原子整数代替的形式和V1版本有高有低，而原子数取模的性能是最高的。集体猜想Skywalking通过原子数组的固定第15位操作是为了进行缓存填充，测试后果和环境有比拟大的关系；而不应用原子数取模的起因是原子数的大小会有限递增。

传输

最初一步就是数据的传输，如下图所示：

Skywalking提供了GRPC和Kafka两种数据传输方式，而鹰眼则先将数据存入本地日志中，再通过agent将数据采集到服务端。和Skywalking相比，用户能够间接在机器上查看trace日志，而Skywalking提供了日志插件以提供可插拔的本地trace存储性能。

从整体上来看，Skywalking采取了埋点和中间件代码拆散的形式，在某种意义上实现了利用级通明，然而在前期保护的过程中中间件版本的降级须要配合插件版本的降级，在保护方面带来了一些问题。而Eagleeye编码方式的埋点由中间件团队保护，对于下层的利用也是通明的，更加适宜阿里团体外部的环境。

原文链接

本文为阿里云原创内容，未经容许不得转载。