簡介： 本文通過梳理項目環境生命週期內創建、部署、重啓、刪除等任務的特點後，去除了流程引擎對消息的依賴，使用分佈式分片任務，分佈式鎖實現任務的分佈式運行。通過使用工廠模式，責任鏈模式，以及領域驅動設計的思路對流程引擎進行重構。最終實現在環境數量翻數百倍以上的情況下，日常以及預發環境平均創建成功率達到 99% 以上，單個環境創建時間由數百秒以上降低至 100秒 以下。工單量每秒並行執行翻近百倍的情況下，系統異常率低於 1% ，單次任務執行時間均值降低 8x%。
引言
項目環境是集團研發同學聯調測試必不可少的平臺型工具之一，其環境申請與釋放動態靈活，環境間流量相互隔離，在開發和上線前的個人自測以及全鏈路聯調場景下有着不可替代的重要作用。一個穩定易用的項目環境能極大地提高一線研發同學的測試體驗，通過對環境簡化抽象、屏蔽基礎設施和微服務複雜性，爲業務提供穩定可靠、簡單易用的測試環境。
項目環境作爲與變更或某個項目的生命週期保持一致的靈活環境，相較於固定環境（如主幹，預發，正式）有着不同的特質，其環境申請和釋放與變更生命週期綁定，部署和重啓更是其中的高頻操作。隨着項目環境覆蓋範圍的推開，在每天開發高峯期時期，每秒同時運行的工單量（環境創建、部署、重啓、刪除等）最高能到數千餘次。這爲項目環境本身的穩定性提出了極高的要求。
在項目環境建設初期，每一次創建、刪除、部署等工單主要通過單機執行，通過內部流程引擎發送消息以及定時任務推動狀態流轉。在實踐過程中隨着工單量的上漲逐漸出現了任務重複運行，任務無跡象消失，任務猝死等問題。而研發流程的改造和推進也給項目環境提出了更高要求，但是以上問題的出現限制了項目環境承載更大範圍使用的可能性。
本文通過梳理項目環境生命週期內創建、部署、重啓、刪除等任務的特點後，去除了流程引擎對消息的依賴，使用分佈式分片任務，分佈式鎖實現任務的分佈式運行。通過使用工廠模式，責任鏈模式，以及領域驅動設計的思路對流程引擎進行重構。最終實現在環境數量翻數百倍以上的情況下，日常以及預發環境平均創建成功率達到 99% 以上，單個環境創建時間由數百秒以上降低至 100秒 以下。工單量每秒並行執行翻近百倍的情況下，系統異常率低於 1% ，單次任務執行時間均值降低 8x%。
技術實踐
文章架構
現狀
1. 流程梳理
環境創建部署等流程如下所示，研發同學創建變更後項目環境會自動開始創建流程，非雲原生應用在環境創建完成後便開始異步申請機器資源，等待資源擴容完成後，會自動開始部署流程。雲原生應用會在部署過程中生產資源。項目環境資源生產完成後建立隔離標與機器的映射關係，即打標流程。三種工單（創建、部署、重啓）的核心流程如下圖所示：
2. 任務特點
可以看到上述三類任務有着兩個顯著特點：
- 任務間有順序
- 單個任務爲異步進行
異步任務需要在條件滿足後纔會觸發下一個任務的執行，這是一個典型的流水線模型，所以我們內部將推動任務流轉的模型稱爲流程引擎
3. 任務處理現狀
異步任務由用戶觸發創建，定時任務會定時調用異步任務判斷同步結果，任務完成後會通過消息推動任務間流轉。
3.1 任務猝死
當異步任務在運行過程中拋出非預期的異常會導致任務直接猝死，由於沒有發送任務完成的消息，任務間流轉所依賴的消息丟失就導致流程引擎無法推動下一個任務運行。
3.2 任務處理單機瓶頸
環境創建、部署、重啓都屬於不可重入任務，如果被定時任務被分佈式調用，會導致任務被重複執行導致資源浪費，工單報錯等無法預期的任務。而單機調度就導致項目環境大部分的機器被閒置，出現一核有難、八核圍觀的狀況。
3.3 任務重複執行
任務量的增多還會導致任務被重複執行。爲了更快的推動任務執行，定時任務的運行間隔必須設置的足夠短。但是隨着任務量的急劇增多，定時任務單機處理會導致當前批次處理的任務在下一次定時任務被調度時仍未執行，從而導致任務被重複執行。
優化之路
1. 任務猝死優化
在流程推進過程中任意一個非預期異常都會導致任務戛然而止，在用戶看來就是環境創建無機器，不部署，流水線不展示，隔離不生效等。首先對當前流程引擎的流程架構進行了初步梳理，如下圖所示（可以不看，僅做展示）
1.1 架構升級-領域模型（DDD）
欲重構先架構，通過整理梳理髮現，整個流程引擎可以分爲四大部分，
- 觸發流程創建的 GroupEnv(項目環境) 實體
- 流程操作的 AppRunningEnv(應用環境) 實體
- 保存流程信息的 Operation 實體
- 推動流程運行的 TaskEngine(流程引擎) 實體
根據抽取出來的四個實體，重新總結繪製了相互間的依賴關係圖，將分散在各處的部署，刪除，重啓等依賴關係收斂到各自的 Domain 中，並抽取出四個能力：創建，提交運行，操作以及更新狀態。
1.2 流程引擎重構
1.2.1 執行器統一接口
可以發現，子任務的執行過程可以分爲兩個部分
（1）執行操作
（2）同步結果
其中執行操作需要拿到子任務的初始執行結果。同步結果操作需要同步外部系統的狀態到項目環境並更新子任務結果。所以可以將這兩個能力抽象到一個接口中，即Taskexecutor。對於不同的子任務調用不同的executor。
1.2.2 使用工廠方法分拆執行器
針對不同操作使用不同的執行器這個思路與工廠模式非常契合。所以可以將每一個子任務執行器都抽取爲一個單獨的類，通過操作類型以及階段從工廠類（ExecutorFactory）拿到對應的執行器執行對應的方法。
1.2.3 異常處理兜底
在流程引擎execSubTask以及handleSubTaskSyncResult兩個方法中做異常統一處理，規範執行器異常處理，在異常信息中攜帶第三方或己方處理結果並格式化後填充到異常信息中。
1.2.4 操作子任務狀態統一透出
在子任務執行器中構建統一的異常信息模板，並通過異常的形式透出給上層調用者。上層調用者不需要關注執行器中發生了什麼，只需要將異常信息落庫。
1.2.5 單元測試補齊
以流程引擎爲入口，以HTTPClient與mapper爲最大mock對象，實現全鏈路測試。
1.3 優化結果
重構後，極大地簡化了任務執行流程，去除了對metaQ的強依賴，流程引擎依賴定時任務觸發，實現異常兜底邏輯，單測全覆蓋。共刪除冗餘代碼2700行。流程引擎核心流程收斂至Domain。
2. 任務執行時間優化
此前定時任務通過SchedulerX隨機選擇一臺機器作爲worker，之後從db中查詢全部正在運行中的任務後逐一觸發運行。單worker執行導致其他機器一直處於閒置狀態。如何充分利用計算資源成爲解決任務運行速度的重點。
分佈式分片任務解決單機計算瓶頸
Schedulerx2.0提供了map模型，通過一個map方法就能將海量數據分佈式到多臺機器上分佈式執行，通過利用MapReduce能力，隨機選取一臺機器作爲master節點，將所有正在運行中的任務分批推送到包含該節點的worker中，逐一觸發運行。總結爲一下三個步驟：
- 取任務全集
- 任務分片
- 多機並行執行
經過優化，全量任務單次觸發的執行時間降低爲原來的1/n ，其中n爲機器數。流程引擎具備了橫向擴展的能力。
3. 重複執行優化
雖然增加了分佈式分片能力，但是worker節點仍然是單線程執行，單機串行執行仍然存在執行瓶頸。所以對於單個worker節點通過線程池增加了並行執行的能力，通過增加線程同步器保證單個節點在所有任務執行結束後才返回。
3.1 秒級調度解決重複執行
使用秒級別調度，等待所有worker的任務都執行完成後纔開始下一次調度。Schedulerx2.0的秒級任務具有高可靠的特性，如果某臺機器掛了，可以在30秒內在另一臺機器上重新拉起。任務執行時間進一步優化至1/(n*x)，x爲線程池線程數。
4. 多機忙等問題解決
使用分佈式分片任務+單機多線程+秒級任務，項目環境的任務基礎架構已經基本完工，但是在實際運行過程中仍然發現多機執行時間仍然很長。表現在用戶觸發任務執行後狀態需要等待幾秒後纔會向前流轉。
由於線程同步器以及秒級任務的雙重加持，整個分佈式分片任務的單次執行時間取決於本批任務中的執行時間最長的任務，這就導致很多worker在等待運行最長任務的worker執行後纔會被再次調度。
4.1 分佈式鎖解決多機忙等
使用線程同步器可以保證單個worker所有任務執行完成後纔會向主節點上報任務集執行完成的信息，在加快任務執行速度的同時解決了任務重複執行的問題，但是會造成執行完任務的worker等待的情況。
通過分析任務模型可以發現，AppRunningEnv（應用環境）是流程引擎執行的最小不可分原子，只需要保證單個環境不被重複操作，就可以去掉worker節點的線程同步器。解決方案就是分佈式鎖。
通過數據庫唯一鍵索引可以根據AppRunningEnv的環境Id建立唯一主鍵，通過在任務被調度時爭奪分佈式鎖，如果未拿到鎖，則直接跳過不執行。獲取到鎖後執行任務，在執行完成或者出現異常後釋放鎖。
爲防止佔有鎖的worker節點掛掉，導致任務無法被調度，在任務分片時，主節點會釋放所有過期的鎖，增加兜底能力。
結果
環境創建成功率
環境創建成功率從之前的隨機成功，到現在的環境創建成功率穩定在99%以上（排除雲原生應用後）
環境創建時間
在環境數量翻百倍的情況下，創建時間均值由300秒以上降低至100s以內。
任務執行異常率
工單量每秒並行執行n+情況下，系統異常率低於1%
單次任務執行時間
消除調用量尖峯，在工單量翻70倍的前提下, 最大執行時間下降爲原來的十六分之一。
原文鏈接：https://click.aliyun.com/m/1000361877/
本文爲阿里雲原創內容，未經允許不得轉載。