當前位置：首頁 > 科技 > 軟件

云音樂服務端大規模自動化升級實踐

來源：責編：時間：2024-07-19 16:34:20 562觀看

導讀一、背景1. 痛點在服務端推進升級是一件比較困難的事情，面臨的困難點包含但不限于：穩定性風險：組件自身兼容性的問題或不正確升級帶來的兼容性問題，可能帶來線上穩定性風險。升級投入&成本：組件升級至少需要研發執行升級、

一、背景

1. 痛點

在服務端推進升級是一件比較困難的事情，面臨的困難點包含但不限于：

穩定性風險：組件自身兼容性的問題或不正確升級帶來的兼容性問題，可能帶來線上穩定性風險。
升級投入&成本：組件升級至少需要研發執行升級、QA執行測試，測試通過后再逐步灰度發布，直至全量發布。整個過程需要研發、QA投入一定的研發、測試、觀察的人力，單次升級時間至少以周為單位來計量。
升級推進成本：因以上投入成本&穩定性風險等其他因素影響，業務研發團隊對組件的升級意愿較低。此外，升級進度還受團隊排期、研發排查&解決問題的能力、多團隊的協調參與、多角色的協調參與等因素影響。在大規模推進升級時，需要投入大量的項目管理、協調成本。

2. 現狀

云音樂應用規模大，且線性增長：隨著微服務的發展，服務拆分細化，疊加云音樂各業務快速發展，云音樂僅服務端應用總數早已突破千級，當協調多個團隊、千級別的應用升級時，整個升級事項的投入是巨大的。
Jar包風險治理率低：在目前架構風險巡檢中，Jar包相關的風險因投入產出比低，其治理率在全部的風險治理中幾乎墊底。Jar包的穩定性風險隱患隨著業務的發展而逐步增大。
新技術落地周期長，多版本維護成本高：當應用規模相對較小時，我們可以針對少量應用，執行技術升級，但是當應用規模較大時，整體推進升級的難度較大，新技術落地的周期較長，在此過程中，多版本的維護成本高，帶來額外的人力消耗。

3. 作用

在貴州機房遷移的背景下，云音樂面臨著大批應用升級的問題，此前一次升級中，全部團隊基本升級完，總體用了約1個多月的時間。對此，我們研發了自動升級平臺，其核心解決升級自動化的問題。

在穩定性上

通過大范圍的自動化部署/測試真實應用，提高組件的測試樣本覆蓋，提前發現并解決組件可能出現的兼容性、穩定性等問題。

自動解決多組件升級的問題，避免因不正確升級帶來兼容性、穩定性問題。

在升級投入&成本上

對于需變更代碼的升級，通過自動升級工具，串聯自動代碼修改、自動測試環境部署、自動CI驗證，自動幫助研發完成大部分的代碼修改以及驗證工作。大部分情況下，無需測試介入，研發僅需合并代碼，執行線上發布發布流程即可。

在升級推進成本上

通過自動升級平臺，支持對任務的分發、中斷、配置、信息收集等等，升級過程、進度管控完全可視化，大部分升級工作可以閉環在中心化執行，降低了多團隊、多角色的協作成本。

4. 使用場景

場景1：技術架構升級

通過自動升級平臺，可以自動化完成大范圍應用的技術架構升級。例如：JDK升級、貴州機房遷移升級等場景。

場景2：組件風險治理

當組件存在風險時，可以借助自動升級平臺，推進完成風險治理。

場景3：組件/Agent 兼容性測試

新發布組件/Agent時，目前主要在指定的測試工程里進行兼容性測試，覆蓋場景可能存在不足，可以借助自動升級平臺完成大范圍的兼容性、穩定性等測試。

二、技術實踐

1. 升級分類

升級分類因整體架構的不同，升級可分為如下幾類：

圖片

組件升級

即傳統的Jar包升級，此種升級一般需要改動業務代碼才能完成，也是目前整體占比最大的一類。

Sidecar模式升級
邊車模式，組件與業務應用解耦，組件側的升級變更無需業務代碼變更或僅需少量變更。例如：JavaAgent、ServiceMesh等方式。

