一、背景

1. 痛點(diǎn)

在服務(wù)端推進(jìn)升級(jí)是一件比較困難的事情，面臨的困難點(diǎn)包含但不限于：

• 穩(wěn)定性風(fēng)險(xiǎn)：組件自身兼容性的問(wèn)題或不正確升級(jí)帶來(lái)的兼容性問(wèn)題，可能帶來(lái)線上穩(wěn)定性風(fēng)險(xiǎn)。
• 升級(jí)投入&成本：組件升級(jí)至少需要研發(fā)執(zhí)行升級(jí)、QA執(zhí)行測(cè)試，測(cè)試通過(guò)后再逐步灰度發(fā)布，直至全量發(fā)布。整個(gè)過(guò)程需要研發(fā)、QA投入一定的研發(fā)、測(cè)試、觀察的人力，單次升級(jí)時(shí)間至少以周為單位來(lái)計(jì)量。
• 升級(jí)推進(jìn)成本：因以上投入成本&穩(wěn)定性風(fēng)險(xiǎn)等其他因素影響，業(yè)務(wù)研發(fā)團(tuán)隊(duì)對(duì)組件的升級(jí)意愿較低。此外，升級(jí)進(jìn)度還受團(tuán)隊(duì)排期、研發(fā)排查&解決問(wèn)題的能力、多團(tuán)隊(duì)的協(xié)調(diào)參與、多角色的協(xié)調(diào)參與等因素影響。在大規(guī)模推進(jìn)升級(jí)時(shí)，需要投入大量的項(xiàng)目管理、協(xié)調(diào)成本。

2. 現(xiàn)狀

• 云音樂(lè)應(yīng)用規(guī)模大，且線性增長(zhǎng)：隨著微服務(wù)的發(fā)展，服務(wù)拆分細(xì)化，疊加云音樂(lè)各業(yè)務(wù)快速發(fā)展，云音樂(lè)僅服務(wù)端應(yīng)用總數(shù)早已突破千級(jí)，當(dāng)協(xié)調(diào)多個(gè)團(tuán)隊(duì)、千級(jí)別的應(yīng)用升級(jí)時(shí)，整個(gè)升級(jí)事項(xiàng)的投入是巨大的。
• Jar包風(fēng)險(xiǎn)治理率低：在目前架構(gòu)風(fēng)險(xiǎn)巡檢中，Jar包相關(guān)的風(fēng)險(xiǎn)因投入產(chǎn)出比低，其治理率在全部的風(fēng)險(xiǎn)治理中幾乎墊底。Jar包的穩(wěn)定性風(fēng)險(xiǎn)隱患隨著業(yè)務(wù)的發(fā)展而逐步增大。
• 新技術(shù)落地周期長(zhǎng)，多版本維護(hù)成本高：當(dāng)應(yīng)用規(guī)模相對(duì)較小時(shí)，我們可以針對(duì)少量應(yīng)用，執(zhí)行技術(shù)升級(jí)，但是當(dāng)應(yīng)用規(guī)模較大時(shí)，整體推進(jìn)升級(jí)的難度較大，新技術(shù)落地的周期較長(zhǎng)，在此過(guò)程中，多版本的維護(hù)成本高，帶來(lái)額外的人力消耗。

3. 作用

在貴州機(jī)房遷移的背景下，云音樂(lè)面臨著大批應(yīng)用升級(jí)的問(wèn)題，此前一次升級(jí)中，全部團(tuán)隊(duì)基本升級(jí)完，總體用了約1個(gè)多月的時(shí)間。對(duì)此，我們研發(fā)了自動(dòng)升級(jí)平臺(tái)，其核心解決升級(jí)自動(dòng)化的問(wèn)題。

• 在穩(wěn)定性上

通過(guò)大范圍的自動(dòng)化部署/測(cè)試真實(shí)應(yīng)用，提高組件的測(cè)試樣本覆蓋，提前發(fā)現(xiàn)并解決組件可能出現(xiàn)的兼容性、穩(wěn)定性等問(wèn)題。

