最近做springcloud的项目，有一些疑惑，记录一下，以后看

bpmh

已于 2024-06-06 22:28:41 修改

阅读量1.1k

点赞数 24

分类专栏： Java开发经验技巧文章标签： spring cloud spring 后端

于 2024-06-05 11:46:49 首次发布

本文链接：https://blog.csdn.net/lyj15012351173/article/details/139468338

版权

Java开发经验技巧专栏收录该内容

13 篇文章 0 订阅

订阅专栏

一.springcloud子模块引入其他子模块的用途是什么，例如子模块base引入 user模块 :

<dependency>           
	<groupId>com.study.user</groupId>  
	<artifactId>spring-cloud-study-user</artifactId>      
	<version>${user.version}</version>    
</dependency>

在Spring Cloud项目中，一个常见的做法是将功能划分为多个子模块（也称为微服务），每个子模块负责一个特定的业务领域或功能。当不同的子模块之间需要共享代码、服务或数据时，它们之间就会存在依赖关系。

在一个多模块的Spring Cloud项目中，一个子模块引入另一个子模块作为依赖的用途可能包括：

代码重用：如果user模块包含了一些通用的业务逻辑、工具类、配置或其他可重用的代码，那么其他模块（如base模块）可以通过引入user模块的依赖来重用这些代码，避免重复编写相同的代码。
服务间调用：在微服务架构中，不同的服务之间需要进行通信和协作。base模块引入user模块的依赖可能是因为它需要调用user模块提供的服务接口。通过引入依赖，base模块可以获得对user模块服务接口的访问权限，从而可以发起远程调用。
数据共享：如果user模块负责处理用户相关的数据（如用户信息、权限等），而base模块需要访问这些数据，那么引入user模块的依赖可以使得base模块能够访问到user模块中的数据。当然，这通常不是通过直接依赖的方式来实现的，而是通过服务接口、数据库共享或其他数据共享机制来完成的。
配置继承：在某些情况下，base模块可能希望继承user模块中的某些配置（如数据库连接配置、消息队列配置等）。虽然这通常不是通过引入依赖来实现的（因为配置通常不会打包到JAR或WAR文件中），但如果base模块和user模块共享一些公共的配置模块或配置文件，那么引入user模块的依赖可能会间接地使得base模块能够访问到这些共享的配置。
版本管理：通过引入依赖并指定版本号（如${user.version}），可以方便地进行版本管理。当user模块的代码发生变更并发布新版本时，只需要在base模块的依赖中更新版本号，就可以自动获取到user模块的新版本代码。

需要注意的是，在微服务架构中，服务之间的依赖应该尽可能地保持松耦合。过度依赖其他服务可能会导致系统变得复杂且难以维护。因此，在引入其他子模块的依赖时，应该仔细考虑是否真的需要这个依赖，以及是否存在更好的替代方案。

二. 一个子模块引入另一个子模块作为依赖会产生什么问题?

一个子模块引入另一个子模块作为依赖时，可能会产生以下问题：

依赖冲突：
- 如果两个子模块引入了相同依赖的不同版本，就可能出现依赖冲突。这可能导致编译时错误、运行时异常或不可预期的行为。
- 例如，子模块A和子模块B都引入了同一个库的不同版本，当子模块C同时依赖A和B时，就可能面临版本冲突的问题。
循环依赖：
- 当两个或多个子模块相互依赖，形成了一个闭环时，就会出现循环依赖。这可能导致构建失败、启动失败或运行时错误。
- 循环依赖通常是由于设计不当或错误的依赖配置导致的。
项目复杂性增加：
- 引入额外的依赖会增加项目的复杂性，使得理解和维护项目变得更加困难。
- 过多的依赖可能导致构建速度变慢、测试覆盖率下降和部署复杂性增加。
可维护性降低：
- 依赖其他子模块可能导致代码的可维护性降低。当被依赖的子模块发生变更时，依赖它的子模块也需要进行相应的调整。
- 如果被依赖的子模块是频繁变动的，那么维护成本就会相应增加。
测试难度增加：
- 引入其他子模块作为依赖可能会增加测试的难度。在测试依赖的子模块时，可能需要考虑依赖模块的状态和行为。
- 这可能导致测试用例变得复杂，测试覆盖率下降。
部署和发布问题：
- 如果子模块之间的依赖关系没有正确配置，可能会导致在部署和发布时出现问题。
- 例如，如果一个子模块依赖另一个尚未发布或部署的子模块，那么就会导致构建失败或部署失败。
版本管理问题：
- 引入其他子模块作为依赖时，需要管理这些子模块的版本。如果没有正确管理版本，可能会导致版本冲突或不可预期的行为。
- 使用Maven或Gradle等构建工具可以帮助管理依赖和版本，但仍然需要仔细配置和维护。

为了避免这些问题，可以采取以下措施：

