詳解 Apache SkyWalking OAP 的分散式計算

SkyWalking的OAP（Observability Analysis Platform，觀測分析平台）是一個用於鏈路數據的分散式計算系統。

因為它巧妙的設計，使得在鏈路數據計算和聚合過程中，不需要考慮數據的一致性，也沒有事務、分散式鎖等概念。

在極端情況下，可能出現鏈路數據的丟失,但會最大限度保障OAP集群的可用性。咱們來看一下，它是如何設計的，為以後的系統設計和架構提供一些思路。

在介紹分散式計算之前，咱們先了解一下需要計算的數據都有哪些類型：

像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必讀技術書籍

最後，感謝你的點贊和關注，帥氣又美麗。