自動(dòng)解決多組件升級(jí)的問(wèn)題，避免因不正確升級(jí)帶來(lái)兼容性、穩(wěn)定性問(wèn)題。

• 在升級(jí)投入&成本上

對(duì)于需變更代碼的升級(jí)，通過(guò)自動(dòng)升級(jí)工具，串聯(lián)自動(dòng)代碼修改、自動(dòng)測(cè)試環(huán)境部署、自動(dòng)CI驗(yàn)證，自動(dòng)幫助研發(fā)完成大部分的代碼修改以及驗(yàn)證工作。大部分情況下，無(wú)需測(cè)試介入，研發(fā)僅需合并代碼，執(zhí)行線上發(fā)布發(fā)布流程即可。

在升級(jí)推進(jìn)成本上

通過(guò)自動(dòng)升級(jí)平臺(tái)，支持對(duì)任務(wù)的分發(fā)、中斷、配置、信息收集等等，升級(jí)過(guò)程、進(jìn)度管控完全可視化，大部分升級(jí)工作可以閉環(huán)在中心化執(zhí)行，降低了多團(tuán)隊(duì)、多角色的協(xié)作成本。

4. 使用場(chǎng)景

• 場(chǎng)景1：技術(shù)架構(gòu)升級(jí)

通過(guò)自動(dòng)升級(jí)平臺(tái)，可以自動(dòng)化完成大范圍應(yīng)用的技術(shù)架構(gòu)升級(jí)。例如：JDK升級(jí)、貴州機(jī)房遷移升級(jí)等場(chǎng)景。

• 場(chǎng)景2：組件風(fēng)險(xiǎn)治理

當(dāng)組件存在風(fēng)險(xiǎn)時(shí)，可以借助自動(dòng)升級(jí)平臺(tái)，推進(jìn)完成風(fēng)險(xiǎn)治理。

• 場(chǎng)景3：組件/Agent 兼容性測(cè)試

新發(fā)布組件/Agent時(shí)，目前主要在指定的測(cè)試工程里進(jìn)行兼容性測(cè)試，覆蓋場(chǎng)景可能存在不足，可以借助自動(dòng)升級(jí)平臺(tái)完成大范圍的兼容性、穩(wěn)定性等測(cè)試。

二、技術(shù)實(shí)踐

1. 升級(jí)分類

升級(jí)分類因整體架構(gòu)的不同，升級(jí)可分為如下幾類：

圖片

• 組件升級(jí)

即傳統(tǒng)的Jar包升級(jí)，此種升級(jí)一般需要改動(dòng)業(yè)務(wù)代碼才能完成，也是目前整體占比最大的一類。

• Sidecar模式升級(jí)

• 邊車模式，組件與業(yè)務(wù)應(yīng)用解耦，組件側(cè)的升級(jí)變更無(wú)需業(yè)務(wù)代碼變更或僅需少量變更。例如：JavaAgent、ServiceMesh等方式。

什么是Sidecar模式

Sidecar 模式是一種常見(jiàn)的微服務(wù)架構(gòu)模式，它通過(guò)在主應(yīng)用程序旁邊部署一個(gè)輔助應(yīng)用程序（稱為 Sidecar），來(lái)擴(kuò)展主應(yīng)用程序的功能。Sidecar 模式允許您在應(yīng)用程序旁邊添加更多功能，而無(wú)需額外第三方組件配置或修改應(yīng)用程序代碼。

此文中，我們?nèi)「鼮閺V義的Sidecar定義，將JavaAgent等作為一個(gè)輔助應(yīng)用程序看待，也被視為Sidecar模式的一種實(shí)現(xiàn)方式。

Sidecar 模式優(yōu)勢(shì)&特點(diǎn)

• 可擴(kuò)展性：通過(guò)添加 Sidecar 應(yīng)用程序，可以輕松地?cái)U(kuò)展主應(yīng)用程序的功能。
• 靈活性：Sidecar 應(yīng)用程序可以獨(dú)立于主應(yīng)用程序進(jìn)行部署、升級(jí)和維護(hù)。
• 可重用性：Sidecar 應(yīng)用程序可以在多個(gè)主應(yīng)用程序之間共享，從而提高代碼重用率。