什么是Sidecar模式

Sidecar 模式是一種常見的微服務架構模式，它通過在主應用程序旁邊部署一個輔助應用程序（稱為 Sidecar），來擴展主應用程序的功能。Sidecar 模式允許您在應用程序旁邊添加更多功能，而無需額外第三方組件配置或修改應用程序代碼。

此文中，我們取更為廣義的Sidecar定義，將JavaAgent等作為一個輔助應用程序看待，也被視為Sidecar模式的一種實現方式。

Sidecar 模式優勢&特點

可擴展性：通過添加 Sidecar 應用程序，可以輕松地擴展主應用程序的功能。
靈活性：Sidecar 應用程序可以獨立于主應用程序進行部署、升級和維護。
可重用性：Sidecar 應用程序可以在多個主應用程序之間共享，從而提高代碼重用率。

兩者的差異點和共同點

組件升級相較于Sidecar式升級，整體升級流程上會存在些許差異，但也存在較多重合流程節點。
組件升級和Sidecar式升級，均需要考慮整個升級流程中的穩定性、兼容性、可維護性、升級規范性等問題。

2. 能力全景圖

考慮到目前云音樂微服務架構未全面推進sidecar化，在貴州遷移中，主要涉及組件自動升級，此文主要對組件自動升級進行詳細闡述，而Sidecar升級能力在未來規劃中。

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

能力全景圖.png

底層通用能力部分，我們主要基于Git、發布平臺、部署平臺、自動化測試平臺、代碼分析&檢索平臺、線上監控，構建了底層的代碼變更、測試部署、測試驗證、線上發布、結果檢測的能力。
組件升級能力部分，支持各類類型文件的變更。
在升級任務部分，我們基于自定義任務流編排和升級規則配置，支持自定義升級任務編排和多版本升級插件，以及多種維度的任務統計。
在使用場景上，自動升級平臺可用于：JDK升級、技術架構升級、組件風險治理、組件/Agent 兼容性測試等場景。

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

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

圖片

底層通用能力

升級變更。基于Git，實現分支創建/刪除、代碼提交/拉取、提交/關閉MergerRequest等能力。
測試部署。基于發布平臺、部署平臺、測試環境，實現測試環境創建、測試環境部署、資源釋放釋放/限流等能力。
測試驗證。基于自動化測試平臺、Sonar、部署平臺，實現代碼CI檢測、自動化測試用例、部署驗證等能力。
線上發布。基于發布平臺，實現灰度發布、發布流程標準化、Agent發布等能力。
結果檢測。基于代碼分析、線上監控，實現代碼升級檢測、線上升級檢測、Agent升級檢測等能力。

以上通用能力在整合時，自動升級平臺重點做了如下方面的設計

流程編排。為了適用不同場景的升級，自動升級對以上通用能力進行流程節點的細化，并支持編排。
資源釋放&限流。在大規模升級時，需要占用大量的資源進行升級、部署、驗證工作，為了避免對線上環境造成影響，自動升級平臺對任務進行了限流，并在測試驗證通過時釋放部分資源、整個任務完成時，釋放全部資源。
冪等&衰減重試機制。若需對底層平臺進行讀寫輪詢操作，需要注意操作的冪等，并且衰減重試，避免產生臟數據或對底層平臺的請求壓力過大。
可觀測性設計。正常情況下的關鍵信息和異常情況下的異常信息，均需要詳細記錄，并可視化觀測，減少升級時的問題排查成本。

4. 組件升級能力

4.1 必要性

以云音樂當前的現狀來看，整體距離Sidecar升級（例：ServiceMesh、Agent、MultiClassloader）仍然相差較遠，同時后續升級推進JDK21、ServiceMesh也需要自動升級平臺的協助。

即使有了Sidecar，大范圍業務代碼的修改也可能是無法避免，變更代碼式的自動升級和不變更代碼的升級均需要，自動化變更代碼的方式仍然是必須的基礎建設。

4.2 核心特性

