在解析SkyWalking的源碼之前，我們先來了解下SkyWalking中的插件機制，那它的作用是什麽？為什麽先要去了解它呢？我們知道SkyWalking是用來監控應用程序的系統，那它必然需要收集我們應用程序中需要監控的相關數據，那問題就來了，它怎麽知道我們系統中需要收集哪些數據？所以插架的作用就在於此，由於對監控的應用程序的不確定性，進而提供了可擴展的插件機制來滿足實際的業務監控需求。
為什麽先要去了解它？因為對監控數據的來源收集是應用監控的基礎，也是第壹步，也就是SkyWalking中的探針部分，同時它也是我們解析Agent啟動源碼中重要的壹環。
在SkyWalking的文檔及源文件中，相信妳能看到官方已經提供了很多常見框架的不同版本的通用插件，這裏面壹些由官方提供，壹些由社區開發者Pull；但是如果妳想在項目中重度使用SkyWalking來做APM，僅僅使用這些插件還是不夠的，妳必然需要封裝符合自己業務監控需求的插件，相應的，妳必須的知道插件的機制以及如何開發。
工欲善其事必先利其器，開發插件前，我們先得具備SkyWalking的插件中的基礎概念以及開發規範的要點。
它是上下文管理器，是SkyWalking中的核心API，負責提供所有主要的API，像下文中Span和Context的壹些列操作都是由它封裝並提供方法，同時負責維護Context上下文，內部是通過 ThreadLocal 來進行多線程的隔離和維護的，在後面插件開發的過程中會經常使用到這個類的。
跨度，它是系統中完成的單個工作單元，通俗的說壹條完整的調用鏈路就是由多個Span單元組成的，通過下圖相信妳會更加直觀的了解它，
這是 /storage/waste 的壹條調用鏈路，下面的每壹行就代表壹個Span，上面的 test 是自定義的插件攔截定義的Span。
OpenTracing的規範中定義了壹個Span需要包含操作名稱、開始和結束時間、跨度標簽、跨度日誌、 SpanContext ，其中SpanContext的作用是攜帶跨進程的邊界數據，由 traceId 、 spanId 、鍵值對數據組成。
而SkyWalking的Span概念與之類似，同時提供了壹些擴展，我們先來看下Span的類圖結構,
首先 AsyncSpan 定義了壹個頂層接口，
能看到裏面定義了兩個方法，它們是在異步場景下使用的API，當Span中的組成信息需要在另壹個線程中進行設置時，像標簽、日誌、屬性等，就可以使用它們。使用的方式也很簡單，比如在A線程的Span裏面調用 prepareForAsync() 方法，然後再B線程中拿到Span進行設置，完成後調用 asyncFinish() 方法來結束調用即可。
再來看它的子類接口 AbstractSpan ，它裏面就定義了Span的屬性組成，像操作名稱OperateName、標簽Tag、日誌Log、組件Component、類別Layer等等。其中
而下面的實現子類中，其中 NoopSpan 是壹個空實現，沒有任何實際操作，用來存放 IgnoredTracerContext 的，我們主要看 AbstractTracingSpan 下三個重要的實現子類：
我們再定義Span的時候只需要根據上面的描述創建相應的Span即可，其中 EntrySpan 和 ExitSpan 註意要設置Component和Layer值。這裏創建Span的方式也很簡單，利用 ContextManager 提供的API來完成，
Context通常代表著上下文，相信看過壹些框架源碼，像Spring等，壹定對它很熟悉；那我們來看看SkyWalking中的Context是怎麽定義的，先看類圖，
這裏 AbstractTracerContext 是壹個頂層接口，代表著跟蹤上下文的管理器， IgnoredTracerContext 剛才我們提到過，源碼註釋中對其說明是表示壹個被忽略的上下文，主要作用是用壹個字段 int stackDepth 來維護堆棧深度，它通常在Span中的OperateName定義為空時會被創建；而 TracingContext 才是核心跟蹤邏輯控制器，它保存著壹些基本的信息個狀態以外，還存放著上下文中傳播的 Span 和跨度深度等重要數據。
我們在創建 Span 的時候方法內部會自動幫我創建 AbstractTracerContext 並初始化，所以不用擔心，主要在下面兩種情況下會需要我們進行傳遞處理：
通過上面我們知道了SkyWalking中插件的作用、自定義插件中需要定義的哪些基本信息和規範，以及如何在不同的場景下進行上下文的傳播，那接下來就是如何進行插件開發了，下壹篇我們繼續。
身未動，心已遠。
把壹件事做到極致就是天分！