一、前言
作为全链路数字化技术与服务提供商，袋鼠云提供了从数据湖、大数据基础平台、离线开发、实时开发、数据服务、数据治理、指标管理、客户数据洞察、数据孪生可视化等全产品体系的服务。
围绕着 “行业应用” 及 “通用应用”，袋鼠云聚焦数智提供全维数字解决方案，帮助企业实现降本增效、快捷转型，迄今为止袋鼠云已服务超过 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 场景下，对于运维部署效率的小提升。无论从引擎层面，平台层面或者是运维层面，袋鼠云持续的产品迭代以及功能特定的增强都是为了面向客户达到更好的运维，部署，以及平台使用的最好的体验。
