導讀：本文摘自于SkyWalking創始人吳晟撰寫的《Apache SkyWalking實戰》一書，詳細講述了SkyWalking的架構設計與優勢。
吳晟：Apache基金會會員，Apache SkyWalking創始人、項目VP和PMC成員，Apache孵化器PMC成員，Apache ShardingSphere PMC成員，Apache APISIX (incubating) PPMC成員，Apache ECharts (incubating)和Apache DolphinScheduler (incubating)孵化器導師，Zipkin成員和貢獻者，CNCF OpenTracing核心維護者。
1. SkyWalking的架構設計
如圖所示，SkyWalking官方架構圖對SkyWalking的整體架構進行了非常直觀的描述。SkyWalking由以下4個核心部分構成。
SkyWalking官方架構圖
- 探針。探針（對應圖中Tracing和Mestrics部分）可以是語言探針，也可以是其他項目的協議。
- OAP平臺（Observability Analysis Platform），或稱OAP Server。它是一個高度組件化的輕量級分析程序，由兼容各種探針的Receiver、流式分析內核和查詢內核三部分構成。
- 存儲實現（Storage Implementors）。SkyWalking的OAP Server支持多種存儲實現，并且提供了標準接口，可以實現其他存儲。
- UI模塊（SkyWalking）。通過標準的GraphQL協議進行統計數據查詢和展現。
從設計角度而言，SkyWalking總體遵循以下三大設計原則：
- 面向協議設計
- 模塊化設計
- 輕量化設計
面向協議設計
面向協議設計是SkyWalking從5.x開始嚴格遵守的首要設計原則。SkyWalking包含下列對外協議。
1. 探針協議
探針協議分為四大類。
- 語言探針上報協議。此協議包括語言探針的注冊、Metrics數據上報、Tracing數據上報、命令下行，以及Service Mesh中使用的Telemetry協議。所有基于語言（JAVA、.NET、Node.js、php、Go等）的探針都需要嚴格遵守此協議定義。此協議從v6版本開始全部以gRPC服務方式對外提供。
- 語言探針交互協議。因為分布式追蹤，探針間需要借助HTTP Header、MQ Header等應用間通信管道進行交互。此協議定義交互格式。所有基于語言（Java、.NET、Node.js、PHP、Go等）的探針都需要嚴格遵守此協議定義。此協議從v2開始執行與v1不同的編碼方法，加入了強制Base64的要求。將從SkyWalking 8開始執行的全新v3協議，簡化了編碼，提供了更多特性，比如透傳業務信息、探針交互能力等。
- Service Mesh協議。此協議是SkyWalking針對Service Mesh抽象的專有協議，任何Mesh類的服務都可以通過此協議直接上行Telemetry數據，用于計算服務Metrics和拓撲圖。
- 第三方協議。針對大型的第三方開源項目，尤其是Service Mesh核心平臺Istio和Envoy，提供核心協議適配，支持針對Istio+Envoy的Service Mesh進行無縫監控。
2. 查詢協議
查詢協議使用GraphQL格式定義的查詢協議。多數讀者可能更熟悉RESTful格式的查詢，但SkyWalking考慮到更好的擴展性、更加靈活的組合查詢模式，選擇了由Facebook在2012年開源的GraphQL。GraphQL在開源和商業項目中已經得到了廣泛運用。協議格式的預定義和多種查詢組合使用提供了UI和第三方系統良好的集成能力。熟悉SkyWalking歷史的讀者會知道，SkyWalking在6.0.0-GA之后的版本，更換了全新的RocketBot UI作為默認UI，這個過程得益于GraphQL的靈活性，后端協議和實現可以完全不變。社區中已有大量公司基于此協議包裝了云平臺產品的UI。
查詢協議分為以下6類。
- 元數據查詢：查詢在SkyWalking注冊的服務、服務實例、Endpoint等元數據信息。
- 拓撲關系查詢：查詢全局或者單個服務或Endpoint的拓撲圖及依賴關系。
- Metrics指標查詢：線性指標查詢。
- 聚合指標查詢：區間范圍均值查詢及TopN查詢等。
- Trace查詢：追蹤明細查詢。
- 告警查詢。
除了上述兩大類協議外，部分模塊也存在一些模塊內協議，如導出的數據格式協議、告警協議、動態配置服務協議等。這些協議與執行模塊的默認實現有關，屬于SkyWalking默認對外集成協議的范圍，考慮到模塊化設計，這些協議本身也是可以替換的，這里就不一一描述了。
模塊化設計
模塊化設計，旨在以開源項目為內核，為更多的企業內部定制服務、商業產品的二次包裝及插拔機制提供插撥機制與擴展點。開源項目的一致性升級至關重要，模塊化設計，明確接口邊界，使得擴展很容易跟上開源版本升級的節奏。對于商業包裝和開源產品的迭代發展，這是必不可少的一環。
大型的開源項目，無一不是由大量的商業公司/商業目的推進，不可能由個人憑興趣在業余時間完成。雖然SkyWalking在早期的一到兩年是個人基于興趣在推進，但隨著社區的壯大和商業價值的體現，開放、包容、具有擴展性的架構是必不可少的特性。Apache SkyWalking作為Apache頂級項目，基于商業友好的Apache 2.0開源協議，在設計上也充分考慮了定制化及二次開發的可能性。
SkyWalking根據探針和服務端的不同特性，使用了兩種不同的模塊化機制。
Java探針端，Java使用了較為緊湊的實現，主要使用SPI將核心服務隔離成替換狀態，用戶可以像開發plugin一樣，只需將新的服務實現放在plugin目錄中，即可實現自動替換。
后端（OAP Server）使用YML定義的模塊化。SkyWalking將模塊化定義為模塊（Module）和實現（Provider）兩部分。模塊為抽象概念，提供對外服務方法的定義和聲明；Provider需要實現這些服務方法，同時聲明此實現依賴的其他模塊。值得注意的是，模塊本身不聲明依賴，依賴由實現（Provider）聲明。這種模式允許用戶替換和新增所需的模塊，并進行組織。
輕量化設計
SkyWalking在設計之初就提出了輕量化的設計理念。APM雖然是運維端的核心系統，但放在整套業務架構下，屬于二線支撐系統，不承擔系統主要業務功能。而絕大多數的分析系統要求大數據作為其核心技術，但是技術團隊應該都了解，大數據天然具有維護難度大和門檻高的問題。基于此背景，SkyWalking核心要求能夠在非大數據架構下，使用最輕量級的jar包模式，形成強大的分析能力、擴展能力和模塊化能力。
2 SkyWalking的優勢
SkyWalking的優勢在于它緊跟當前的技術發展趨勢，保證同一套APM系統適用于傳統架構和云原生架構。另外，在技術設計理念上，SkyWalking提供了較大的包容性和擴展性，適用于不同的用戶場景和定制需求。
2.1 傳統分布式架構與云原生的一致性支持
隨著近十年服務化和微服務化的進程，以RPC和HTTP服務為通信技術核心，以注冊中心作為服務注冊與服務發現的架構，已經成為國內成熟的微服務“傳統”架構。主流技術有Spring Cloud、Apache Dubbo等。SkyWalking從2015年項目誕生之初，就把這種傳統的分布式架構及自動探針作為最為核心的功能。SkyWalking可以無縫支持已經穩定的分布式服務架構，方便替換傳統的監控手段，而無須增加運維團隊和開發團隊的工作量。
同時，從2018年起，由google、Lyft和CNCF的Istio與Envoy組成的Service Mesh方案開始流行，提供了在Kubernetes上創新的分布式服務管理、監控和安全管理能力。SkyWalking項目團隊也一直關注這一動向，在Istio 1.0.4發布的同時發布了SkyWalking 6的測試版本，并在3個月后開始發布SkyWalking 6穩定版本。在6.x版本中，SkyWalking針對Istio和Envoy組成的Service Mesh方案提供了核心適配能力。用戶可以認為Service Mesh構成了SkyWalking的一種新的語言無關的探針形式。利用SkyWalking的后端OAP平臺以及UI，可以對Service Mesh管理中的服務提供同樣的依賴拓撲、服務性能指標、告警等能力。90%以上的配置與使用其他語言探針（如Java探針）時完全一致。
這也是首個在開源軟件中實現語言探針和Service Mesh一致性解決方案的項目。為不同公司的技術棧提供統一的監控能力，更有利于公司在未來系統架構升級中保持監控系統的一致性。這個一致性不單單指SkyWalking的使用，更是對于用戶在SkyWalking構建的生態系統，如告警平臺、AIOps、指標基線計算系統、彈性計算等，保持一致性。
2.2 易于維護
SkyWalking一直堅持以易于維護為核心需求，不引入過多的技術棧，以免成為一個過于復雜的監控系統。這其中的深層邏輯在于，監控系統作為二線甚至三線系統，應該利用有限的環境資源，提供盡可能大的監控價值，同時盡可能降低對于運維的要求。在SkyWalking集群模式下，大量公司每日需要采集超過百億級別的監控數據及明細，SkyWalking不要求使用復雜的大數據平臺，以減少系統的入門難度和維護負擔。同時SkyWalking的構建集群架構比較簡單，用戶只要針對自己的數據量，對于不同的存儲平臺（如MySQL、TiDB或Elasticsearch等）具備基本的集群運維能力，就可以輕松監控百億級的流量系統。
2.3 高性能
SkyWalking并不會因為追求簡單、易于維護而降低對性能的要求。SkyWalking內置一套針對分布式監控專門設計的可擴展流計算框架（參見第7章），該計算框架針對監控數據特別設計了特定的流程，并利用字節碼技術來兼顧擴展性和系統性能。
SkyWalking在永輝超市的典型公開案例中，使用15臺OAP節點和20臺Elasticsearch節點，就支撐了250多個服務每天高達3TB的監控數據，數據流量超過百億。在6.x中，SkyWalking性能從6.0-GA到6.4，每個版本都得到了明顯提升。
2.4 利于二次開發和集成
SkyWalking的二次開發和集成的便利性主要分為兩方面。
面向協議和模塊化的設計。面向協議保證其他的探針接入，只需要學習協議就可以輕松完成對接。而模塊化給予用戶深度定制的能力，模塊實現的可切換使用戶可以對分布式計算過程、集群管理與協調模式、存儲、告警引擎、可視化頁面等進行個性化定制。
大量的SkyWalking內置實現提供了第三方網絡接口，HTTP或gRPC接口。用戶可以使用第三方程序進行對接，而非進行程序改造。這樣能保證SkyWalking版本升級時周邊生態的穩定。而且在容器化大行其道的今天，網絡接口集成的方式也更為友好。
SkyWalking的幾百家公開用戶大量使用了這些擴展方式，定制了豐富的內部系統，也保證了SkyWalking內核的穩定和高通用性。
關于SkyWalking的實戰內容推薦閱讀《Apache SkyWalking實戰》一書，本文經出版社授權發布。
