一、前言

作為全鏈路數字化技術與服務提供商，袋鼠雲提供了從資料湖、大資料基礎平臺、離線開發、實時開發、資料服務、資料治理、指標管理、客戶資料洞察、資料孿生視覺化等全產品體系的服務。

圍繞著 “行業應用” 及 “通用應用”，袋鼠雲聚焦數智提供全維數字解決方案，幫助企業實現降本增效、快捷轉型，迄今為止袋鼠雲已服務超過 5000 家的客戶。

面對如此龐大的客戶，平臺需要不斷更新迭代，以適應最新的產品特性，給客戶呈現更完備的功能，以達到客戶使用平臺的極佳體驗效果。

為了高效部署和監控袋鼠雲平臺中的各個產品，袋鼠雲自研了新產品大資料基礎平臺 EasyMR，提供快速構建和運維大資料叢集的能力，幫助提升大資料平臺運維與互動能力。平臺層的程式碼在面向客戶升級部署時，需要定義標準化打包規範，以快速和標準化的輸出平臺層面程式碼的標準包，藉助於大資料基礎平臺 EasyMR，可進行一站式產品包服務的部署、升級、解除安裝、配置等操作，解放人工運維的成本。

在 ToB 的客戶環境下，我們需要考慮從產品功能迭代到運維出包再到部署的提效最佳化。面對大型客戶的場景，區域網化的部署必然涉及到平臺增量包的傳輸大小限制，特別是在不斷增量部署的情況下，客戶需要不斷稽核產品包，而又因為產品包過大而耗費大量時間，大大影響了平臺部署產品的效率

基於產品包記憶體過大影響平臺部署效率的問題，袋鼠雲技術團隊不斷探索實踐，從平臺對編譯策略的最佳化，結合袋鼠雲內部產品包的出包最佳化，來探討如何在增量策略下，更優的解決產品包的記憶體大小問題，以解決增量升級的效率性。

二、程式碼編譯最佳化策略

1、編譯

袋鼠雲平臺層程式碼使用 java 開發語言，基於 maven 的 module 進行各個平臺產品的模組劃分，平臺層關注的是程式碼層面功能性，產品的編譯包通常基於簡單的如:

編譯方式，透過內部的 maven-shard-plugin 外掛編譯 executable shard jar。

maven-shade-plugin 內含有大量的資源轉換器（Resource Transformers），可以透過追加的策略來避免因不版本相同屬性資源的覆蓋錯誤。

官方參考文件：

2、產品包

運維基於平臺編譯的可執行的 jar 包例如:

{project.name}-{project-version}-jar-with-dependency.jar

需要整合 shell 啟停指令碼和配置資源以及 sql 等輸出標準的適配 EasyMR 部署的標準 tar 包，大致的整個平臺編譯的策略如下圖：

透過上面的編譯到產品包的具體步驟，我們會發現，平臺層透過 maven-shade-plugin 編譯為一個 executable shard jar 的策略下，我們可以思考下面幾個問題：

• 漏洞修復

• 增量釋出包的 tar 包大小

• 平臺與 EasyMR 的直接聯通

● 漏洞修復問題

針對這個問題，目前的編譯策略無法解決，只能在面對客戶漏洞修復的場景下，將整體 shade jar 做整體產品部署包輸出，進行全量升級來解決。

● 增量釋出包的 tar 包大小問題

針對這個問題：透過編譯可執行 jar 包的策略，即依賴 jar 和平臺自身 jar 編譯為一個整體的 jar 包的策略是無法解決最小代價的增量升級一個單一 jar 的問題，該問題勢必會導致在 toB 客戶升級場景下的增量 jar 升級的傳包大小的問題。實際上在增量升級的策略下，對於不變的 jar 包無需做升級替換，對可變的 jar 包才需要做增量升級替換。

● 平臺與 EasyMR 的直接聯通的問題

目前平臺基於 EasyMR 部署的策略下，還需要透過運維層去出標準的產品包，這個內部無形增加了開發到部署的能力，未來平臺會基於 EasyMR 的標準打包規範，直接能夠聯通 EMR 做標準產品 tar 的產品包編譯。

本文主要針對目前平臺的第一個問題，即透過拆分平臺產品層面的的自身 jar 和第三方依賴 jar 的策略來解決。

三、最佳化策略設計原則

1、規範目錄

基於拆分各個平臺自身的 jar 和第三方依賴的 jar 的原則，我們可以約定平臺層輸出的編譯包的制定統一路徑，以便運維統一路徑下的產品包的輸出。

規範化的編譯指定目錄，將對於的平臺服務層面的配置檔案、指令碼、依賴等相關的核心內容進行目錄拆解，這個也是平臺層面去統一抽離編譯目錄的核心部分。

2、平臺編譯

基於規範化的編譯目錄的制定，我們透過 assembly maven:

( )

做指定依賴包的隔離，最終透過 java -cp CLASSPATH 類載入器載入路徑策略將對應的不同隔離 jar 載入到類載入器中。例如：

3、增量策略

全量包策略下，目錄下的 lib 和 dtstack 都需要載入到對應的 classpath 下。

下面分析在增量出包的前提下，一種基於專案為緯度產品出包策略：

即：基於客戶 A 出增量包場景下，對於下次的增量升級策略下，我們可以透過 MD5 增量比對上次系統出包的 lib/dtstack 依賴的 md5 值，增量打包變更 / 新增的 jar 包。

基於增量打包的策略能更細粒度的對於升級包的大小和增量升級的維護，需要注意的是，系統運維出包需要維護當前內部 jar 包的 md5 值，以作為下次增量產品包輸出的依據。

四、總結

基於規範編譯目錄到平臺編譯策略的小最佳化小改造，再到從增量的角度去探討增量包的出包策略，我們可以均衡的抽離出平臺自研的 jar 包和平臺依賴的 jar 包。

基於此我們能夠為未來更細粒度的升級和部署運維袋鼠雲平臺產品打下基礎，同時也是在 toB 場景下，對於運維部署效率的小提升。無論從引擎層面，平臺層面或者是運維層面，袋鼠雲持續的產品迭代以及功能特定的增強都是為了面向客戶達到更好的運維，部署，以及平臺使用的最好的體驗。

袋鼠雲開源框架釘釘技術交流群（30537511），歡迎對大資料開源專案有興趣的同學加入交流最新技術資訊，開源專案庫地址：