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必讀技術書籍
最后，感謝你的點贊和關注，帥氣又美麗，
作者：萬貓學社
出處：http://www.cnblogs.com/heihaozi/
著作權宣告：本文遵循 CC 4.0 BY-NC-SA 著作權協議，轉載請附上原文出處鏈接和本宣告，
微信掃描二維碼，關注萬貓學社，回復「電子書」，免費獲取12本Java必讀技術書籍，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/424877.html
標籤：Java