兩者的差異點(diǎn)和共同點(diǎn)

• 組件升級(jí)相較于Sidecar式升級(jí)，整體升級(jí)流程上會(huì)存在些許差異，但也存在較多重合流程節(jié)點(diǎn)。
• 組件升級(jí)和Sidecar式升級(jí)，均需要考慮整個(gè)升級(jí)流程中的穩(wěn)定性、兼容性、可維護(hù)性、升級(jí)規(guī)范性等問(wèn)題。

2. 能力全景圖

考慮到目前云音樂(lè)微服務(wù)架構(gòu)未全面推進(jìn)sidecar化，在貴州遷移中，主要涉及組件自動(dòng)升級(jí)，此文主要對(duì)組件自動(dòng)升級(jí)進(jìn)行詳細(xì)闡述，而Sidecar升級(jí)能力在未來(lái)規(guī)劃中。

這部分主要介紹一下組件自動(dòng)升級(jí)的能力全景，其包括底層通用能力、組件升級(jí)能力、升級(jí)任務(wù)等模塊的核心能力，整體如下圖所示：

能力全景圖.png

• 底層通用能力部分，我們主要基于Git、發(fā)布平臺(tái)、部署平臺(tái)、自動(dòng)化測(cè)試平臺(tái)、代碼分析&檢索平臺(tái)、線上監(jiān)控，構(gòu)建了底層的代碼變更、測(cè)試部署、測(cè)試驗(yàn)證、線上發(fā)布、結(jié)果檢測(cè)的能力。
• 組件升級(jí)能力部分，支持各類類型文件的變更。
• 在升級(jí)任務(wù)部分，我們基于自定義任務(wù)流編排和升級(jí)規(guī)則配置，支持自定義升級(jí)任務(wù)編排和多版本升級(jí)插件，以及多種維度的任務(wù)統(tǒng)計(jì)。
• 在使用場(chǎng)景上，自動(dòng)升級(jí)平臺(tái)可用于：JDK升級(jí)、技術(shù)架構(gòu)升級(jí)、組件風(fēng)險(xiǎn)治理、組件/Agent 兼容性測(cè)試等場(chǎng)景。

3. 底層通用能力&流程編排

目前主要有以下5大底層通用能力：

圖片

底層通用能力

• 升級(jí)變更。基于Git，實(shí)現(xiàn)分支創(chuàng)建/刪除、代碼提交/拉取、提交/關(guān)閉MergerRequest等能力。
• 測(cè)試部署。基于發(fā)布平臺(tái)、部署平臺(tái)、測(cè)試環(huán)境，實(shí)現(xiàn)測(cè)試環(huán)境創(chuàng)建、測(cè)試環(huán)境部署、資源釋放釋放/限流等能力。
• 測(cè)試驗(yàn)證。基于自動(dòng)化測(cè)試平臺(tái)、Sonar、部署平臺(tái)，實(shí)現(xiàn)代碼CI檢測(cè)、自動(dòng)化測(cè)試用例、部署驗(yàn)證等能力。
• 線上發(fā)布。基于發(fā)布平臺(tái)，實(shí)現(xiàn)灰度發(fā)布、發(fā)布流程標(biāo)準(zhǔn)化、Agent發(fā)布等能力。
• 結(jié)果檢測(cè)。基于代碼分析、線上監(jiān)控，實(shí)現(xiàn)代碼升級(jí)檢測(cè)、線上升級(jí)檢測(cè)、Agent升級(jí)檢測(cè)等能力。

以上通用能力在整合時(shí)，自動(dòng)升級(jí)平臺(tái)重點(diǎn)做了如下方面的設(shè)計(jì)

