管理java版本号_微服务项目中如何管理依赖版本号？

本文是微服务项目代码组织形式三部曲中的第三篇，也是最后一篇，通过这三篇文章，相信大家对于如果组织微服务中的代码已经有了一个基本认知，前面两篇分别是：

微服务项目搭建，到底要不要聚合工程？

在微服务项目中，Maven 真的适合管理公共代码库吗？

第三篇相对来说要简单一些，本来没打算写，但是上周有个小伙伴问了我一个 Maven 问题，然后我就发现有的小伙伴对聚合工程的认知还是不到位，因此才有了这篇文章，想和大家再聊聊聚合工程的问题。

1.微服务架构

理论上的微服务架构和实际应用的微服务，往往会有一些差异。

理论上，在微服务架构中，各个独立的微服务可以是各种语言，像我们使用的 Eureka 注册中心，就是支持多种语言的，这样可以充分发挥各种语言的优势。如果是这样，就没有必要从项目整体上进行版本管理了，也管不了。

但是在实际操作中，考虑到团队的技术栈，现有的技术生态等因素，大部分情况下，我们可能并不会在项目中掺杂其他语言进来，比如就是用 Java 开发，相信大部分小伙伴都是这么做的。

既然统一都使用 Java 语言开发，那一个需求就随之浮出水面，就是项目依赖统一管理。

这个问题其实不是绝对的。

大型的微服务项目分属不同的团队开发，每个团队维护好自己的项目，然后通过 RPC 或者 HTTP 的方式互相之间进行交互，这种情况下，版本号也可以交由各个团队自行维护，这样版本升级的时候，就不必一起升级，可以各个团队独自完成