微服务多模块冲突解决方法

最近开发一个半成品的社区商城小程序的项目。项目使用的是nacos微服务,使用过程中常常会模块依赖冲突。

如图所示:在订单成功之后我需要在订单支付回调中指定派送。而在派送员模块中需要调用查询订单等诸多方法 这时候就会出现maven模块依赖问题
如图所示:在订单成功之后我需要在订单支付回调中指定派送。而在派送员模块中需要调用查询订单等诸多方法 这时候就会出现maven模块依赖问题

后面再网上查问题时碰到的方案,以下内容部分转自:https://www.iteye.com/blog/hck-1728329l

很​多​时​候​随​着​项​目​的​膨​胀​,模​块​会​越​来​越​多​,如​果​设​计​上​ 稍​有​不​慎​就​会​出​现​模​块​之​间​相​互​依​赖​的​情​况​。​这​对​于​使​用​Maven的​用​户​是​比​较​痛​苦​的​,因​为​出​现​模​块​之​间​相​互​依​赖​的​话​在​构​建​的​时​候​就​会​失​败​,Maven通​常​要​先​编​译​被​依​赖​的​模​块​,如​果​出​现​相​互​依​赖​Maven就​不​知​道​该​怎​么​办​了​。​下​图​描​述​了​三​个​Maven模​块​相​互​依​赖​的​场​景​:
在这里插入图片描述
图​中​模​块​C依​赖​于​模​块​B,模​块​B依​赖​于​模​块​A,而​模​块​A又​依​赖​于​模​块​C,这​样​就​出​现​了​相​互​依​赖​情​况​,如​果​运​行​mvn compile会​出​现​如​下​错​误​:
[INFO] Scanning for projects… [ERROR] The projects in the reactor contain a cyclic reference: Edge between ‘Ve rtex{label=‘org.kuuyee.sample:module-C:1.0-SNAPSHOT’}’ and ‘Vertex{label=‘org.ku uyee.sample:module-B:1.0-SNAPSHOT’}’ introduces to cycle in the graph org.kuuyee .sample:module-B:1.0-SNAPSHOT --> org.kuuyee.sample:module-A:1.0-SNAPSHOT --> or g.kuuyee.sample:module-C:1.0-SNAPSHOT --> org.kuuyee.sample:module-B:1.0-SNAPSHO T -> [Help 1][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit ch.[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 rea d the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectCycleEx ception
使​用​build-helper-maven-plugin解​决​相​互​依​赖​的​问​题​我​的​解​决​办​法​就​是​先​把​相​互​依​赖​的​模​块​整​合​在​一​起​,相​当​于​把​这​些​模​块​合​并​成​一​个​单​独​的​模​块​统​一​编​译

在这里插入图片描述

这​样​就​产​生​了​一​个​合​并​模​块​D,我​们​把​它​当​做​一​个​辅​助​构​建​模​块​,然​后​让​A、​B、​C模​块​都​依​赖​于​D模​块​,这​样​的​话​就​可​以​成​功​编​译​A、​B和​C模​块​,

在这里插入图片描述
要​想​把​A、​B、​C三​个​模​块​整​合​在​一​起​编​译​,需​要​借​助​build-helper-maven-plugin插​件​,这​个​插​件​在​Maven构​建​周​期​提​供​一​些​辅​助​功​能​,下​面​列​出​插​件​的​提​供​的​功​能​列​表​: build-helper:add-source:添​加​更​多​的​构​建​源​码​目​录​ build-helper:add-test-source:添​加​更​多​的​测​试​源​码​目​录​ build-helper:add-resource:添​加​更​多​的​资​源​目​录​ build-helper:add-test-resource:添​加​更​多​的​测​试​资​源​目​录​ build-helper:attach-artifact:在​安​装​和​部​署​周​期​附​加​artifacts build-helper:maven-version:添​加​一​个​指​定​当​前​Maven版​本​的​属​性​ build-helper:parse-version:添​加​一​个​指​定​组​件​版​本​的​属​性​ build-helper:released-version:决​定​当​前​项​目​的​最​终​版​本​ build-helper:remove-project-artifact:从​本​地​资​源​库​中​移​除​项​目​的​artifacts build-helper:reserve-network-port:Reserve a list of random and unused network ports. 在​这​里​我​们​要​用​到​build-helper:add-source这​个​功​能​,将​模​块​A、​B、​C的​源​码​路​径​加​进​来​。​ 我​们​再​添​加​一​个​辅​助​模​块​D,在​辅​助​模​块​D中​使​用​build-helper-maven-plugin插​件​,然​后​让​模​块​A、​B、​C都​依​赖​于​辅​助​模​块​D,模​块​D的​POM模​型​如​下​: 例 1. 辅​助​模​块​D的​POM模​型​

找到灵感之后,在代码中做了如下的改造

在这里插入图片描述
新建中间模块depend,并且加了一个IOrderDeliverStatusService接口,接口内容如下:


/**
 * 配送员订单服务类
 *
 * @author BladeX
 * @since 2020-12-11
 */
public interface IOrderDeliverStatusService extends BaseService<OrderDeliver> {
	/**
	 * 派单
	 *
	 * @param orderSn
	 * @return
	 */
	boolean assignOrder(String orderSn);
}

定义了订单模块中需要调用的配送模块的方法。而后在deliver中新建实现类 继承service接口

@Service
public class OrderDeliverStatusServiceImpl extends BaseServiceImpl<OrderDeliverMapper, OrderDeliver>
	implements IOrderDeliverStatusService {
			@Override
			public boolean assignOrder(String orderSn) {
				//业务代码
			}
	}

order模块中直接引入depend依赖即可调用assignOrder方法

maven处理循环依赖

在多maven工程的项目里,如果工程间存在循环依赖,构建就会报错。本文介绍一下循环依赖要怎么处理

1、什么是循环依赖

如果工程A依赖工程B,工程B又依赖工程A,就会形成循环依赖。或者A依赖B,B依赖C,C依赖A,也是循环依赖
  
  总的来说,在画出工程依赖图之后,如果发现工程间的依赖连线形成了一个有向循环图,则说明有循环依赖的现象
  
  如果循环依赖发生在工程之间,则会影响构建,因为maven不知道应该先编译哪个工程。如果循环依赖发生在同一个工程的模块之间,虽然不影响编译,但是也是一种不好的实践,说明模块的设计有问题,应该避免
  
  如果在模块内部,有几个类互相调用的话,我觉得可能是正常的。比如观察者模式里面,Observer和Observable就是互相依赖的

2、怎么解决循环依赖

目前知道有2个办法可以解决
  
  第一个办法是用build-helper-maven-plugin插件来规避。比如A依赖B,B依赖C,C依赖A的情况。这个插件提供了一种规避措施,即临时地将工程A、B、C合并成一个中间工程,编译出临时的模块D。然后A、B、C再分别依赖临时模块D进行编译
  
  这种方法可以解决无法构建的问题,但是只是一个规避措施,工程的依赖关系依然是混乱的
  
  第二个办法是通过重构,从根本上消除循环依赖

3、如何重构

目前也知道2个重构的思路
  
  第一个办法是平移,比如A和B互相依赖,那么可以将B依赖A的那部分代码,移动到工程B中,这样一来,B就不需要继续依赖A,只要A依赖B就可以了,从而消除循环依赖
  
  第二个办法是下移,比如A和B互相依赖,同时它们都依赖C,那么可以将B和A相互依赖的那部分代码,移动到工程C里,这样一来,A和B相互之间都不依赖,只继续依赖C,也可以消除循环依赖
  
  这两种重构方式都是可行的,具体采用哪种方式要根据实际情况来判断。不管采取哪种方式,都需要对代码进行修改,有时候并不是那么容易的

新人博客,写的不好望见谅!

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值