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