源寶導讀：為了打通CI/CD環節，實現持續的端到端的交付能力，RDC平臺提供了在線化的更新服務，隨著業務量增長與場景的需要，我們對更新服務架構重新設計，實現了2.0版本。本文將介紹更新服務2.0的架構演進過程與實踐。

一、ERP的部署架構

? ? 在談更新服務之前我們先了解一下ERP現存的部署架構，ERP產品以建模平臺為底座，開發有成本、售樓、計劃、采招等產品及對應的二開項目，同時依賴配置中心、中臺服務等配套服務。依據客戶的不同規模提供不同的部署方案，部署方案的復雜程度決定了更新的過程的難易程度。在RDC接入更新服務之前，產品及二開團隊出包后需要聯系一線進行線下更包，架構的復雜程度越高，線下更新的代價越大。更新服務1.0的出現了解決這一痛點：一線人員通過訪問ERP站點更新鏈接即可跳轉到更新頁面實現一鍵更新。

? ? ERP部署架構如下圖所示：

二、更新服務1.0架構

? ? 應用層ERP產品如建模平臺、成本系統、售樓系統、計劃系統、采招系統及各種配套服務通過代理服務接入到RDC CD管道（Pipeline），代理服務對外輸出持續交付能力：

• 客戶在線狀態心跳監測

• 產品注冊上報

• 產品更新檢查

• 產品持續部署

? ? 那代理服務是如何做到這些的呢？

三、更新服務1.0設計

更新服務1.0更新包時序圖：

? ? 盡管1.0的更新服務完成了打通CD環節實現了端到端的持續交付但依然存在一些不足：

• 更新效率低；

• 擴展性 - 后期ERP代理服務不單是處理更新，還要能擴展處理其他業務，例如商城插件的安裝、卸載、更新。擴展性已經考慮了，只是缺乏插件的定義規范；

• 穩定性 - 主要表現在現有機制下，后去下一步執行步驟出錯（預先將下一步放在一個表）；

• 日志和異常 - 異常日志和異常出錯指引，日志的顯示要明晰；

• 設計到更新的表結構設計不合理：插件自身定義和插件步驟定義沒有分開，更新包狀態的維護。過程中會涉及到不少聯合查詢做業務的場景，互相依賴。原則：單實體職責單一，同時相應處理接口，職責也要單一；

• 代碼實現數據腳本式。

功能也存在不足：

• 獲取一條指令錯誤；

• 更新狀態掛起，一直是進行中，即不成功，也不失敗；

• 錯誤日志不明晰，出錯的情況下難以快速定位到出錯步驟；

• 包的更新狀態沒有維護，查詢時得實時從多個表中計算包的狀態，效率很低。

四、更新服務2.0架構

? ? 將代理服務重構，支持動態插件加載，解決擴展性不足，實現守護插件解決穩定性不足同時重新設計了日志的采集機制解決了日志記錄上的不足。
? ? 重構了更新邏輯解決更新性能及設計上的不足：

• 重新定義了插件的設計：解決1.0中未從代碼層面約定插件的定義問題；

• 解耦執行命令與更新業務**：**解決1.0中設計上擴展性不足的問題；

• 解耦更新插件對更新服務的強依賴：可實現一鍵離線更包解決一線線下更包時需要在服務器上進行手動蓋包、執行sql、元數據同步修改mysofverion等復雜高危操作的痛點；

• 解耦更新步驟與更新步驟控制邏輯：讓插件開發者只用關心插件本身的業務不用考慮負載等場景中如何對執行流程進行控制；

• 優化更新列表查詢慢問題；

• 重構更新服務數據庫設計及實現方案：解決1.0中表設計不合理及引發的更新性能問題；

• 重新設計了插件日志規范:解決1.0中日志設計的不足將業務日志與通用診斷日志進行區分，業務日志提供更友好的格式化日志呈現，詳細的診斷日志提供線上問題分析；

• 設計超時機制及補償機制：解決1.0中更新超時或狀態異常時導致更新狀態掛起的問題；

• 設計重試機制：提升更新成功率；

• 設計守護插件：提高代理服務自身的穩定性。

五、更新服務2.0設計

更新服務2.0更新包時序圖：

對比時序圖我們可以發現2.0在命令設計這塊有以下明顯區別：

1、命令設計不同：1.0一次更新過程按步驟拆分成若干步驟（如下載更新包、備份等）而2.0僅為一條命令從而減少了心跳的周期；

2、更新流程控制方式不同：1.0依據服務端運算并下發下一步的更新命令而2.0則在客戶端自行控制更新流程從而效率更高；

3、設計有補償機制：解決服務器狀態異常或執行掛起時修復執行狀態保證更新過程的穩定性避免過多的人工干預。

小結一下：

? ? 對比1.0的時序圖我們不難發現，2.0只需要一次心跳輪詢即可完成整個更新過程，而在1.0中每一步執行都依賴于心跳輪詢，負載環境更新時還需要依賴心跳輪詢機制保證每臺服務器執行步調一致且1.0的服務端還需要根據當前步驟執行結果計算出下一步需要分發出去的執行命令，而2.0服務端一次完成命令下發，客戶端根據命令及服務端提供的執行狀態自行完成更新過程所以2.0執行效率要更高，更新服務1.0單包平均更新時間約為3分鐘，更新服務2.0為50秒左右效率提升大約3倍以上詳見下表：

更新服務V2更新效率

六、寫在最后

? ? 更新服務2.0設計解決了1.0中暴露出來的一系列問題，更新效率也大幅提高，然而沒有最好的設計只有更合適的設計。目前更新服務2.0還有一些有待提升的地方，比如更新流程未實現逐步回滾，基于更新插件擴展其他業務插件尚不夠完善。展望未來更新插件將以更新插件核心框架作為更新底座，提供完善的流程控制邏輯和更新控制，各種更新業務插件以底座為依托實現自己更新業務，最終實現ERP全系產品的端到端高效交付流程。

------ END ------

作者簡介

王同學：?研發工程師，目前負責RDC平臺的設計與開發工作。

也許您還想看

研發協同平臺持續集成Jenkins作業設計演進

研發協同平臺持續交付之代理服務實踐

研發協同平臺持續集成2.0架構演進

鏈路追蹤在ERP系統中的應用實踐

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的研发协同平台持续交付2.0架构演进的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。