我覺得面對測試的態(tài)度是區(qū)分一個普通程序員和優(yōu)秀程序員的重要標(biāo)準(zhǔn)。

現(xiàn)如今我們的程序和服務(wù)越來越龐大，光是單元測試 TDD 之類的就已經(jīng)很難保證質(zhì)量，不過這些都是 baseline，所以今天聊點新的話題。

說測試之前，我們先問下自己，為什么要測試？當(dāng)然是為了找 Bug?？雌饋磉@是句廢話，但是仔細(xì)想想，如果我們能寫出 Bug-free 的程序不就好了嗎？何必那么麻煩。不過 100% 的 bug-free 肯定是不行的，那么我們有沒有辦法能夠盡可能地提升我們程序的質(zhì)量？

舉個例子，我想到一個 Raft 的優(yōu)化算法，與其等實現(xiàn)之后再測試，能不能在寫代碼前就知道這個算法理論上有沒有問題？辦法其實是有的，那就是形式化證明技術(shù)，比較常用的是 TLA+。

1. TLA+

TLA+ 背后的思想很簡單，TLA+ 會通過一套自己的 DSL（符號很接近數(shù)學(xué)語言）描述程序的初始狀態(tài)以及后續(xù)狀態(tài)之間的轉(zhuǎn)換關(guān)系，同時根據(jù)你的業(yè)務(wù)邏輯來定義在這些狀態(tài)切換中的不變量，然后 TLA+ 的 TLC model checker 對狀態(tài)機的所有可達(dá)狀態(tài)進(jìn)行窮舉，在窮舉過程中不斷檢驗不變量約束是否被破壞。

舉個簡單的例子，分布式事務(wù)最簡單的兩階段提交算法，對于 TLA+ Spec 來說，需要你定義好初始狀態(tài)（例如事務(wù)要操作的 keys、有幾個并發(fā)客戶端等），然后定義狀態(tài)間跳轉(zhuǎn)的操作（ Begin / Write / Read / Commit 等），最后定義不變量（例如任何處于 Committed 狀態(tài)的 write ops 一定是按照 commit timestamp 排序的，或者 Read 的操作一定不會讀到臟數(shù)據(jù)之類的），寫完以后放到 TLC Checker 里面運行，等待結(jié)果就好。

但是，我們活在一個不完美的世界，即使你寫出了完美的證明，也很難保證你就是對的。第一， Simulator 并沒有辦法模擬出無限多的 paticipants 和并發(fā)度， 一般也就是三五個；第二，聰明的你可能也看出來了，一般 TLA+ 的推廣文章也不會告訴你 Spec 的關(guān)鍵是定義不變量，如果不變量定義不完備，或者定義出錯，那么證明就是無效的。因此，我認(rèn)為形式化驗證的意義在于讓工程師在寫代碼之前提高信心，在寫證明的過程中也能更加深對算法的理解，此外，如果在 TLC Checker 里就跑出異常，那就更好了。

目前 PingCAP 應(yīng)該是國內(nèi)唯一一個使用 TLA+ 證明關(guān)鍵算法，并且將證明的 Spec 開源出來的公司，大家可以參考  pingcap/tla-plus  這個 Repo。

2. Chaos Engineering

如果完美的證明不存在，那么 Deterministic 的測試存在嗎？我記得大概 2015 年在 PingCAP 成立前，我看到了一個 FoundationDB 關(guān)于他們的 Deterministic 測試的 演講。簡單來說他們用自己的 IO 處理和多任務(wù)處理框架 Flow 將代碼邏輯和操作系統(tǒng)的線程以及 IO 操作解耦，并通過集群模擬器做到了百分之百重現(xiàn) Bug 出現(xiàn)時的事件順序，同時可以在模擬器中精確模擬各種異常，確實很完美。但是考慮到現(xiàn)實的情況，我們當(dāng)時選擇使用的編程語言主要是 Go，很難或者沒有必要做類似 Flow 的事情 。所以我們選擇了從另一個方向解決這個問題，提升分布式環(huán)境下 Bug 的復(fù)現(xiàn)率，能方便復(fù)現(xiàn)的 Bug 就能好解決，這個思路也是最近幾年很火的 Chaos Engineering。做 Chaos Engineering 的幾個關(guān)鍵點：

