如何解决Java语言中的大规模Jar传递依赖地狱问题？

问：

我想解决的是一个大型组织（超过2,300名研发人员，超过4,000个内部Jars）中的传递依赖问题

我面临的情况是，当我引入任何 Jar 并想通过 RPC 访问其背后的服务时，这个 Jar 包会为我引入 1.5GB 的传递依赖。公司里有成千上万个这样的罐子。

我们如何在内部协调这些 Jar 包版本？所有 Java 项目都必须使用 Maven 并继承统一的 pom.xml。这个 pom.xml 定义了 4000 Jars 的最新版本，因此每个项目都使用最新版本来避免类冲突。

服务端的情况如下：一个服务端项目构建了一个超过 2GB 的部署产品，类路径下有超过 400,000 个 Java 类，其中 70% 的体积是由 proto 编译生成的类带来的。当我启动 spring boot 时，spring 将扫描完整的类路径。服务启动速度很慢，JVM 元空间会超过 1GB。

防腐设计很差。SDK 中的请求和响应将嵌套其他 Jar 包的 protobuf 类。那么这个 protobuf 类可能在其他 Jar 包中嵌套了 protobuf 类。这 4000 个 Jar 包中的大多数都是这样，形成了一个复杂的图形。

这是我必须解决的复杂情况。有没有人有什么好主意可以帮助我解决这个 Jar 地狱问题和 protobuf 问题？