Skywalking enhancement and interception mechanism

Byte enhanced matching condition

In many implementations skywalking implemented in a byte-buddy query based on the matching chain, code as follows:

public abstract class AbstractJunction<V> implements ElementMatcher.Junction<V>

FIG class class corresponding relationship is as follows:

In addition, in order to facilitate better matching is performed in the period of interception, skywalking also defined matcher Match a custom implementation of class Class schematic showing the relationship is as follows:

Wherein NameMatch inherit the name of NameMatch Match category if relatively more independent, but otherwise Match inheritance structure is relatively little complicated, are inherited IndirectMatch, before complete class diagram corresponding to FIG concise upper class of the class and the following :

Enhanced plug-ins extension points

All skywalking-based package of enhanced logical framework, such as the search for new middleware to enhance or components must be observed that the development of plug-in extensions specification, the specific specifications are as follows:

First, the definition file must exist at skywalking-plugin.def classpath jar packet corresponding widget file must include the fully qualified name of the Instrumentation JTI custom class to enhance Dubbo example, the content of

dubbo=org.apache.skywalking.apm.plugin.dubbo.DubboInstrumentation

Second, Custom Instrumentation to ClassInstanceMethodsEnhancePluginDefine must inherit the abstract class, in class, this facility shall designate an enhanced content of two core elements:

. A) need enhanced target class, Class Enhance Technology
. B) plug-in to achieve their specific knockdown achieved xxxxxInterceptor
likewise Dubbo example, if you want to customize their solid plug, then we must specify the following:

Third, the last is to achieve a true definition of an interceptor implementation of the interface InstanceMethodsAroundInterceptor

For each plug-in, it is not necessarily only one Interceptor, can also have multiple, sometimes not necessarily just because you want to intercept a class or a method may be more than one class, there may be one more class the method of one or more methods of a plurality of classes, and therefore, in addition to the first inlet Instrumentation definition, provide enhancements to enhance expansion, the specific method shown below for the plurality Dubbo shown:

Logic plug-ins enhance the body

Understand the relationship between plug-ins to achieve enhanced mechanism of class and class, is still important, it is also the core middleware to enhance the operation of a plug-way, here's a sky-walking carefully under our analysis, how to customize plug-in, and how to enhance the middleware. Throughout the enhanced mechanism, ClassEnhancePluginDefine is very important and the core of a class, in which enhance methods were specified for

Enhanced static method
Implementation enhancement
It defines ConstructorInterceptPoint, InstanceMethodsInterceptPoint, StaticMethodsInterceptPoint

These three constructors, instance methods, static methods point of interception abstract way for plug-in subclasses to achieve interception point

Here is an example DubboInstrumentation insert body in Dubbo implementation class diagram dependent relationship:

The above is ClassEnhancePluginDefine the core body of the core structure class diagram is now mainly to talk about the implementation of such a sequence is composed mainly inside, complete class diagram is shown below:

Seen from above, ClassEnhancePluginDefine inheritance to AbstractClassEnhancePluginDefine, as all the plug-ins must implement the inherited basis, the abstract class AbstractClassEnhancePluginDefine specific definition of what behavior, these behaviors and what significance? What place calls this method?

There are four ways in AbstractClassEnhancePluginDefine

enhance abstract methods, no abstract classes implement subclasses to achieve, particularly enhanced logic
enhanceClass abstract methods, no abstract classes implement the sub-class to implement, particularly to enhance the Match category
WitnessClasses is a method may be overloaded, subclass reloadable
define an instance method, it is mainly made following several things (entry method)

1 WitnessClasses find all enhanced widget class explicitly specified - the user explicitly specify their overloaded
call enhance Method 2, performing enhanced logic true plug-in returns the new DynamicType.Builder
. 3 disposed context, the definition of the initialization step is complete flag
4 newClassBuilder back after the last new second enhancement

Well, in this class, the most important methods define who is calling it?

上面的就是这个类方法被使用的 Usages 情况，主要是被 Sky-Walking Agent 的 Agent 主入口调用，这个方法也是使用 byte-buddy 的字节码增强的 agent 中的一个使用范式，也就是说在 agent 执行真正的 transformer , 所有的插件中因为都是继承至AbstractClassEnhancePluginDefine ，自然它们的 define 的定义的初始化方法，也就会被全部调用初始化，代码如下所示：

