譯者：董旭（本人：熱心的朝陽群眾）
skywalking做為apache的頂級專案，是乙個開源的apm和可觀測性分析平台，它解決了21世紀日益龐大、分布式和異構的系統的問題。它是為應對當前系統管理所面臨的困難而構建的：就像大海撈針，skywalking可以在服務依賴複雜且多語言環境下，獲取服務對應的指標，以及完整而有意義的效能檢視。
skywalking是乙個非常全面的平台，無論你的微服務是否在服務網格(service mesh)架構下，它都可以提供高效能且一致性的監控。
讓我們來看看，skywalking是如何解決大規模集群的可觀測性問題，並從乙個純粹的鏈路跟蹤系統，發展成為乙個每天分析百億級跟蹤資料，功能豐富的可觀測性平台。
skywalking的誕生，時間要追溯到2023年，當時它主要應用於監控頂級電信公司（例如：中國聯通和中國移動）的第一代分布式核心系統。2013-2023年，這些電信公司計畫用分布式系統取代傳統的單體架構應用。從誕生那天開始，skywalking首要的設計目標，就是能夠支援超大型分布式系統，並具有很好可擴充套件性。那麼支撐超大規模系統要考慮什麼呢？
與資料流向息息相關的：拉取模式和推送模式。agent（客戶端）收集資料並將其推送到後端，再對資料進一步分析，我們稱之為「推送」模式。究竟應該使用拉取還是推送？這個話題已經爭論已久。關鍵因素取決於可觀測性系統的目標，即：在agent端花最小的成本，使其適配不同型別的可觀測性資料。
agent收集資料後，可以在短時間內傳送出去。這樣，我們就不必擔心本地快取壓力過大。舉乙個典型的例子，任意服務都可以輕鬆地擁有數百個甚至數千個端點指標（如：http的uri，grpc的服務）。那麼apm系統就必須具有分析這些數量龐大指標的能力。
此外，度量指標並不是可觀測性領域中的唯一關注點，鏈路跟蹤和日誌也很重要。在生產環境下，skywalking為了能提供100%取樣率的跟蹤能力，資料推送模式是唯一可行的解決方案。
skywalking即便使用了推送模式，同時也可進行資料拉取。在最近的8.x的發版本中，skywalking支援從已經整合prometheus的服務中獲取終端使用者的資料，避免重複工程建設，減少資源浪費。另外，比較常見的是基於mq的傳輸構建拉取模式，kafka消費者就是乙個比較典型的例子。skywalking的agent端使用推送模式，oap伺服器端使用拉取模式。
結論：skywalking的推送模式是原生方式，但拉取式模式也適用於某些特殊場景。
度量指標依賴於數學理論和計算。percentile（百分位數）是用於反映響應時間的長尾效應。服務具備合理的平均響應時間和成功率，說明服務的服務等級目標(slo）很好。除此之外，分布式跟蹤還為跟蹤提供了詳細的資訊，以及可分析的**值指標。
運維團隊（ops）和系統穩定性（sre）團隊通過服務拓撲圖，用來觀察網路情況（當做noc dashboard使用）、確認系統資料流。skywalking依靠trace（跟蹤資料），使用stam（streaming topology analysis method）方法進行分析拓撲結構。在服務網格環境下，使用als（envoy access log service）進行拓撲分析。節點（services）和線路（service relationships）的拓撲結構和度量指標資料，無法通過sdk輕而易舉的拿到。
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-mseayzjy-1598010742309)(
為了解決端點度量指標收集的侷限性，skywalking還要從跟蹤資料中分析端點依賴關係，從而拿到鏈路上游、下游這些關鍵具體的資訊。這些依賴關係和度量指標資訊，有助於開發團隊定位引起效能問題的邊界，甚至**塊。
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-vymtj3bw-1598010742312)(
相比查詢時計算的靈活性，預計算可以提供更好、更穩定的效能，這在分析場景下尤為重要。回想一下我們的設計原則：skywalking是為了乙個大規模的分布式系統而設計。查詢時計算的使用範圍非常有限，大多數度量計算都需要預先定義和預先計算。支援大資料集的關鍵是：在設計階段，要減小資料集。預計算允許將原始資料合併到下游的聚合結果中，用於查詢，甚至用於警報檢查。
使用skywalking的另乙個重要因素是：指標的有效期，ttl（time to live）。由於採用了預先計算，查詢提供了近似線性的高效能。這也幫助「查詢系統」這類基礎設施系統，提供更好的效能擴充套件。
關於警報，使用查詢時計算方案，也意味著警報查詢需要基於查詢引擎。但在這種情況下，隨著資料集增加，查詢效能會隨之下降，其他指標查詢也是一樣的結果。
在很多行業中，skywalking是被應用於超大型分布式系統各種場景下的乙個可觀測性平台：
永輝超市
貝殼找房(ke.com)
阿里雲效
阿里巴巴天貓
skywalking針對可觀測性遵循以下原則：
理解邏輯模型：不要把可觀測性當作數學統計工具。
首先確定依賴關係，然後確定它們的度量指標。
原生和方便的支撐大規模增長。
在不同的架構情況下，apm各方面表現依然保持穩定和一致。
訪談 阿里超大規模Docker化之路
林昊 畢玄 阿里巴巴研究員，平台架構部負責人，服務框架 hsf 作者，異地多活專案負責人，目前致力於資源統一管理排程系統建設。眾所周知docker技術這幾年大熱，但是過去相當長的一段時間內，阿里內部技術人員只能自己私下玩玩，沒法在阿里內部生產環境使用docker，因為docker要求的os版本和核心...
Azure超大規模資料庫入門
雲的優勢之一是規模。我們不會將三大雲平台稱為超大規模。他們在全球擁有龐大的資料中心，擁有數百萬台伺服器，這些伺服器可以視為計算和儲存池。現代的分布式應用程式可以執行在許多計算核心上，每個核心都有自己的記憶體，所有定址核心都達到了tb級。我們從構成雲的所有物理基礎架構中抽象出來，將我們使用的所有內容都...
azure 入門 Azure超大規模資料庫入門
azure 入門 雲的優勢之一是規模。我們不會將三大雲平台稱為超大規模。他們在全球擁有龐大的資料中心，擁有數百萬台伺服器，這些伺服器可以視為計算和儲存池。現代的分布式應用程式可以執行在許多計算核心上，每個核心都有自己的記憶體，所有定址核心都達到了tb級。我們從構成雲的所有物理基礎架構中抽象出來，將我...