• 流程編排。為了適用不同場(chǎng)景的升級(jí)，自動(dòng)升級(jí)對(duì)以上通用能力進(jìn)行流程節(jié)點(diǎn)的細(xì)化，并支持編排。
• 資源釋放&限流。在大規(guī)模升級(jí)時(shí)，需要占用大量的資源進(jìn)行升級(jí)、部署、驗(yàn)證工作，為了避免對(duì)線上環(huán)境造成影響，自動(dòng)升級(jí)平臺(tái)對(duì)任務(wù)進(jìn)行了限流，并在測(cè)試驗(yàn)證通過(guò)時(shí)釋放部分資源、整個(gè)任務(wù)完成時(shí)，釋放全部資源。
• 冪等&衰減重試機(jī)制。若需對(duì)底層平臺(tái)進(jìn)行讀寫(xiě)輪詢操作，需要注意操作的冪等，并且衰減重試，避免產(chǎn)生臟數(shù)據(jù)或?qū)Φ讓悠脚_(tái)的請(qǐng)求壓力過(guò)大。
• 可觀測(cè)性設(shè)計(jì)。正常情況下的關(guān)鍵信息和異常情況下的異常信息，均需要詳細(xì)記錄，并可視化觀測(cè)，減少升級(jí)時(shí)的問(wèn)題排查成本。

4. 組件升級(jí)能力

4.1 必要性

以云音樂(lè)當(dāng)前的現(xiàn)狀來(lái)看，整體距離Sidecar升級(jí)（例：ServiceMesh、Agent、MultiClassloader）仍然相差較遠(yuǎn)，同時(shí)后續(xù)升級(jí)推進(jìn)JDK21、ServiceMesh也需要自動(dòng)升級(jí)平臺(tái)的協(xié)助。

即使有了Sidecar，大范圍業(yè)務(wù)代碼的修改也可能是無(wú)法避免，變更代碼式的自動(dòng)升級(jí)和不變更代碼的升級(jí)均需要，自動(dòng)化變更代碼的方式仍然是必須的基礎(chǔ)建設(shè)。

4.2 核心特性

• 中心化操作：圈選應(yīng)用后，根據(jù)升級(jí)任務(wù)配置，自動(dòng)創(chuàng)建Git分支、自動(dòng)創(chuàng)建測(cè)試環(huán)境并部署、驗(yàn)證。驗(yàn)證通過(guò)后，提交MergerRequest
• 團(tuán)隊(duì)研發(fā)操作：合并MergerRequest，在devops發(fā)布平臺(tái)走發(fā)布流程
• 中心化操作：驗(yàn)證各個(gè)應(yīng)用的Master分支升級(jí)情況、線上部署情況

4.3 能力介紹

組件自動(dòng)升級(jí)插件基于OpenRewrite做了二次開(kāi)發(fā)。這里簡(jiǎn)要介紹一下OpenRewrite：

• OpenRewrite支持大規(guī)模分布式源代碼重構(gòu)，以進(jìn)行框架遷移、漏洞補(bǔ)丁和API遷移。
• OpenRewrite基于 Lossless Semantic Trees (LST)，來(lái)實(shí)現(xiàn)代碼的變更。

LST.png

• 目前除支持對(duì)普通Java項(xiàng)目中的java、props、properties、xml、pom.xml，也支持Spring、Micronaut、Quarkus、Jakarta、JDK17、JDK21的升級(jí)。
• 支持對(duì)變更的明細(xì)的觀測(cè)&記錄。

4.4 升級(jí)流程

圖片

組件升級(jí)默認(rèn)流程.png

以下為升級(jí)流程介紹，在此過(guò)程中加入了升級(jí)穩(wěn)定性、兼容性保障的設(shè)計(jì)

• 創(chuàng)建代碼分支。

拉取新代碼分支：不污染Master分支，不影響研發(fā)流程。

• 版本升級(jí)。

• 分支升級(jí)。在新的代碼分支，調(diào)用升級(jí)插件，實(shí)現(xiàn)升級(jí)

• 分支驗(yàn)證。再次驗(yàn)證分支升級(jí)的結(jié)果，避免升級(jí)錯(cuò)誤。

• 測(cè)試部署節(jié)點(diǎn)。

• 會(huì)對(duì)各團(tuán)隊(duì)創(chuàng)建升級(jí)任務(wù)單，同時(shí)提前打通上線流程。

