我眼中的分佈式系統可觀測性

作者 | 黃東旭，PingCAP 聯合創始人兼 CTO

位於 M87 中心的特大質量黑洞示意圖（© EHT Collaboration）

今天的文章我想從這張模糊的照片說起。

相信很多小夥伴對這張照片並不陌生，這是去年人類第一次拍攝的 M87 中心黑洞的照片，從 1915 年，愛因斯坦提出相對論預言黑洞的存在到 2019 年我們終於第一次「看到」了黑洞的樣子，中間整整相隔了 100 多年，這對於人類認識黑洞乃至認識宇宙都是一個里程碑式的事件。人類是一個感性的動物，所謂「一圖勝千言」很多時候一張圖傳達的信息超過千言萬語。

關於黑洞我不想展開太多，今天我們聊聊「望遠鏡」。

前幾天，在 TiDB 4.0 的開發分支中，我們引入了一個新功能叫做：Key Visualizer（下面簡稱 KeyViz），說起來這個小工具也並不複雜，就是用不同顏色的方框來顯示整個數據庫的不同位置數據訪問頻度和流量。一開始我們只是僅僅將它定位爲一個給 DBA 用來解決數據庫熱點問題的調優輔助小工具，但是從昨晚開始我就一直在把玩這個小東西，突然覺得它對於分佈式數據庫來說背後的意義遠不及此。

在 CNCF 對 Cloud Native 的定義中，有一條叫做「Observability」，通用的翻譯叫系統的「可觀測性」。過去我一直苦於尋找一個例子說明什麼叫做一個「可觀測」的系統，在 KeyViz 這個項目上，我找到了對這點絕佳的體現。

舉幾個直觀的小例子。你知道 TPC-C 測試「長」什麼樣子嗎？請看下圖：

KeyViz 給 TPC-C 拍攝的「照片」

圖中橫軸是時間，縱軸是數據的分佈，左半部分是數據導入的過程，有零星的亮點，可以看到寫入分散到多個區塊；右邊密集的色塊是測試在運行時系統的實時讀寫狀態，越暗表示流量越小，越亮表示流量越高。從密集的色塊我們能夠看得出來，workload 基本分佈均勻，但是大概有兩處是明顯偏亮的區域，其中靠近最上方，有一個特別明顯的 局部訪問熱點（最亮的那條線）。

第二個例子，你見過 Sysbench 測試 「長」什麼樣子嗎？看看下面。

左邊比較密集的明亮黃塊部分，是導入數據階段；右半段明暗相間的部分是在進行 oltp_point_select 測試，因爲選取的模式是 uniform 模式，並且導入的時候是 32 線程 32 張測試表，可以看到的數據和分佈和訪問都比較均勻。

如果你看懂了上面兩個小例子，下面是一個小作業：這是我們模擬的一個實際用戶的生產環境的照片，這個用戶的系統遇到了一些瓶頸，你能看出問題嗎？

上面幾個小例子是讓大家對 KeyViz 有個感性的認識，在介紹這個東西背後的意義之前，我想先介紹一下 TiDB 這類典型的分佈式數據庫的系統架構，方便大家更好的理解。

一個典型的分佈式數據庫的數據分佈策略

分佈式數據庫，顧名思義，數據一定是分散在不同機器上的。對於一張表的數據，我們會在邏輯上切分成若干個連續的區間，將這些區間內的數據分給不同的機器存儲，不管是寫入還是讀取，只需要知道目標數據屬於哪個區間，就可以直接到那個機器上進行訪問。然後加上對每一個區間的數據在物理上做多副本冗餘，實現高可用。如下圖所示，Region 在 TiDB 的內部就是一個個連續的數據區間。

和很多分佈式數據庫不太一樣的是，我們的 Region 的大小比較小（默認 96MB) ，另外數據的分佈並不是靜態的，而是動態的，Region 會像細胞一樣分裂 / 合併，也會在不同機器之間移動進行動態的負載均衡。

現在回頭看這個設計，還是覺得無比的簡潔和優雅。對用戶而言再也不用去思考怎麼分庫，怎麼分表，數據在最底層的細胞就像有生命一樣繁衍和遷徙。

然後問題就來了，對於這樣的數據庫而言，有沒有一種辦法能夠直觀地描述系統的運行時狀態？我怎麼知道它是不是「生病」了？我能不能預測這個系統的未來？我能不能發現未知的風險？

過去，不管是業務開發者還是 DBA，衡量一個數據庫的狀態，來來回回就是幾個指標，QPS 、TPS、查詢時間、機器負載（CPU、網絡、磁盤），但很多時候就像是盲人摸象一樣對於系統的全局我們是不清楚的。再加上在一個分佈式的架構下，很多時候，我們可能會被海量的數字矇蔽了雙眼。一些有經驗的 DBA 或許可以通過自己的經驗，從多個指標裏模糊構建出業務全局狀態，但是到底這個經驗往往是不可描述的，這就是爲什麼一些老運維、老 DBA 那麼值錢的原因，但是我認爲這種做事方式是很難 scale 的。

CT 、B 超、核磁共振，這些現代化的手段極大地促進了現代醫學的發展，因爲我們第一次能「看見」我們身體的內部狀態，從而才能得出正確的判斷。在計算機的世界道理也是相通的，最好通過某些工具讓人清晰地「看見」系統運行的健康狀態、幫助診斷病竈，從而降低經驗門檻和不確定性。