定義穩(wěn)態(tài)，記錄正常環(huán)境下的 workload 以及關(guān)注的重要指標(biāo)。

定義系統(tǒng)穩(wěn)態(tài)后，我們分為實驗組和對照組進(jìn)行實驗，確認(rèn)在理想的硬件情況下，無論如何操作實驗組，最后都會回歸穩(wěn)態(tài)。

開始對底層的操作系統(tǒng)和網(wǎng)絡(luò)進(jìn)行破壞，再重復(fù)實驗，觀察實驗組會不會回歸穩(wěn)態(tài)。

道理大家都懂，但是實際做起來最大的問題在于如何將整個流程自動化。原因在于：一是靠手動的效率很低；二是正統(tǒng)的 Chaos Engineering 強調(diào)的是在生產(chǎn)環(huán)境中操作，如何控制爆炸半徑，這也是個比較重要的問題。

先說第一個問題，PingCAP 在實踐 Chaos Engineering 的初期，都是在物理機上通過腳本啟停服務(wù)，所有實驗都需要手動完成，耗時且非常低效，在資源利用上也十分不合理。這個問題我們覺得正好是 K8s 非常擅長的，于是我們開發(fā)了一個基于 K8s 的，內(nèi)部稱為 Schrodinger 的自動化測試平臺，將 TiDB 集群的啟停鏡像化，另外將 TiDB 本身的 CI/CD，自動化測試用例的管理、Fault Injection 都統(tǒng)一了起來。這個項目還催生出一個好玩的子項目 Chaos Operator：我們通過 CRD 來描述 Chaos 的類型，然后在不同的物理節(jié)點上啟動一個 DaemonSets，這個 DaemonSets 就負(fù)責(zé)干擾 Pod，往對應(yīng)的 Pod 里面注入一個 Sidecar，Sidecar 幫我們進(jìn)行注入錯誤（例如使用 Fuse 來模擬 IO 異常，修改 iptable 制造網(wǎng)絡(luò)隔離等），破壞 Pod。近期我們也有計劃將 Chaos Operator 開源。

第二個問題，其實在我看來，有 Chaos Engineering 仍然還是不夠的，我們在長時間的對測試和質(zhì)量的研究中發(fā)現(xiàn)提升測試質(zhì)量的關(guān)鍵是如何發(fā)現(xiàn)更多的測試 workload。在早期我們大量依賴了 MySQL 和相關(guān)社區(qū)的集成測試，數(shù)量大概千萬級別，這個決定讓我們在快速迭代的同時保證質(zhì)量，但是即使這樣還是不夠的，我們也在從學(xué)術(shù)界尋求答案. 例如引入并通過官方的 Jepsen Test ，再例如通過 SQLfuzz 自動生成合法 SQL 的語句加入到測試集中。

總之，比起寫業(yè)務(wù)邏輯，在分布式環(huán)境下寫測試 + 寫測試框架花費的精力可能一點都不少，甚至可能多很多（如果就從代碼量來說，TiDB 的測試相關(guān)的代碼行數(shù)可能比內(nèi)核代碼行數(shù)多一個數(shù)量級），而且這是一個非常值得研究和投資的領(lǐng)域。另外一個問題是如何通過測試發(fā)現(xiàn)性能回退。我們的測試平臺中每天運行著一個名為 benchbot 的機器人，每天的回歸測試都會自動跑性能測試，對比每日的結(jié)果。這樣一來我們的工程師就能很快知道哪些變更導(dǎo)致了性能下降，以及得到一個長期性能變化趨勢。

3. eBPF

說完測試，另外一個相關(guān)的話題是 profiling 和分布式 tracing。tracing 看看 Google 的 Dapper 和開源實現(xiàn) OpenTracing 就大概能理解，所以，我重點聊聊 profiling。最近這幾年我關(guān)注的比較多的是 eBPF (extended BPF) 技術(shù)。想象下，過去我們?nèi)绻_發(fā)一個 TCP filter，要么就自己寫一個內(nèi)核驅(qū)動，要么就用 libpcap 之類的基于傳統(tǒng) BPF 的庫，而傳統(tǒng) BPF 只是針對包過濾這個場景設(shè)計的虛擬機，很難定制和擴展。