• 創(chuàng)建新的測(cè)試環(huán)境，并檢查是否部署成功。確保不影響研發(fā)流程的同時(shí)，驗(yàn)證升級(jí)結(jié)果。

• 測(cè)試驗(yàn)證節(jié)點(diǎn)。

• 觸發(fā)自動(dòng)化測(cè)試用例并驗(yàn)證。驗(yàn)證業(yè)務(wù)邏輯是否正常。維護(hù)自動(dòng)化測(cè)試用例是QA側(cè)的日常工作，若不存在自動(dòng)化測(cè)試用例，流程會(huì)卡住，可通知QA側(cè)進(jìn)行維護(hù)，或自行測(cè)試。

• 代碼CI驗(yàn)證。驗(yàn)證代碼CI正確。

• 此節(jié)點(diǎn)下，每步的執(zhí)行結(jié)果無(wú)論是否成功，均需直接釋放測(cè)試集群，避免在大批量升級(jí)時(shí)，占用過(guò)多的測(cè)試機(jī)器資源。當(dāng)執(zhí)行不成功時(shí)，需要將異常日志完整保存，方便問(wèn)題排查。

• 代碼合并

• 當(dāng)前置所有節(jié)點(diǎn)通過(guò)后，可以認(rèn)為自動(dòng)升級(jí)已經(jīng)成功完成了：升級(jí)、部署、驗(yàn)證的工作，此時(shí)會(huì)自動(dòng)發(fā)起代碼合并請(qǐng)求。

• 業(yè)務(wù)研發(fā)在Review后，將代碼合并至Master分支

• 合并檢測(cè)

• 系統(tǒng)會(huì)持續(xù)離線檢測(cè)Master分支的組件依賴情況，從而檢測(cè)是否完成升級(jí)

• 線上檢測(cè)

• 系統(tǒng)會(huì)持續(xù)離線檢測(cè)線上機(jī)器的組件依賴情況，從而檢測(cè)是否完成升級(jí)并已上線。

• 釋放資源

• 當(dāng)所有檢測(cè)通過(guò)后，認(rèn)為該升級(jí)任務(wù)已完成，會(huì)執(zhí)行各節(jié)點(diǎn)的釋放資源方法，釋放資源。例如：刪除代碼分支、再次檢查并釋放機(jī)器資源等。

除此之外，在每次大規(guī)模升級(jí)前，會(huì)先對(duì)指定范圍內(nèi)的應(yīng)用提前預(yù)升級(jí)，從而提前摸查該次升級(jí)中的兼容性、穩(wěn)定性問(wèn)題。進(jìn)而保障升級(jí)的準(zhǔn)確性、升級(jí)推進(jìn)時(shí)的效率。

以下為系統(tǒng)實(shí)現(xiàn)示例圖：

系統(tǒng)示例圖

點(diǎn)擊應(yīng)用名，可查看該升級(jí)任務(wù)中各個(gè)流程節(jié)點(diǎn)的詳情數(shù)據(jù)。詳情數(shù)據(jù)包括成功情況、變更明細(xì)、失敗日志、失敗原因、重試間隔、最大重試次數(shù)、當(dāng)前重試次數(shù)、研發(fā)操作指引，以及一些基礎(chǔ)信息展示等。以下為系統(tǒng)示例圖：

系統(tǒng)實(shí)現(xiàn)示例圖2.png

5. 任務(wù)編排&非功能性設(shè)計(jì)

為了適用不同場(chǎng)景的升級(jí)，自動(dòng)升級(jí)對(duì)通用能力進(jìn)行流程節(jié)點(diǎn)的細(xì)化，并支持編排，整體能力如下圖所示：

圖片

自定義流程編排.png

在任務(wù)編排中，我們重點(diǎn)做了如下設(shè)計(jì)：

• 支持任務(wù)編排。通過(guò)自定義配置實(shí)現(xiàn)節(jié)點(diǎn)順序編排。
• 穩(wěn)定性設(shè)計(jì)

冪等執(zhí)行。消息可能存在重復(fù)消費(fèi)，因此必須支持冪等消費(fèi)。