中心化操作：圈選應用后，根據升級任務配置，自動創建Git分支、自動創建測試環境并部署、驗證。驗證通過后，提交MergerRequest
團隊研發操作：合并MergerRequest，在devops發布平臺走發布流程
中心化操作：驗證各個應用的Master分支升級情況、線上部署情況

4.3 能力介紹

組件自動升級插件基于OpenRewrite做了二次開發。這里簡要介紹一下OpenRewrite：

OpenRewrite支持大規模分布式源代碼重構，以進行框架遷移、漏洞補丁和API遷移。
OpenRewrite基于 Lossless Semantic Trees (LST)，來實現代碼的變更。

LST.png

目前除支持對普通Java項目中的java、props、properties、xml、pom.xml，也支持Spring、Micronaut、Quarkus、Jakarta、JDK17、JDK21的升級。
支持對變更的明細的觀測&記錄。

4.4 升級流程

圖片

組件升級默認流程.png

以下為升級流程介紹，在此過程中加入了升級穩定性、兼容性保障的設計

創建代碼分支。

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

版本升級。
分支升級。在新的代碼分支，調用升級插件，實現升級
分支驗證。再次驗證分支升級的結果，避免升級錯誤。
測試部署節點。
會對各團隊創建升級任務單，同時提前打通上線流程。
創建新的測試環境，并檢查是否部署成功。確保不影響研發流程的同時，驗證升級結果。
測試驗證節點。
觸發自動化測試用例并驗證。驗證業務邏輯是否正常。維護自動化測試用例是QA側的日常工作，若不存在自動化測試用例，流程會卡住，可通知QA側進行維護，或自行測試。
代碼CI驗證。驗證代碼CI正確。
此節點下，每步的執行結果無論是否成功，均需直接釋放測試集群，避免在大批量升級時，占用過多的測試機器資源。當執行不成功時，需要將異常日志完整保存，方便問題排查。
代碼合并
當前置所有節點通過后，可以認為自動升級已經成功完成了：升級、部署、驗證的工作，此時會自動發起代碼合并請求。
業務研發在Review后，將代碼合并至Master分支
合并檢測
系統會持續離線檢測Master分支的組件依賴情況，從而檢測是否完成升級
線上檢測
系統會持續離線檢測線上機器的組件依賴情況，從而檢測是否完成升級并已上線。
釋放資源
當所有檢測通過后，認為該升級任務已完成，會執行各節點的釋放資源方法，釋放資源。例如：刪除代碼分支、再次檢查并釋放機器資源等。

除此之外，在每次大規模升級前，會先對指定范圍內的應用提前預升級，從而提前摸查該次升級中的兼容性、穩定性問題。進而保障升級的準確性、升級推進時的效率。

以下為系統實現示例圖：

系統示例圖

點擊應用名，可查看該升級任務中各個流程節點的詳情數據。詳情數據包括成功情況、變更明細、失敗日志、失敗原因、重試間隔、最大重試次數、當前重試次數、研發操作指引，以及一些基礎信息展示等。以下為系統示例圖：

系統實現示例圖2.png

5. 任務編排&非功能性設計

為了適用不同場景的升級，自動升級對通用能力進行流程節點的細化，并支持編排，整體能力如下圖所示：

圖片

自定義流程編排.png

在任務編排中，我們重點做了如下設計：

支持任務編排。通過自定義配置實現節點順序編排。
穩定性設計

冪等執行。消息可能存在重復消費，因此必須支持冪等消費。

資源釋放&限流。在大規模升級時，需要占用大量的資源進行升級、部署、驗證工作，為了避免對線上環境造成影響，自動升級平臺對任務進行了限流，并在測試驗證通過時釋放部分資源、整個任務完成時，釋放全部資源。

支持按異常類型自定義重試策略。因在升級、部署驗證過程中，可能會出現各種異常導致不成功，自動升級平臺支持按照不同的異常類型來自定義重試策略，包括：重試間隔時間、最大重試次數。
基于MQ的消息通知機制，進行任務節點的自動流轉、任務路由、執行異步化。
過程信息、異常信息可視化。因任務依賴的系統/組件較多，對于過程信息、異常信息需要記錄并可視化，降低任務的理解成本、問題排查成本。
擴展性設計。每個流程節點均支持異步的通知擴展，以及同步的前置/后置Hook調用。單個流程節點分為5個階段：前置處理、前置hook、處理邏輯、后置hook、后置處理。每個階段均可獨立擴展。

