一、前言 作為全鏈路數字化技術與服務提供商，袋鼠雲提供了從數據湖、大數據基礎平臺、離線開發、實時開發、數據服務、數據治理、指標管理、客戶數據洞察、數據孿生可視化等全產品體系的服務。 圍繞著“行業應用”及“通用應用”，袋鼠雲聚焦數智提供全維數字解決方案，幫助企業實現降本增效、快捷轉型，迄今為止袋鼠雲已 ...
一、前言
作為全鏈路數字化技術與服務提供商，袋鼠雲提供了從數據湖、大數據基礎平臺、離線開發、實時開發、數據服務、數據治理、指標管理、客戶數據洞察、數據孿生可視化等全產品體系的服務。
圍繞著“行業應用”及“通用應用”，袋鼠雲聚焦數智提供全維數字解決方案，幫助企業實現降本增效、快捷轉型，迄今為止袋鼠雲已服務超過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場景下，對於運維部署效率的小提升。無論從引擎層面，平臺層面或者是運維層面，袋鼠雲持續的產品迭代以及功能特定的增強都是為了面向客戶達到更好的運維，部署，以及平臺使用的最好的體驗。
袋鼠雲開源框架釘釘技術交流qun（30537511），歡迎對大數據開源項目有興趣的同學加入交流最新技術信息，開源項目庫地址：https://github.com/DTStack/Taier
