問題矛盾：ci測試中經常遇到整個流程時間太長，需求測試結果很急。
全自動ci集群測試縮短測試時間。
例如100個case，假設原來ci測試需要12小時（一台機器把所有的case跑一遍）
假設又n個機器，這裡為了說明具體點，我們舉例三個機器
ta, tb,tc
在三颱機器都能連線的server上建立case 池，靜態方式case.json狀態檔案，動態方式起個server服務與測試端通訊, 檔案解釋
1 : 表示有效可以被選中case還沒有機器選中去跑，優先分配
0：已經有機器選中，1的分配完才會被分配。
2：case結果已反饋給server， 不能再分配。
這裡主要是負責負載均衡，在test **測試端，使用者的測試環境一般都有個可用機器最大值，例如這裡我們設定為unit_number :10，根據使用者場景修改
舉例：ta：機器測試的時候首先分配 allcase/10
tb：機器測試的時候首先分配 allcase/10
tc：機器測試的時候首先分配 allcase/10
當第一輪跑完以後再次按照上面邏輯進分配，若1的分配完了，選值為0的case，等所有case的標誌為2，結束。
可以根據具體測試場景，進行演算法的調整。例如，按照歷史時間平均分配case，按照分類測試分配case，可以預先編輯一些分配規則，使用者根據需求進行選擇分配演算法。
由上面架構圖，我們可以看到每個測試客戶端都會與報告服務進行互動，當每個機器跑完當前分配的case後都會傳送給report service，新增gui,使用者可以實時看到case狀態，當所有case跑完後，生成統一的報告。
優點1：大大縮短ci / patch的驗證時間。
2：不同平台的機器可以彙總在乙個報告裡面對比分析
3：平台的cover度更高，減弱平台的影響
4：靈活配置，可單可多
5: 可以動態新增/刪除測試case
缺點：1：如果某個平台有問題，影響結果分析。
2：增加了乙個服務，需要確保服務的正常執行
設計草稿，如有建議，歡迎提出，共同進步。
微服務軟體架構設計
在軟體內部經過綜合各種因素考量 權衡，選擇特定的技術，將系統劃分為不同的部分並使用這些部分相互分工，彼此協作，為使用者提供需要的價值 軟體架構進化考慮的因素 傳統架構 單體架構 概念優勢 挑戰微服務架構 定義使用一套小服務來開發單個應用的方式，每個服務執行在單獨的程序，一般採用輕量級的通訊機制互聯，...
微服務架構設計模式綜述
隨著微服務的大量應用，在實踐中也會遇到很多之前單體架構所沒有的問題，微服務架構設計模式也應運而生。架構方面的權威chris richardson先生從多個角度歸納了42個設計模式，我將其歸納整理如下表，以饗讀者。後面會陸續出關於微服務架構設計模式的文章，更加深入的闡述richardson先生關於微服...
架構設計之 微服務入門
微服務這幾年不可謂不火，很多技術團隊都開始在自己的專案上引入了微服務。一方面這些團隊確實很好的推動了微服務的應用和發展，另一方面也可以看到一些盲目追技術熱點的行為所帶來的危害，比如很多中小團隊對微服務的基礎知識只是做了很淺顯的了解就開始盲目的推動微服務的實施，最後導致了專案的失敗。微服務要想做好是乙...