資源釋放&限流。在大規(guī)模升級(jí)時(shí)，需要占用大量的資源進(jìn)行升級(jí)、部署、驗(yàn)證工作，為了避免對(duì)線上環(huán)境造成影響，自動(dòng)升級(jí)平臺(tái)對(duì)任務(wù)進(jìn)行了限流，并在測(cè)試驗(yàn)證通過(guò)時(shí)釋放部分資源、整個(gè)任務(wù)完成時(shí)，釋放全部資源。

• 支持按異常類型自定義重試策略。因在升級(jí)、部署驗(yàn)證過(guò)程中，可能會(huì)出現(xiàn)各種異常導(dǎo)致不成功，自動(dòng)升級(jí)平臺(tái)支持按照不同的異常類型來(lái)自定義重試策略，包括：重試間隔時(shí)間、最大重試次數(shù)。
• 基于MQ的消息通知機(jī)制，進(jìn)行任務(wù)節(jié)點(diǎn)的自動(dòng)流轉(zhuǎn)、任務(wù)路由、執(zhí)行異步化。
• 過(guò)程信息、異常信息可視化。因任務(wù)依賴的系統(tǒng)/組件較多，對(duì)于過(guò)程信息、異常信息需要記錄并可視化，降低任務(wù)的理解成本、問(wèn)題排查成本。
• 擴(kuò)展性設(shè)計(jì)。每個(gè)流程節(jié)點(diǎn)均支持異步的通知擴(kuò)展，以及同步的前置/后置Hook調(diào)用。單個(gè)流程節(jié)點(diǎn)分為5個(gè)階段：前置處理、前置hook、處理邏輯、后置hook、后置處理。每個(gè)階段均可獨(dú)立擴(kuò)展。

6. 任務(wù)管控&功能性設(shè)計(jì)

自動(dòng)升級(jí)平臺(tái)支持任務(wù)的管控、統(tǒng)計(jì)，能力如下圖所示

升級(jí)任務(wù).png

• 支持升級(jí)范圍的圈選。除支持按照應(yīng)用、團(tuán)隊(duì)圈選應(yīng)用外，還支持按照使用的Jar來(lái)圈選應(yīng)用（即：若應(yīng)用依賴某個(gè)Jar，則會(huì)自動(dòng)納入圈選）。
• 支持Jar包源&目標(biāo)版本的設(shè)置，精準(zhǔn)控制，避免升級(jí)錯(cuò)誤。以下為示例圖：

圖片

• 與自動(dòng)升級(jí)插件聯(lián)動(dòng)，支持升級(jí)規(guī)則的配置、升級(jí)插件版本的配置，支持不同的任務(wù)可執(zhí)行不同的升級(jí)規(guī)則。

圖片

• 支持升級(jí)任務(wù)編排。每個(gè)任務(wù)可獨(dú)立定制自己的任務(wù)流程。
• 支持任務(wù)的重試、跳過(guò)、關(guān)閉（包含資源釋放）、重新開(kāi)始等管控功能。
• 支持任務(wù)統(tǒng)計(jì)。

支持團(tuán)隊(duì)、應(yīng)用、任務(wù)階段維度的統(tǒng)計(jì)。

支持結(jié)果檢測(cè)統(tǒng)計(jì)。

支持執(zhí)行時(shí)長(zhǎng)、進(jìn)度維度的統(tǒng)計(jì)。

三、運(yùn)行數(shù)據(jù)

1. 支持事項(xiàng)

自動(dòng)升級(jí)平臺(tái)在近半年的時(shí)間里，支撐了貴州機(jī)房遷移測(cè)試環(huán)境演練升級(jí)、貴州機(jī)房遷移全量應(yīng)用升級(jí)、網(wǎng)關(guān)ZK拆分升級(jí)三大事項(xiàng)。

2. 運(yùn)行數(shù)據(jù)