6. 任務管控&功能性設計

自動升級平臺支持任務的管控、統計，能力如下圖所示

升級任務.png

支持升級范圍的圈選。除支持按照應用、團隊圈選應用外，還支持按照使用的Jar來圈選應用（即：若應用依賴某個Jar，則會自動納入圈選）。
支持Jar包源&目標版本的設置，精準控制，避免升級錯誤。以下為示例圖：

圖片

與自動升級插件聯動，支持升級規則的配置、升級插件版本的配置，支持不同的任務可執行不同的升級規則。

圖片

支持升級任務編排。每個任務可獨立定制自己的任務流程。
支持任務的重試、跳過、關閉（包含資源釋放）、重新開始等管控功能。
支持任務統計。

支持團隊、應用、任務階段維度的統計。

支持結果檢測統計。

支持執行時長、進度維度的統計。

三、運行數據

1. 支持事項

自動升級平臺在近半年的時間里，支撐了貴州機房遷移測試環境演練升級、貴州機房遷移全量應用升級、網關ZK拆分升級三大事項。

2. 運行數據

一次性升級成功率約50%。在小范圍、標準化的應用升級任務中，一次性升級成功率較高，在貴州機房全量應用升級中，一次性升級成功率約在50%左右。未能一次性升級成功的應用，研發也可借助升級平臺進行問題排查&解決，提升升級效率。
貴州遷移約節省人日約500人日，效率提升約83%。自動升級平臺按照1000個應用且僅升級一次保守統計，總體節省人力約500人日，升級效率提升約83%

節約人力：0.6d（研發+QA升級并驗證單個應用的平均耗時） * 1000（應用數） - 0.1d（自動升級平臺升級并驗證單個應用的平均耗時） * 1000（應用數） = 500d

效率提升：500/600 = 83%

數據對比如下：

圖片

數據對比.png

3. 問題總結

對于未能一次性升級成功的原因，歸納主要有：

應用組件版本過于陳舊，不符合升級最低版本要求。

因版本跨度較大，有太大兼容性問題，自動升級平臺不再予以支持。此部分應用在貴州機房遷移過程中，也大都不再升級，而是由各業務自行遷移。

測試環境配置維護不足，自動部署成功率低。
測試環境配置維護不足主要體現在：應用的構建、發布配置上，例如：健康檢查未配置、啟動類設置錯誤、內存參數設置不合理、期望啟動時間設置不合理等等。
組件依賴的使用方式多樣，也存在非標準的使用方式，升級工具覆蓋不足。
非腳手架的老應用，組件依賴的的使用方式較為多樣，也存在非標準的使用方式。
升級工具基于OpenRewrite進行二次開發，從實際運行的效果來看，OpenRewrite的一些開源規則仍有可完善的空間。
新發布組件，因帶來新的依賴變更或依賴版本變更，帶來新的兼容性問題。
例如：dts-sdk，在3.x除部分類路徑、類名發生變更外，又新引入了servlet-api、jsp-api、logback、commons-beanutils-core等Jar包依賴，與云音樂技術中心的應用、組件存在普遍的不兼容問題。
查詢的啟動結果不準確。
部分應用可能因啟動時間過長、多次自動重啟，導查詢的啟動結果不準確
少量應用未接入自動化測試用例。

四、未來展望

以下為能力規劃全景圖：

圖片

未來規劃全景圖.png

提升一次性升級成功率。
增加Sidecar升級能力的支持。
支持組件發布、版本管理、風險治理與自動升級的聯動。降低組件自身風險、同時提升組件側、治理側的效率，形成整體的閉環

圖片

本文鏈接：http://www.tebozhan.com/showinfo-26-101848-0.html云音樂服務端大規模自動化升級實踐

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇：為什么 Next.js 不用 Vite 而要自造輪子 Turbopack？

