一、前言
作為全鍊路數字化技術與服務提供商，袋鼠雲提供了從資料湖、大資料基礎平台、離線開發、實時開發、資料服務、資料治理、名額管理、客戶資料洞察、資料孿生可視化等全産品體系的服務。
圍繞着 “行業應用” 及 “通用應用”，袋鼠雲聚焦數智提供全維數字解決方案，幫助企業實作降本增效、快捷轉型，迄今為止袋鼠雲已服務超過 5000 家的客戶。
面對如此龐大的客戶，平台需要不斷更新疊代，以适應最新的産品特性，給客戶呈現更完備的功能，以達到客戶使用平台的極佳體驗效果。
為了高效部署和監控袋鼠雲平台中的各個産品，袋鼠雲自研了新産品大資料基礎平台 EasyMR，提供快速建構和運維大資料叢集的能力，幫助提升大資料平台運維與互動能力。平台層的代碼在面向客戶更新部署時，需要定義标準化打包規範，以快速和标準化的輸出平台層面代碼的标準包，借助于大資料基礎平台 EasyMR，可進行一站式産品包服務的部署、更新、解除安裝、配置等操作，解放人工運維的成本。
在 ToB 的客戶環境下，我們需要考慮從産品功能疊代到運維出包再到部署的提效優化。面對大型客戶的場景，區域網路化的部署必然涉及到平台增量包的傳輸大小限制，特别是在不斷增量部署的情況下，客戶需要不斷稽核産品包，而又因為産品包過大而耗費大量時間，大大影響了平台部署産品的效率
基于産品包記憶體過大影響平台部署效率的問題，袋鼠雲技術團隊不斷探索實踐，從平台對編譯政策的優化，結合袋鼠雲内部産品包的出包優化，來探讨如何在增量政策下，更優的解決産品包的記憶體大小問題，以解決增量更新的效率性。
二、代碼編譯優化政策
1、編譯
袋鼠雲平台層代碼使用 java 開發語言，基于 maven 的 module 進行各個平台産品的子產品劃分，平台層關注的是代碼層面功能性，産品的編譯包通常基于簡單的如:
編譯方式，通過内部的 maven-shard-plugin 插件編譯 executable shard jar。
maven-shade-plugin 内含有大量的資源轉換器（Resource Transformers），可以通過追加的政策來避免因不版本相同屬性資源的覆寫錯誤。
官方參考文檔：
https://maven.apache.org/plugins-archives/maven-shade-plugin-3.3.0/examples/resource-transformers.html#AppendingTransformer
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:
(https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/examples/single/including-and-excluding-artifacts.html)
做指定依賴包的隔離，最終通過 java -cp CLASSPATH 類加載器加載路徑政策将對應的不同隔離 jar 加載到類加載器中。例如：
3、增量政策
全量包政策下，目錄下的 lib 和 dtstack 都需要加載到對應的 classpath 下。
下面分析在增量出包的前提下，一種基于項目為緯度産品出包政策：
即：基于客戶 A 出增量包場景下，對于下次的增量更新政策下，我們可以通過 MD5 增量比對上次系統出包的 lib/dtstack 依賴的 md5 值，增量打包變更 / 新增的 jar 包。
基于增量打包的政策能更細粒度的對于更新包的大小和增量更新的維護，需要注意的是，系統運維出包需要維護目前内部 jar 包的 md5 值，以作為下次增量産品包輸出的依據。