在這個背景下，eBPF 應(yīng)運而生，eBPF 引入了 JIT 和寄存器，將 BPF 的功能進(jìn)一步擴充，這背后的意義是，我們在內(nèi)核中有一個安全的、高性能的、基于事件的、支持 JIT 的字節(jié)碼的虛擬機！這其實極大地降低了拓展內(nèi)核能力的門檻，我們可以不用擔(dān)心在驅(qū)動中寫個異常把內(nèi)核搞崩，我們也可以將給 llvm 用的 clang 直接編譯成 eBPF 對象，社區(qū)還有類似 bcc 這樣的基于 Python 的實用工具集……

過去其實大家是從系統(tǒng)狀態(tài)監(jiān)控、防火墻這個角度認(rèn)識 eBPF 的。沒錯，性能監(jiān)控以及防火墻確實是目前 eBPF 的王牌場景，但是我大膽地預(yù)測未來不止于此，就像最近 Brendan Gregg 在他的 blog 里喊出的口號：BPF is a new type of software?？赡茉诓痪玫奈磥恚琫BPF 社區(qū)能誕生出更多好玩的東西，例如我們能不能用 eBPF 來做個超高性能的 web server？能不能做個 CDN 加速器？能不能用 BPF 來重定義操作系統(tǒng)的進(jìn)程調(diào)度？我喜歡 eBPF 的另一個重要原因是，第一次內(nèi)核應(yīng)用開發(fā)者可以無視內(nèi)核的類型和版本，只要內(nèi)核能夠運行 eBPF bytecode 就可以了，真正做到了一次編譯，各個內(nèi)核運行。所以有一種說法是 BPF is eating Linux，也不是沒有道理 。

PingCAP 也已經(jīng)默默地在 BPF 社區(qū)投入了很長時間，我們也將自己做的一些 bcc 工具開源了，詳情可以參考 pingcap/kdt  這個 repo。其中值得一提的是，我們的 bcc 工具之一 drsnoop 被 Brendan Gregg 的新書收錄了，也算是為社區(qū)做出了一點微小的貢獻(xiàn)。

上面聊的很多東西都是具體的技術(shù)，技術(shù)的落地離不開部署和運維，分布式系統(tǒng)的特性決定了維護(hù)的復(fù)雜度比單機系統(tǒng)大得多。在這個背景之下，我認(rèn)為解法可能是：不可變基礎(chǔ)設(shè)施。

云和容器的普及讓 infrastructure as code 的理念得以變成現(xiàn)實，通過描述式的語言來創(chuàng)建可重復(fù)的部署體驗，這樣可重用的描述其實很方便在開源社區(qū)共享，而且由于這些描述幾乎是和具體的云的實現(xiàn)無關(guān)，對于跨云部署和混合數(shù)據(jù)中心部署的場景很適合。有些部署工具甚至誕生出自己的生態(tài)系統(tǒng)，例如 Terraform / Chef / Ansible。有一種說法戲稱現(xiàn)在的運維工程師都是 yaml 語言工程師，其實很有道理的：人總是會出錯，且傳統(tǒng)的基于 shell 腳本的運維部署受環(huán)境影響太大，shell 天然也不是一個非常嚴(yán)謹(jǐn)?shù)恼Z言。描述意圖，讓機器去干事情，才是能 scale 的正道。

4. 作者介紹

黃東旭：分布式系統(tǒng)專家，架構(gòu)師，開源軟件作者。PingCAP 聯(lián)合創(chuàng)始人兼 CTO，知名開源項目 Codis / TiDB / TiKV 主要作者，曾就職于微軟亞洲研究院，網(wǎng)易有道及豌豆莢。2015 年創(chuàng)業(yè)，成立 PingCAP，致力于下一代開源分布式數(shù)據(jù)庫的研發(fā)工作，擅長分布式存儲系統(tǒng)設(shè)計與實現(xiàn)，高并發(fā)后端架構(gòu)設(shè)計。