分布式系統關注點(21)——構建「易測試」系統的“六脈神劍”

這篇是「分布式系統理論」系列的第20篇。提前預告一下，后面還有一篇文章，這個系列就結束了。

在之前，核心的概念都講的差不多了。前面Z哥帶你已經聊過了「數據一致性」、「高可用」、「易擴展」、「高性能」主題下的一些實踐思路。

這篇講怎么構建一個「易測試」的系統。

作為一位開發人員，可能一聽到測試就想關掉這篇文章了。那我只能說too young，too naive。

作為關注我這個號的“跨界者“們，你不能將自己的邊界劃的太清楚，特別在當下這個變化越來越快、適者生存的時代。要活的像“水”一樣，與所處的環境結合的更緊密。

除此之外，測試工作并不是單單測試人員的事，開發人員是不是編寫了一個易測試的系統也至關重要。

在Z哥我過去的幾年coding經驗中，總結了六點認為有助于構建出一個易測試的系統建議，在這里分享給你。

第一點，分層。分層其實除了之前聊到的「易擴展」之外，對于測試工作的進行也是有很大幫助，規模越大的系統越是如此。

腦子里想象一下，一條業務線好比一根管道，每一次的業務操作會經歷整根管道的流轉最終到達終點。

往往很多時候，其實我們已經定位到了問題可能產生的范圍，但是由于項目沒有做好分層，導致每一次的測試工作不得不“從頭開始”。這是多么痛苦的一件事。

做好分層只要記住一個概念就行，「高內聚低耦合」。具體可以參考之前的文章，文末放鏈接。

第二點，無狀態。前面的文章里說過，滿足無狀態的功能點意味著可以動態的進行擴容而不用考慮“狀態丟失”問題。其實同時它也支持了一種測試場景，就是「容量規劃」。

為了支撐業務的不斷發展以及不定期舉行的大型活動，我們需要清楚的知道，到底部署多少臺機器為宜。

當然，你也可以選擇拍腦袋的方式進行，盡量多加一些就好了。但這不是一個科學的方法，也容易造成更多的浪費。

進行容量規劃的過程就好比通過水龍頭裝水到一組杯子里。比如，你現在的要求是1分鐘裝入3L水，那么通過不斷的調整杯子的數量和大小，理想情況是剛剛好達到這個要求為宜。

如果此時支持無狀態，那么整個過程中水龍頭一直開著就好了，你只要專心調整杯子的數量和大小就行。做好無狀態具體也可以參考之前的文章，文末放鏈接。

第三點，避免硬編碼，盡量配置化。可能你一看到那些龐雜的配置項就頭疼，但是不得不說，配置對于測試工作的開展是有很大幫助的。

反而用“眼不見為凈”的方式，硬編碼到邏輯代碼中是“掩耳盜鈴”的辦法。

特別是以下這些用途的變量，盡量放到配置中去，否則每次配置的變更都需要重新打包編譯代碼，是多么麻煩的一件事情。

容量類的配置

次數類的配置

開關類的配置

時間類的配置

這些類型的配置之間的共同點是，沒有永遠正確、永遠合理的配置。你要根據你當前的需求，不斷的調整他們。

如果可以引入一個集中式的配置中心就更好了，這樣可以不用一個個登陸服務器去修改配置。

第四點，依賴注入。如果你平時經常編寫單元測試的話，對這個應該感受頗深。因為支持依賴注入的代碼，更容易編寫單元測試。

但它的價值還不止于此，隨著系統規模越來越大，對于直接在生產環境進行故障演練需求越迫切，因為這才足夠真實。

但是又要求不能對正常的業務數據產生影響，怎么做？那就只能單獨準備演練數據，然后寫入到單獨的數據庫中。

這個時候，依賴注入就起作用了。我們可以將載入數據源的地方設計成支持依賴注入的，如此一來，你就可以靈活的切換到不同的數據源，進行故障演練。

第五點，打日志。測試工作最終做的好不好，看的是數據，是結果。這就意味著，對一個系統要求是「可觀測」的。

一個系統的運行過程怎么來觀測呢？就是通過各個地方的打日志。

之前聽說過一個自嘲的段子，說我們中國程序員在硅谷為什么混的沒印度人好，就是因為沒人家日志打的多。說明我們很多時候都在靠“直覺”做事，但直覺會經常翻車～

怎么打好日志？主要就是2個事情，「梳理」和「歸類」。先梳理羅列一下各個打日志的地方，然后通過“目的”進行「歸類」。

比如你是想以應對方式來歸類的話，日志可以分為馬上處理，定期處理，定期關注，事后排查等等。

你想以重要程度來歸類的話，就是嚴重錯誤、錯誤、警告、普通信息等等。

記住，不要過分吝嗇你的磁盤空間，那點錢不值得你用更多排查問題的時間去換。

第六點，接口版本化，并且向前兼容。用戶規模越大的系統，越不能用一刀切的方式發布，需要像一滴水滴到紙上一樣，緩慢的進行蔓延，進行更新。這其實也是一種試探性的測試方式。

版本管理怎么進行呢？首先你得要有一個版本管理中心，管理著不同版本之間的依賴關系。比如以下這樣。

其次，你要有一個集中式的分發請求的地方。比如網關或者一些服務治理解決方案。

然后，在程序往下游系統發起請求的時候，將自己的版本號在消息頭中帶給網關或者服務治理框架。由他們通過上面的這個依賴關系表，路由到指定版本的服務節點上去。

除了這個之外，你的接口實現邏輯上還需要向前兼容，否則請求是路由過來了，處理不了還是白搭。

總結一下，今天沒有寫什么技術性的東西，主要就是一些思路上的東西。其實，哪怕你的程序不具有「易測試性」，并不會阻礙測試工作的進行。但這并不意味著，它不重要。

你不重視它，它也不重視你，更容易給你找麻煩。誰都不希望每天都在修bug，你說是吧？

分布式

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。