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

本文轉載自查看原文 2019-05-31 09:02 578 易測試/ 架構/ bug/ 易測試性/ 分布式系統/ 分布式

如果第二次看到我的文章，歡迎右側掃碼訂閱我喲~ 👉

每周五早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
...

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

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

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