一、前言
作為全鏈路數字化技術與服務提供商，袋鼠云提供了從資料湖、大資料基礎平臺、離線開發、實時開發、資料服務、資料治理、指標管理、客戶資料洞察、資料孿生可視化等全產品體系的服務，
圍繞著“行業應用”及“通用應用”，袋鼠云聚焦數智提供全維數字解決方案，幫助企業實作降本增效、快捷轉型，迄今為止袋鼠云已服務超過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值，以作為下次增量產品包輸出的依據，
四、總結
基于規范編譯目錄到平臺編譯策略的小優化小改造，再到從增量的角度去探討增量包的出包策略，我們可以均衡的抽離出平臺自研的jar包和平臺依賴的jar包，
基于此我們能夠為未來更細粒度的升級和部署運維袋鼠云平臺產品打下基礎，同時也是在toB場景下，對于運維部署效率的小提升，無論從引擎層面，平臺層面或者是運維層面，袋鼠云持續的產品迭代以及功能特定的增強都是為了面向客戶達到更好的運維，部署，以及平臺使用的最好的體驗，
袋鼠云開源框架釘釘技術交流qun（30537511），歡迎對大資料開源專案有興趣的同學加入交流最新技術資訊，開源專案庫地址：https://github.com/DTStack/Taier
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/521900.html
標籤：大數據
上一篇：我應該檢查[NSApplicationsharedApplication]以獲取零回報嗎？
下一篇：索引