過去也經常有朋友問我：“你說我這個業務適不適合使用 TiDB？” 這時我們只能問，你的 QPS 多少 TPS 多少，數據量多少？讀寫比？典型查詢？數據分佈怎麼樣？表結構是什麼呀？等等一連串的靈魂拷問，而且很多術語都非常專業，不是在這個行業摸爬滾打很久的老司機可能都搞不太清楚。而且有些信息可能是敏感的，也不方便共享。所以「預判 TiDB 到底適不適合某項業務」就成了一個玄學問題，這個問題困擾了我很久，很多時候也只能憑個人感覺和經驗。其實這個問題也並不是 TiDB 特有，尤其是最近幾年，幾乎所有現代的分佈式系統，都或多或少有類似的問題。

** 在過去，一個物理機器的狀態確實可以通過幾個監控指標描述，但是隨着我們的系統越來越複雜，我們的觀測對象正漸漸的從「Infrastructure」轉到「應用」，觀察行爲本身從「Monitoring（監控）」到「Observability（觀測）」。雖然看上去這兩者只是文字上的差別，但是請仔細思考背後的含義。關於這個話題，我很喜歡引用下面這張圖：

上圖座標描述了我們對系統的理解程度和可收集信息之間的關係。在 X 軸的右側（Known Knows 和 Known Unknowns）這些稱爲確定性的已知和未知，圖中也給出了相對應的例子，這些信息通常是最基礎的普適的事實，也就是在系統上線之前我們一定就能想到，一定能夠監控起來的（CPU Load、內存、TPS、QPS 之類的指標），我們過去已有的大多數運維監控都是圍繞這些確定的東西。

但是有一些情況是這些基礎信息很難描述和衡量的，例如這個座標的左上角：Unknown Knowns，用通俗的話來說，叫做 「假設」。舉個數據庫的例子：有經驗的架構師在設計一個基於分佈式數據庫的應用時，通常不會將表的主鍵設成自增主鍵，會盡可能的用 UUID 或者其他方式打散數據，這樣在即使有突發寫入壓力的時候，系統也能很好的擴展。

注意在這個例子中，其實「假設」的事情（寫入壓力突然增大）並沒有發生，如果在日常壓力不大，數據量不多的情況下，即使使用自增主鍵，從已有的基礎監控中，可能也很難看出任何問題。但是到出事的時候，這個設計失誤就會變成 Unknown Unkowns（意外），這是任何人都不想看到的。有經驗的架構師能通過種種的蛛絲馬跡證實自己的推測，也從無數次翻車的 Post-mortem 中將 Unknown Unknowns 的範圍變小。但是更合理的做法是通過技術手段描繪系統更全面的狀態。在 Cloud Native 和微服務的世界裏，最近幾年一個行業的大趨勢是將「系統的可觀測性」放在一個更高的位置（監控只是可觀測性的一個子集），這是有道理的。

回到數據庫的世界，TiDB KeyViz 的意義在於，就像上面提到的，這個工具不僅僅是一個監控工具，而且它能以一個非常低門檻且形象的方式讓架構師具象化的看到自己對於業務的「假設」是否符合預期，這些「假設」不一定是能夠通過監控反映的，以獲得對業務更深刻的 Insight。

還是說回上面那個主鍵的小例子。對於兩種不同的主鍵設計，KeyViz 這邊是怎麼表現的呢？看看下面兩張圖，是不是非常一目瞭然？

所以現在如果有朋友問我，“這個業務適不適合 TiDB？” 我只需要通過錄制線上流量，或者搭建一個從集羣，只需要把 KeyViz 的圖給我看一眼，我甚至都不需要壓力測試就能判斷這個業務是否適合，而且即使不適合，我也能準確的給出修改建議，因爲 KeyViz 的圖對我的「假設」的可解釋性有了很強的支持。

我們不妨在此基礎上再放飛一下想象力，爲什麼人類能夠一眼就從這圖片中理解這些信息，這說明這些圖形背後有模式，有模式我們就可以識別——

想象一下，如果所有的 TiDB 用戶，都使用 KeyViz 將自己的系統具象化後分享出來（其實這些圖片已經高度抽象，已經不具有任何的業務機密信息），我們是不是可以通過機器學習，挖掘背後更深層次的價值？AI 能不能通過這種形式更加理解我們的業務？

最後，我想以我最喜歡的科幻小說《三體：黑暗森林》中的一段話結束這篇文章，大致是面壁人希恩斯在冬眠後被妻子喚醒後的一個場景：

…… 與此同時，希恩斯感覺到圍繞着他們的白霧發生了變化，霧被粗化了，顯然是對某一局部進行了放大。他這時發現所謂的霧其實是由無數發光的小微粒組成的，那月光般的光亮是由這些小微粒自身發出的，而不是對外界光源的散射。放大在繼續，小微粒都變成了閃亮的星星。希恩斯所看到的，並不是地球上的那種星空，他彷彿置身於銀河系的核心，星星密密麻麻，幾乎沒有給黑夜留出空隙。

“每一顆星星就是一個神經元。” 山杉惠子說，一千億顆星星構成的星海給他們的身軀鍍上了銀邊。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/EPE9gBsA9fxYrJhvJgHTaA