对于 snow-walking 来说，使用 Agent 的固定范式（ 来自于 byte-buddy 的固定实现方式）如下所示：

至此，已经分析完了，所有 sky-walking 的自定义插件都必须要继承并重载的抽象类 AbstractClassEnhancePluginDefine ，它定义了所有的Agent 插件都必须要实现的行为，以及它自身需要定义与初始化的行为逻辑。

接下为，真正的主角上场了，它就是 ClassEnhancePluginDefine , 其类的依赖关系如下：

下面看一下类的本身的方法，总共有六个方法：

enhance 方法，重载了父类抽象类 AbstractClassEnhancePluginDefine 的方法，做为所有插件的基类，它定义了 enhance 方法必须所具备的操作。此方法的内部主要做了两件事：

enhanceClass ，增强一个类，以拦截其静态方法
enhanceInstance ，增强一个类，以拦截其构造器与实例方法

除了重载的方法外，其它的三个方法，分别提供了对应的拦截点：

在实现自定义插件逻辑的时候，要重载这三个方法中的实现，以 Dubbo 插件拦截扩展为例，在 DubboInstrumentation 中就重载了父类的getInstanceMethodsInterceptPoints方法，以此来告诉父类中的共性 enhance 增强处理逻辑，本插件的实例方法拦截点的一些元数据信，区配的方法是什么，要增强的类是哪一个，是否要重载其方法参数，这些信息。

上面这里，在具体的 ClassEnhancePluginDefine 实现插件内部，对于拦截器 intercepter 都是指定的是字符串 String 类型，那么父类中ClassEnhancePluginDefine 是如何转化，并在什么时机调用这个 intercepter 的实现类，以执行拦截的真实的逻辑的呢？

那上面的这里从用户自定义的插件中显式的指定了 intercepter Fullname了，到了ClassEnhancePluginDefine后，进行enhance时，会最终都落在 byte-buddy 的 builder. method (....).intercpet (MethodDelegation.xxxx)

这样的固定增强的编程范式当中去。在 sky-walking 的实现中，它又将 intercepter 的名称，根据不同的增强类型，传入了不同类型的具体的委托执行实例当中去执行了。在 sky-walking 中，根据增强的分类类型，委托执行实例分为以下几种：

它们分别是，静态方法固定拦截委托实现器，实例方法固定拦截委托实现器，构造器固定拦截委托实现器，它们只有一个主要的核心执行方法，就是 intercept ，这个方法在执行时是与 byte-budy 的 MethodDelegation 配套使用的，此方法必须要显式的按规定指定相应的byte-buddy 的 Annotation 方能正常的执行增强工作。

因为这三个固定类型的拦截器的处理方式都是差不多，这里就以静态方法拦截器举例分析其内部的执行原理。先看一下这个拦截器的类
的依赖情况：

从上面的此拦截器的依赖情况可以，它主要依赖两个：

StaticMethodsAroundInterceptor ，这个接口的实现者是自定义插件自行根据需求实现的
InterceptorInstanceLoader ，这个是用户自定义插件的拦截器的类加载器

之前我们说，执行 byte-buddy 固定的 intercept 逻辑范式时，通过 MethodDelegation 委托给了 sky-walking 的预设定的几个类型的拦截器，在构建这些固定拦截器时，传入的都是用户自定义的拦截器的 ClassFullName ，所以在真实的固定类型的拦截器内部，就得有一个机制去加载用户自定义的拦截器，只有这样，这些拦截器才能被调用执行。
这些拦截器有三个固定的方法：

beforeMethod ，被拦截方法之前执行
afterMethod ，被拦截方法之后执行
handleMethodException ，处理捕获执行期间的异常

OK ，分析到这里，基本上，用户自定义增强插件，如何被增强，如何被拦截执行的过程应该算是比较清楚了。

增强与拦截机制总结

下图是整理后的关于 sky-walking 的 APM 中用户自定义插件的完整的调用链路，它对于插件如何生效并进行增强与拦截的调用过程做了描绘。