微服务项目中如何管理依赖版本号?

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

  1. 微服务项目搭建,到底要不要聚合工程?
  2. 在微服务项目中,Maven 真的适合管理公共代码库吗?

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

1.微服务架构

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

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

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

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

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

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

但是这种方式又可能会带来另外一个问题,就是依赖版本的碎片化,在经过 N 多次迭代之后,可能会存在两个项目所依赖的微服务版本差异非常大。

因此,在实际操作中,有的团队会倾向于将项目版本统一管理。

统一管理也很简单,就是搞一个 parent 就行了,但是有的小伙伴容易将这种 parent 和聚合工程搞混,因此松哥这里还是和大家稍微聊一下怎么统一管理项目版本号。

2.统一管理版本号

2.1 聚合工程

先来说一说聚合工程,这里我就不重新写代码了,以微人事(https://github.com/lenve/vhr)为例来和大家分享。

微人事项目的服务端就是一个聚合工程。

我们可以来看下 vhrserver 的 pom.xml 文件:

<parent>
    <artifactId>vhr</artifactId>
    <groupId>org.javaboy</groupId>
    <version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>vhrserver</artifactId>
<packaging>pom</packaging>
<modules>
    <module>vhr-mapper</module>
    <module>vhr-model</module>
    <module>vhr-service</module>
    <module>vhr-web</module>
</modules>

在这个聚合工程中,vhr-model 用来放实体类,vhr-mapper 用来放 Dao 层,vhr-server 用来放 Service 层,vhr-web 则是一个 Spring Boot 工程。

在聚合工程中,vhr-web 作为聚合工程的一部分,是无法独立打包的,因为它依赖 vhr-service,vhr-service 依赖 vhr-mapper ,而 vhr-mapper 则依赖 vhr-model。我们需要从 vhrserver 处打包,这样它会自动解决 module 之间的依赖问题。

单独给 vhr-web 打包会报如下错误:

从 vhrserver 处统一打包,结果如下:

可以看到,我们需要直接打包聚合工程,内部的依赖问题会自动解决。

有人可能会问,既然前面报 Could not find artifact org.javaboy:vhr-service:pom:1.0-SNAPSHOT 错误,那我先把 vhr-service install 到本地仓库,再去打包 vhr-web 行不行?

这个是不行的,因为这是聚合工程,不能这样做,只能从聚合工程处打包。

2.2 统一管理版本号

上面说的聚合工程虽然也能实现版本号的统一管理,但是我们不能在微服务中采用这种方式。

你想一个微服务系统,包含了很多子系统,例如商品管理、交易管理、物流管理等等,要是想给商品管理打包,你还得从聚合工程处打包,打完之后,其他微服务模块也生成了各自的包,这样效率太低了。

但是我们还想实现版本号的统一管理,该怎么办呢?创建父子工程即可。这种项目结构和聚合工程很像,但是不一样,很多小伙伴会搞混,所以这里我来给大家稍微演示一下。

首先我们定义一个普通的 Maven 工程作为父工程,我把 pom.xml 文件拎出来给大家参考下:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.3.0.RELEASE</version>
    <relativePath/>
</parent>
<packaging>pom</packaging>
<groupId>org.javaboy.vmall</groupId>
<artifactId>vmall</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
    <!--省略-->
</properties>
<dependencyManagement>
    <dependencies>
        <!--省略-->
    </dependencies>
</dependencyManagement>

大家可以看到,这个父工程本身也有一个 parent ,就是 Spring Boot 中的 parent。

这里的 packaging 依然是 pom,然后我们定义了 dependencyManagement,将一些不包含在 spring-boot-starter-parent 中的依赖版本进行统一管理。但是大家注意,这里没有 modules 节点,这是一个很大的不同。

接下来,我们创建其他微服务项目,在创建的过程中,可以采用平铺的方式,例如下面这样:

也可以做成有层次结构的父子形式,像下面这样:

两种方式都可以。

然后在各个微服务项目中,重新修改 parent 即可:

如此之后,我们就可以对各个微服务中的依赖版本进行统一管理了。

这种项目结构和聚合工程并不一样,这种项目打包,是可以独立打包的。

首先我们先将父工程 install 到本地仓库:

然后再去 install vmall-common 模块,最后给 vmall-app-manager 进行打包,注意,现在的 vmall-app-manager 可以独立打包,不需要从总的 parent 处进行统一打包。微服务项目中如果需要对项目版本进行统一管理,可以采用这种方式。

小伙伴们可以仔细品一品这种方式和聚合工程的差异。

3.小结

好啦,今天的内容比较简单,再结合前面已经发过的两篇文章,相信大家对于如何组织微服务项目的代码已经有一定的思路了。

如果小伙伴们觉得有收获,记得点个在看鼓励下松哥哦~

已标记关键词 清除标记
1、课程简介 Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。        在本套课程,我们将全面的讲解Spring Cloud技术栈, 从环境的部署到技术的应用,再到项目实战,让我们不仅是学习框架技术的使用,而且可以学习到使用Spring Cloud如何解决实际的问题。 Spring Cloud各个组件相互配合,合作支持了一套完整的服务架构。 - 注册心负责服务的注册与发现,很好将各服务连接起来 - 断路器负责监控服务之间的调用情况,连续多次失败进行熔断保护。 - API网关负责转发所有对外的请求和服务 - 配置心提供了统一的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息 - 链路追踪技术可以将所有的请求数据记录下来,方便我们进行后续分析 - 各个组件又提供了功能完善的dashboard监控平台,可以方便的监控各组件的运行状况 2、适应人群 有一定的Java基础,并且要有一定的web开发基础。 3、课程亮点        系统的学习Spring Cloud技术栈,由浅入深的讲解服务技术。涵盖了基础知识,原理剖析,组件使用,源码分析,优劣分析,替换方案等,以案例的形式讲解服务的种种问题和解决方案 l  服务的基础知识 n  软件架构的发展史 n  服务的核心知识(CAP,RPC等) l  注册心 n  Eureka搭建配置服务注册 n  Eureka服务端高可用集群 n  Eureka的原理和源码导读 n  Eureka替换方案Consul n  Consul下载安装&服务注册&高可用 l  服务发现与服务调用 n  Ribbon负载均衡基本使用&源码分析 n  Feign的使用与源码分析 n  Hystrix熔断(雪崩效应,Hystrix使用与原理分析) n  Hystrix替换方案Sentinel l  服务网关 n  Zuul网关使用&原理分析&源码分析 n  Zuul 1.x 版本的不足与替换方案 n  SpringCloud Gateway深入剖析 l  链路追踪 n  链路追踪的基础知识 n  Sleuth的介绍与使用 n  Sleuth与Zipkin的整合开发 l  配置心 n  SpringClond Config与bus 开发配置心 n  开源配置心Apollo 4、主讲内容 章节一: 1.     服务基础知识 2.     SpringCloud概述 3.     服务注册心Eureka 4.     Eureka的替换方案Consul 章节二: 1.     Ribbon实现客户端负载均衡 2.     基于Feign的服务调用 3.     服务熔断技术Hystrix 4.     Hystrix的替换方案Sentinel 章节三: 1.     服务网关Zuul的基本使用 2.     Zuul1.x 版本的不足和替换方案 3.     深入SpringCloud Gateway 4.     链路追踪Sleuth与Zipkin 章节四: 1.     SpringCloud Config的使用 2.     SpringCloud Config结合SpringCloud Bus完成动态配置更新 3.     开源配置心Apollo
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页