如果第二次看到我的文章，歡迎右側掃碼訂閱我喲~ 👉
每週五早8點 按時送達。當然了，也會時不時加個餐～
這篇是「分佈式系統理論」系列的第20篇。提前預告一下，後面還有一篇文章，這個系列就結束了。
在之前，核心的概念都講的差不多了。前面Z哥帶你已經聊過了「數據一致性」、「高可用」、「易擴展」、「高性能」主題下的一些實踐思路。
這篇講怎麼構建一個「易測試」的系統。
作爲一位開發人員，可能一聽到測試就想關掉這篇文章了。那我只能說too young，too naive。
作爲關注我這個號的“跨界者“們，你不能將自己的邊界劃的太清楚，特別在當下這個變化越來越快、適者生存的時代。要活的像“水”一樣，與所處的環境結合的更緊密。
除此之外，測試工作並不是單單測試人員的事，開發人員是不是編寫了一個易測試的系統也至關重要。
在Z哥我過去的幾年coding經驗中，總結了六點認爲有助於構建出一個易測試的系統建議，在這裏分享給你。
第一點，分層。分層其實除了之前聊到的「易擴展」之外，對於測試工作的進行也是有很大幫助，規模越大的系統越是如此。
腦子裏想象一下，一條業務線好比一根管道，每一次的業務操作會經歷整根管道的流轉最終到達終點。
往往很多時候，其實我們已經定位到了問題可能產生的範圍，但是由於項目沒有做好分層，導致每一次的測試工作不得不“從頭開始”。這是多麼痛苦的一件事。
做好分層只要記住一個概念就行，「高內聚低耦合」。具體可以參考之前的文章，文末放鏈接。
第二點，無狀態。前面的文章裏說過，滿足無狀態的功能點意味着可以動態的進行擴容而不用考慮“狀態丟失”問題。其實同時它也支持了一種測試場景，就是「容量規劃」。
爲了支撐業務的不斷髮展以及不定期舉行的大型活動，我們需要清楚的知道，到底部署多少臺機器爲宜。
當然，你也可以選擇拍腦袋的方式進行，儘量多加一些就好了。但這不是一個科學的方法，也容易造成更多的浪費。
進行容量規劃的過程就好比通過水龍頭裝水到一組杯子裏。比如，你現在的要求是1分鐘裝入3L水，那麼通過不斷的調整杯子的數量和大小，理想情況是剛剛好達到這個要求爲宜。
如果此時支持無狀態，那麼整個過程中水龍頭一直開着就好了，你只要專心調整杯子的數量和大小就行。做好無狀態具體也可以參考之前的文章，文末放鏈接。
第三點，避免硬編碼，儘量配置化。可能你一看到那些龐雜的配置項就頭疼，但是不得不說，配置對於測試工作的開展是有很大幫助的。
反而用“眼不見爲淨”的方式，硬編碼到邏輯代碼中是“掩耳盜鈴”的辦法。
特別是以下這些用途的變量，儘量放到配置中去，否則每次配置的變更都需要重新打包編譯代碼，是多麼麻煩的一件事情。
-
容量類的配置
-
次數類的配置
-
開關類的配置
-
時間類的配置
這些類型的配置之間的共同點是，沒有永遠正確、永遠合理的配置。你要根據你當前的需求，不斷的調整他們。
如果可以引入一個集中式的配置中心就更好了，這樣可以不用一個個登陸服務器去修改配置。
第四點，依賴注入。如果你平時經常編寫單元測試的話，對這個應該感受頗深。因爲支持依賴注入的代碼，更容易編寫單元測試。
但它的價值還不止於此，隨着系統規模越來越大，對於直接在生產環境進行故障演練需求越迫切，因爲這才足夠真實。
但是又要求不能對正常的業務數據產生影響，怎麼做？那就只能單獨準備演練數據，然後寫入到單獨的數據庫中。
這個時候，依賴注入就起作用了。我們可以將載入數據源的地方設計成支持依賴注入的，如此一來，你就可以靈活的切換到不同的數據源，進行故障演練。
public interface IDataSource{ public string getName(int id); } public class DataSourceMysql implements IDataSource{ public string getName(int id){ // 從正常的數據庫裏中獲取數據。 } } public class DataSourceDrill implements IDataSource{ public string getName(int id){ // 從故障演練的數據庫裏中獲取數據。 } } public class UserBLL{ private IDataSource _database; public UserBLL(IDataSource database){ _database = database; } public void MethodA(int id){ // do something... var name = _database.getName(id); // do something... } } //以下是調用的時候 new UserBLL(new DataSourceMysql()).MethodA(id); //處理的是正常數據 new UserBLL(new DataSourceDrill()).MethodA(id); //處理的是演練數據
第五點，打日誌。測試工作最終做的好不好，看的是數據，是結果。這就意味着，對一個系統要求是「可觀測」的。
一個系統的運行過程怎麼來觀測呢？就是通過各個地方的打日誌。
之前聽說過一個自嘲的段子，說我們中國程序員在硅谷爲什麼混的沒印度人好，就是因爲沒人家日誌打的多。說明我們很多時候都在靠“直覺”做事，但直覺會經常翻車～
怎麼打好日誌？主要就是2個事情，「梳理」和「歸類」。先梳理羅列一下各個打日誌的地方，然後通過“目的”進行「歸類」。
比如你是想以應對方式來歸類的話，日誌可以分爲馬上處理，定期處理，定期關注，事後排查等等。
你想以重要程度來歸類的話，就是嚴重錯誤、錯誤、警告、普通信息等等。
【Fault】2019-05-24 09:01:07.669 | xxxxxx 【Error】2019-05-24 09:01:07.679 | xxxxxx 【Warning】2019-05-24 09:01:07.689 | xxxxxx 【Info】2019-05-24 09:01:07.699 | xxxxxx ...
記住，不要過分吝嗇你的磁盤空間，那點錢不值得你用更多排查問題的時間去換。
第六點，接口版本化，並且向前兼容。用戶規模越大的系統，越不能用一刀切的方式發佈，需要像一滴水滴到紙上一樣，緩慢的進行蔓延，進行更新。這其實也是一種試探性的測試方式。
版本管理怎麼進行呢？首先你得要有一個版本管理中心，管理着不同版本之間的依賴關係。比如以下這樣。
其次，你要有一個集中式的分發請求的地方。比如網關或者一些服務治理解決方案。
然後，在程序往下游系統發起請求的時候，將自己的版本號在消息頭中帶給網關或者服務治理框架。由他們通過上面的這個依賴關係表，路由到指定版本的服務節點上去。
除了這個之外，你的接口實現邏輯上還需要向前兼容，否則請求是路由過來了，處理不了還是白搭。
總結一下，今天沒有寫什麼技術性的東西，主要就是一些思路上的東西。其實，哪怕你的程序不具有「易測試性」，並不會阻礙測試工作的進行。但這並不意味着，它不重要。
你不重視它，它也不重視你，更容易給你找麻煩。誰都不希望每天都在修bug，你說是吧？
相關文章：
作者：Zachary
出處：https://www.cnblogs.com/Zachary-Fan/p/easytest.html
如果你喜歡這篇文章，可以點一下右下角的「推薦」。
這樣可以給我一點反饋。: )
謝謝你的舉手之勞。
既然看到這了，送我一個「贊同」吧，支持我的創作。
想更進一步和我一起玩耍，歡迎「搜索微信公號：跨界架構師」或者在「右側掃描」。
內容包括：架構設計丨分佈式系統丨產品丨運營丨個人深度思考。