在应用打包这一节文末中提到 Biz 包可以通过 mvn deploy 指令发布到远程 maven 仓库，类似发布普通 Jar 包。很自然想到，这样做的好处是应用可以通过依赖的形式引入其他应用生成的 Biz 包，就像引入普通的 Jar 包依赖。那么，在应用中引入其他应用生成的 Biz 包的目的什么？还有，Jarslink2.0 怎么动态装卸载 Biz 包？

回答上面两个问题，其实就是理解静态合并部署和动态合并部署的概念。

回答第一个问题，在应用中引入其他应用生成的 Biz 包目的是什么？

总结一下，即应用通过依赖的形式引入了其他应用生成的 Biz 包，最后由该应用打包生成的 Ark 包将会包含多个 Biz 包；执行该 Ark 包，将启动所有的 Biz 包，被称之为静态合并部署。

静态合并部署不依赖 Jarslink2.0，直接通过 SOFAArk 打包插件即可使用这一特性。

请注意，多个 Biz 包的启动顺序是可控的，每个 Biz 包在生成时，可以通过打包插件配置优先级，默认值为 100，优先级越高，值越小。优先级即决定了 Biz 包的启动顺序。

动态合并部署

相对于静态合并部署，Jarslink2.0 赋予了 SOFAArk 框架动态装卸载 Biz 包的能力。即在启动 Ark 包之后，如果 Ark 包中含有了 Jarslink2.0 插件，那么在运行时，Jarslink2.0 可以动态地接受指令控制 Biz 包的装载和卸载。Jarslink2.0 目前只接受 telnet 协议连接的方式进行指令的交互，端口为 1234。 启动 Ark 包后， 执行 即可进入 Jarslink2.0 交互界面。未来计划在 0.2.0 版本中支持 Http 请求的方式进行交互。

关于 Jarslink2.0 的指令模式将在专门的Jarslink 交互指令一节中介绍，下面我们着重描述如何使用 Jarslink2.0 实现应用的热更新。这里说的应用热更新是指，运行时使用新版本的应用替换老版本的应用，中间保证应用对外提供服务的连续性。

在合并部署时，Jarslink2.0 是通过 Biz 包名称和版本号作为唯一标识。Biz 包名称和版本号在插件打包过程中生成，记录在 MANIFEST.MF 文件中。Jarslink2.0 允许同时安装相同名称不同版本的 Biz 包，但是最多只有一个相同名称的 Biz 包对外提供服务。这里说的服务是指 Biz 包发布的 JVM 服务，关于 Biz 包 JVM 服务，请阅读 一节。当 Jarslink2.0 已经加载两个相同名称不同版本的 Biz 包时，可以通过命令切换对外提供服务的 Biz 版本，从而做到应用热更新，并保证服务的连续性。