• 一次性升級(jí)成功率約50%。在小范圍、標(biāo)準(zhǔn)化的應(yīng)用升級(jí)任務(wù)中，一次性升級(jí)成功率較高，在貴州機(jī)房全量應(yīng)用升級(jí)中，一次性升級(jí)成功率約在50%左右。未能一次性升級(jí)成功的應(yīng)用，研發(fā)也可借助升級(jí)平臺(tái)進(jìn)行問(wèn)題排查&解決，提升升級(jí)效率。
• 貴州遷移約節(jié)省人日約500人日，效率提升約83%。自動(dòng)升級(jí)平臺(tái)按照1000個(gè)應(yīng)用且僅升級(jí)一次保守統(tǒng)計(jì)，總體節(jié)省人力約500人日，升級(jí)效率提升約83%

節(jié)約人力：0.6d（研發(fā)+QA升級(jí)并驗(yàn)證單個(gè)應(yīng)用的平均耗時(shí)）  * 1000（應(yīng)用數(shù)） - 0.1d（自動(dòng)升級(jí)平臺(tái)升級(jí)并驗(yàn)證單個(gè)應(yīng)用的平均耗時(shí)） * 1000（應(yīng)用數(shù)） = 500d

效率提升 ：500/600 = 83%

• 數(shù)據(jù)對(duì)比如下：

圖片

數(shù)據(jù)對(duì)比.png

3. 問(wèn)題總結(jié)

對(duì)于未能一次性升級(jí)成功的原因，歸納主要有：

• 應(yīng)用組件版本過(guò)于陳舊，不符合升級(jí)最低版本要求。

因版本跨度較大，有太大兼容性問(wèn)題，自動(dòng)升級(jí)平臺(tái)不再予以支持。此部分應(yīng)用在貴州機(jī)房遷移過(guò)程中，也大都不再升級(jí)，而是由各業(yè)務(wù)自行遷移。

• 測(cè)試環(huán)境配置維護(hù)不足，自動(dòng)部署成功率低。

• 測(cè)試環(huán)境配置維護(hù)不足主要體現(xiàn)在：應(yīng)用的構(gòu)建、發(fā)布配置上，例如：健康檢查未配置、啟動(dòng)類設(shè)置錯(cuò)誤、內(nèi)存參數(shù)設(shè)置不合理、期望啟動(dòng)時(shí)間設(shè)置不合理等等。

• 組件依賴的使用方式多樣，也存在非標(biāo)準(zhǔn)的使用方式，升級(jí)工具覆蓋不足。

• 非腳手架的老應(yīng)用，組件依賴的的使用方式較為多樣，也存在非標(biāo)準(zhǔn)的使用方式。

• 升級(jí)工具基于OpenRewrite進(jìn)行二次開(kāi)發(fā)，從實(shí)際運(yùn)行的效果來(lái)看，OpenRewrite的一些開(kāi)源規(guī)則仍有可完善的空間。

• 新發(fā)布組件，因帶來(lái)新的依賴變更或依賴版本變更，帶來(lái)新的兼容性問(wèn)題。

• 例如：dts-sdk，在3.x除部分類路徑、類名發(fā)生變更外，又新引入了servlet-api、jsp-api、logback、commons-beanutils-core等Jar包依賴，與云音樂(lè)技術(shù)中心的應(yīng)用、組件存在普遍的不兼容問(wèn)題。

• 查詢的啟動(dòng)結(jié)果不準(zhǔn)確。

• 部分應(yīng)用可能因啟動(dòng)時(shí)間過(guò)長(zhǎng)、多次自動(dòng)重啟，導(dǎo)查詢的啟動(dòng)結(jié)果不準(zhǔn)確

• 少量應(yīng)用未接入自動(dòng)化測(cè)試用例。

四、未來(lái)展望

以下為能力規(guī)劃全景圖：

圖片

未來(lái)規(guī)劃全景圖.png

• 提升一次性升級(jí)成功率。
• 增加Sidecar升級(jí)能力的支持。
• 支持組件發(fā)布、版本管理、風(fēng)險(xiǎn)治理與自動(dòng)升級(jí)的聯(lián)動(dòng)。降低組件自身風(fēng)險(xiǎn)、同時(shí)提升組件側(cè)、治理側(cè)的效率，形成整體的閉環(huán)

圖片