实践：微服务版本升级步骤以及maven仓库相关概念

进行微服务开发的时候，上层服务依赖于下层的服务的api，比如适配属于上层服务，用户属于下层服务。

例子:

上层服务

<!--订单管理微服务api依赖-->
<dependency>
    <groupId>com.jn.server</groupId>
    <artifactId>order-mgmt-service-api</artifactId>
    <version>1.0.20-SNAPSHOT</version>
</dependency>

下层服务

<artifactId>order-mgmt-service-parent</artifactId>
<version>1.0.20-SNAPSHOT</version>

这样子下层服务中写了相关api并发布后，在上层服务就可以引用到下层的服务。

开发指南：

本地:
我们在开发的过程中也应该先写好下层的api,然后将api进行本地install，这个时候本地仓库就有了这个版本的依赖包(api包)，我们在上层服务中将maven中依赖的服务的api版本改成相对应的版本，刷新maven,这个时候本地上层服务里面就正确引入了最小的包。

测试站:
当将我们的代码合到测试站的时候，我们都是从下层开始合并，比如先合用户并重新部署，这个时候如果直接启动适配会部署失败，因为这个时候适配里面对应的用户maven依赖找不到(是去远程仓库中找的)，所以得先发布用户最新的api,再部署适配，就会成功。

还有一种情况是，当我们在开发的成功中修复bug的时候也修改了api,而且这个bug的跟着之前的迭代上线，这个时候用户的版本已经更新了，适配依赖不到，但是在测试站我们又不能将版本降级，这个时候我们要想的是，修改之前那个版本的api,因此，在合并修改的业务代码之后，需要将本地/开发分支修改为之前的版本，并且发布到远程仓库，这个时候测试站适配能调到我们修改的最新api,但是版本还是之前那个。

本地仓库与远程仓库

Maven 仓库可以分为 2 个大类：

本地仓库
远程仓库

当 Maven 根据坐标寻找构件时，它会首先查看本地仓库，若本地仓库存在此构件，则直接使用；若本地仓库不存在此构件，Maven 就会去远程仓库查找，若发现所需的构件后，则下载到本地仓库使用。如果本地仓库和远程仓库都没有所需的构件，则 Maven 就会报错。

远程仓库还可以分为 3 个小类：中央仓库、私服、其他公共仓库。

中央仓库是由 Maven 社区提供的一种特殊的远程仓库，它包含了绝大多数流行的开源构件。在默认情况下，当本地仓库没有 Maven 所需的构件时，会首先尝试从中央仓库下载。
私服是一种特殊的远程仓库，它通常设立在局域网内，用来代理所有外部的远程仓库。它的好处是可以节省带宽，比外部的远程仓库更加稳定。
除了中央仓库和私服外，还有很多其他公共仓库，例如 JBoss Maven 库，Java.net Maven 库等等。Maven 仓库的分类如下图

![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/68c45d4dcd684ac182bb4db037b2b1b5.png

本地仓库

Maven 本地仓库实际上就是本地计算机上的一个目录（文件夹），它会在第一次执行 Maven 命令时被创建。

Maven 本地仓库可以储存本地所有项目所需的构件。当 Maven 项目第一次进行构建时，会自动从远程仓库搜索依赖项，并将其下载到本地仓库中。当项目再进行构建时，会直接从本地仓库搜索依赖项并引用，而不会再次向远程仓库获取。

Maven 本地仓库默认地址为 C:%USER_HOME%.m2\repository ，但出于某些原因（例如 C 盘空间不够），我们通常会重新自定义本地仓库的位置。这时需要修改 %MAVEN_HOME%\conf 目录下的 settings.xml 文件，通过 localRepository 元素定义另一个本地仓库地址，例如：

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
   http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <localRepository>D:/myRepository/repository</localRepository>
</settings>