SkyWalking的OAP（Observability Analysis Platform，觀測分析平臺）是一個用於鏈路資料的分散式計算系統。
因為它巧妙的設計，使得在鏈路資料計算和聚合過程中，不需要考慮資料的一致性，也沒有事務、分散式鎖等概念。
在極端情況下，可能出現鏈路資料的丟失,但會最大限度保障OAP叢集的可用性。我們們來看一下，它是如何設計的，為以後的系統設計和架構提供一些思路。
資料型別
在介紹分散式計算之前，我們們先了解一下需要計算的資料都有哪些型別：
- Record資料，即明細資料，如Trace、訪問日誌等資料，由
RecordStreamProcessor進行處理。 - Metrisc資料，即指標資料，絕大部分的OAL指標都會生成這種資料，由
MetricsStreamProcessor進行處理。 - TopN資料，即週期性取樣資料，如慢SQL的週期性採集，由
TopNStreamProcessor進行處理。
分散式計算
像Trace、訪問日誌等這樣的明細資料，資料量比較大，但是不需要歸併處理，所以在OAP節點內部處理即可完成。明細資料採用快取、非同步批量處理和流式寫入的方式寫入到儲存中。
絕大部分由OAL（Observability Analysis Language，觀測分析語言）定義的指標資料是需要分散式聚合計算的，所以在OAP叢集計算流中分成了兩種步驟。
步驟一：接收和解析探針傳送的資料，並進行當前OAP節點內的資料聚合，使用OAL或者其他聚合模式。如果是不需要分散式聚合的資料，直接寫入到儲存中；如果是需要分散式聚合的資料，根據一定的路由規則傳送給指定的OAP節點。
步驟二：接收和解析經步驟一處理過的資料，然後進行二次聚合計算，並寫入到儲存中。
因為上面兩個步驟極有可能不在同一個OAP節點上，所以OAP節點被分為Receiver（步驟一）和Aggregator（步驟二）兩種角色。
為了減少部署難度，所有OAP節點在預設情況下都會使用Mixed角色（既可以進行步驟一的操作，也可以進行步驟二的操作）。在大規模部署的時候，可以根據網路流量進行角色分離的兩級部署。
指標資料是計算資源消耗最大的分散式計算，也是整套分散式計算要支援的核心計算型別。在此計算過程中，使用雜湊路由策略，根據計算的實體，如服務ID、端點ID等的雜湊值來選擇對應的OAP節點。
OAP節點之間的通訊採用的是 gRPC stream 模式，傳輸過程中不包含業務欄位名稱，按照資料型別和欄位定義順序進行序列化，減少非資料欄位的傳輸。
注：本文以SkyWalking的8.2.0版本為例進行介紹，如果版本不同會略有差異。
微信公眾號：萬貓學社
微信掃描二維碼
關注後回覆「電子書」
獲取12本Java必讀技術書籍
最後，感謝你的點贊和關注，帥氣又美麗。