下一篇： Vue 組件管理的新趨勢！以后可能不再需要組件庫了？

標簽：

熱門焦點

俄羅斯：將審查iPhone等外國公司設備保數據安全

iPhone和特斯拉都屬于在各自領域領頭羊的品牌，推出的產品也也都是數一數二的，但對于一些國家而言，它們的產品可靠性和安全性還是在限制范圍內。近日，俄羅斯聯邦通信、信息技術
紅魔電競平板評測：大屏幕硬實力

前言：三年的疫情因為要上網課的原因激活了平板市場，如今網課的時代已經過去，大家的生活都恢復到了正軌，這也就意味著，真正考驗平板電腦生存的環境來了。也就是面對著這種殘酷的
十個可以手動編寫的 JavaScript 數組 API

JavaScript 中有很多API，使用得當，會很方便，省力不少。你知道它的原理嗎? 今天這篇文章，我們將對它們進行一次小總結。現在開始吧。1.forEach()forEach()用于遍歷數組接收一參
一文搞定Java NIO，以及各種奇葩流

大家好，我是哪吒。很多朋友問我，如何才能學好IO流，對各種流的概念，云里霧里的，不求甚解。用到的時候，現百度，功能雖然實現了，但是為什么用這個？不知道。更別說效率問題了~下次再遇到，
消費結構調整丨巨頭低價博弈，拼多多還卷得動嗎？

來源：征探財經作者：陳香羽隨著流量紅利的退潮，電商的存量博弈越來越明顯。曾經主攻中高端與品質的淘寶天貓、京東重拾“低價”口號。而過去與他們錯位競爭的拼多多，靠
東方甄選單飛：有些鳥注定是關不住的

作者：彭寬鴻來源：華爾街科技眼&zwj;&zwj;&zwj;&zwj;&zwj;&zwj;&zwj;&zwj;&zwj;&zwj;東方甄選創始人俞敏洪帶隊的“7天甘肅行”直播活動已在近日順利收官。成立后一
重估百度丨大模型，能撐起百度的“今天”嗎?

自象限原創作者｜程心羅輯2023年之前，對于自己的“今天”，百度也很迷茫。“新業務到 2022 年底還是 0，希望 2023 年出來一個 1。”這是2022年底，李彥宏
滴滴違法違規被罰80.26億共存在16項違法事實

滴滴違法違規被罰80.26億存在16項違法事實開始于2121年7月，歷經一年時間，網絡安全審查辦公室對“滴滴出行”網絡安全審查終于有了一個暫時的結束。據“網信
最薄的14英寸游戲筆記本電腦 Alienware X14已可以購買

2022年1月份在國際消費電子展(CES2022)上首次亮相的Alienware新品——Alienware X14現在已經可以購買了，這款筆記本電腦被譽為世界上最薄的 14 英寸游戲筆

AVt天堂网手机版,亚洲va久久久噜噜噜久久4399,天天综合亚洲色在线精品,亚洲一级Av无码毛片久久精品

云音樂服務端大規模自動化升級實踐

一、背景

1. 痛點

2. 現狀

3. 作用

4. 使用場景

二、技術實踐

1. 升級分類

什么是Sidecar模式

2. 能力全景圖

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

4. 組件升級能力

4.1 必要性

4.2 核心特性

4.3 能力介紹

4.4 升級流程

5. 任務編排&非功能性設計

6. 任務管控&功能性設計

三、運行數據

1. 支持事項

2. 運行數據

3. 問題總結

四、未來展望

俄羅斯：將審查iPhone等外國公司設備保數據安全

紅魔電競平板評測：大屏幕硬實力

十個可以手動編寫的 JavaScript 數組 API

一文搞定Java NIO，以及各種奇葩流

消費結構調整丨巨頭低價博弈，拼多多還卷得動嗎？

東方甄選單飛：有些鳥注定是關不住的

重估百度丨大模型，能撐起百度的“今天”嗎?

滴滴違法違規被罰80.26億共存在16項違法事實

最薄的14英寸游戲筆記本電腦 Alienware X14已可以購買

最新推薦

猜你喜歡

熱門推薦

相關資訊