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

做者：黃東旭，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 能不能經過這種形式更加理解咱們的業務？

---

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

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

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