Koupleless 内核系列 | 一台机器内 Koupleless 模块数量的极限在哪里？

梁栎鹏（立蓬）

蚂蚁集团技术工程师

云原生领域工程师

就职于蚂蚁集团中间件团队，参与维护与建设蚂蚁 SOFAArk 和 Koupleless 开源项目，参与内部 SOFAServerless 产品的研发和实践。

本文  4873  字，预计阅读  12  分钟

本篇文章属于 Koupleless 进阶系列文章第三篇，默认读者对 Koupleless 的基础概念、能力都已经了解，如果还未了解过的可以查看官网（https://koupleless.io/）。

进阶系列一：Koupleless 模块化的优势与挑战&我们是如何应对挑战的

进阶系列二：Koupleless 单进程多应用如何解决兼容问题

在前面进阶系列的文章里，我们介绍了 Koupleless 模块化适用的一些场景，这里大都涉及把多个应用合并在一个基座里。大家可能会有一个问题：一台机器最多能安装多少个模块应用呢？为了帮助大家更好的理解 Koupleless 模块化的价值、评估生产上部署的策略，这篇文章我们就尝试回答下这个问题，并分析一个模块应用需要消耗多少资源，在日常迭代时需要考虑哪些问题。

模块数量的上限在哪里？

这个问题也可以换一种方式来问，那就是——一台机器最多能安装多少个模块应用？

如果使用的是静态合并部署，一个基座能安装的模块数量上限，在计算能力允许的前提下，主要取决于模块消耗的内存。根据进阶系列第一篇文章里的数据，一个模块在强制 gc 后消耗 30M 内存，包括堆内存和非堆内存，假如一个 4C8G 的机器，JVM 配置 6G 内存，预留2G 内存给运行器创建的一些临时对象，那么可以用于安装模块的内存空间大小为 4G，那么总共可以安装的模块数量 = 4000M / 30M =  133 个模块。

如果是动态合并部署，即：模块升级时无需重启基座，直接安装模块到正运行的基座上，也称为热部署方式。热部署方式除了需要考虑基座启动后可提供模块消耗的内存，还需要考虑每次热部署新版本后，在卸载老版本时候，老版本占用内存的回收情况，老版本内存是否能全部回收给新版本模块使用。根据实际观察验证，我们发现老版本的内存回收需要考虑这两方面：

• 堆内存：从 JVM 资源视角中，堆内存中旧版本模块的实例不再可达，可以通过 GC 回收给其他模块应用/基座应用继续使用。

• 非堆内存：Metaspace 的回收要求较高，需要满足三个条件“该类的所有的实例对象都已被 GC”、“该类没有在其他任何地方被引用”、“且该类的类加载器的实例已被GC”。在 koupleless 中，模块的每次安装都会产生一个模块实例，每个模块实例都由一个新的 ClassLoader 加载，由于该 ClassLoader 被 Spring ApplicationContext 等运行环境持有，无法彻底回收，导致整个模块实例的非堆内存基本无法回收。