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必讀技術書籍
最后，感謝你的點贊和關注，帥氣又美麗。