尽量减少不必要的依赖，保持子模块之间的松耦合关系。
合理使用Maven或Gradle等构建工具来管理依赖和版本。
定期进行依赖分析和清理，删除不必要的依赖和过时的版本。
使用服务化、事件驱动或消息队列等方式来降低服务之间的耦合度。
在设计和开发过程中，注意避免循环依赖和过度依赖的问题。

三.循环依赖的例子

制造一个循环依赖：在base子模块中引入starter子模块，同时在starter子模块中引入base子模块，编译工程报错：

[ERROR] [ERROR] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='com.study.base:dsy-cloud-study-base:3.0.00-SNAPSHOT'}' and 'Vertex{label='com.study.starter:dsy-cloud-study-starter:3.0.00-STANDARD'}' introduces to cycle in the graph com.study.starter:dsy-cloud-study-starter:3.0.00-STANDARD --> com.study.base:dsy-cloud-study-base:3.0.00-SNAPSHOT --> com.study.starter:dsy-cloud-study-starter:3.0.00-STANDARD @ 
[ERROR] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='com.study.base:dsy-cloud-study-base:3.0.00-SNAPSHOT'}' and 'Vertex{label='com.study.starter:dsy-cloud-study-starter:3.0.00-STANDARD'}' introduces to cycle in the graph com.study.starter:dsy-cloud-study-starter:3.0.00-STANDARD --> com.study.base:dsy-cloud-study-base:3.0.00-SNAPSHOT --> com.study.starter:dsy-cloud-study-starter:3.0.00-STANDARD -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectCycleException

这个错误表示Maven项目中存在循环依赖（Cyclic Dependency）的问题。具体地，com.study.base:dsy-cloud-study-base 和 com.study.starter:dsy-cloud-study-starter 这两个子模块相互依赖，形成了一个闭环。这会导致Maven无法正确地构建项目，因为它无法确定构建的顺序。

循环依赖是设计不良的标志，通常表示模块之间的职责划分不够清晰，或者模块之间的耦合度过高。为了解决这个问题，可以采取以下步骤：

识别循环依赖：
- 仔细查看pom.xml文件，找出com.study.base:dsy-cloud-study-base和com.study.starter:dsy-cloud-study-starter之间的依赖关系。
- 确定是哪个模块引入了另一个模块的依赖，并思考这种依赖是否必要。
重构代码：
- 如果循环依赖是由于不必要的依赖关系导致的，那么需要重构代码，将公共的代码或功能提取到一个新的模块中，或者通过接口、服务等方式来解耦。
- 如果循环依赖是因为模块之间的功能划分不合理，那么需要重新规划模块的功能边界，确保每个模块只负责一个清晰的业务领域。
更新pom.xml文件：
- 在重构代码后，更新pom.xml文件，移除不必要的依赖关系。
- 确保每个模块只依赖它真正需要的模块，并且没有循环依赖。
重新构建项目：
- 在解决了循环依赖问题后，重新运行Maven构建命令（如mvn clean install），检查项目是否能够成功构建。
使用Maven的依赖树功能：
- 可以使用Maven的mvn dependency:tree命令来查看项目的依赖树，这有助于更好地理解项目中的依赖关系，并发现潜在的循环依赖问题。
编写测试：
- 在重构代码和更新依赖后，确保编写足够的单元测试来验证代码更改是否正确。这可以帮助确保在解决循环依赖问题的同时，没有引入新的错误或问题。

四. 一个子模块引入另一个子模块作为依赖，那么启动这个子模块，被引用的模块的功能或类可以被使用吗?

当一个子模块（我们称之为模块A）引入了另一个子模块（我们称之为模块B）作为依赖时，在模块A中是可以使用模块B的功能或类的，前提是这些功能或类是对外暴露的（即不是私有的或包私有的）。

Maven 或 Gradle 这样的构建工具会处理依赖关系，确保在构建模块A时，模块B的编译产物（如JAR文件）会被包含在模块A的构建路径中。这样，当模块A启动或运行时，它可以访问并使用模块B中定义的功能或类。

这里有几个关键点需要注意：

依赖范围：在Maven或Gradle中，你可以指定依赖的范围（如compile、runtime、test等）。只有被包含在编译路径或运行路径中的依赖才能在运行时被使用。
可见性：模块B中的功能或类必须是对外可见的（即不是私有的或包私有的）。如果它们是私有的或包私有的，那么即使模块A引入了模块B作为依赖，也无法直接访问这些功能或类。
冲突解决：如果多个模块引入了同一个依赖的不同版本，构建工具可能会尝试解决这些冲突。然而，这可能会导致不可预期的行为或错误。因此，最好确保项目中的依赖版本是一致的。
模块之间的通信：如果模块A和模块B是通过微服务架构来组织的，那么仅仅通过Maven或Gradle引入依赖可能不足以实现模块之间的通信。你还需要配置服务注册与发现、API网关、负载均衡等基础设施来确保模块之间的通信是顺畅的。
测试：在引入依赖并编写代码后，你应该编写单元测试、集成测试等来验证你的代码能够正确地使用模块B的功能或类。这有助于确保你的代码是健壮的，并且能够在各种情况下正常工作。