分布式系统的架构,有两种方式来进行各个子工程之间的依赖
A
依赖B
,B
依赖C
,C
依赖D
(更加夸张的是这里出现循环依赖D
依赖A
)。那么当D
的common.JAR
包改变以后那么A
,B
,C
都需要全部重新编译重新部署,这个时间是很漫长的。A
项目的一个实体在B
项目里面是引用不到的。这个时候如果A
项目需要和B
项目进行通信,并且需要传一个实体。那么必须在A
项目和B
项目里面定义两个一模一样的对象出来,来完成通信。A
,B
,C
,D
4步)需要同步更新促销系统的一个时间。按照现在的逻辑需要做一些处理(将下单流程分解才能完成这个需求)。ALL-Commen.JAR
来放一些公共对象和公共的Util
,所有的子项目依赖这个Jar包(必须确保这些对象是稳定的,不然出现的是ALL-Commen.JAR
一改,所以的子工程都要重新部署)。ALL-Commen.JAR
>各个项目单独通信
不晓得有没有别的模块依赖方式。
分布式系统的架构,有两种方式来进行各个子工程之间的依赖
A
依赖B
,B
依赖C
,C
依赖D
(更加夸张的是这里出现循环依赖D
依赖A
)。那么当D
的common.JAR
包改变以后那么A
,B
,C
都需要全部重新编译重新部署,这个时间是很漫长的。A
项目的一个实体在B
项目里面是引用不到的。这个时候如果A
项目需要和B
项目进行通信,并且需要传一个实体。那么必须在A
项目和B
项目里面定义两个一模一样的对象出来,来完成通信。A
,B
,C
,D
4步)需要同步更新促销系统的一个时间。按照现在的逻辑需要做一些处理(将下单流程分解才能完成这个需求)。ALL-Commen.JAR
来放一些公共对象和公共的Util
,所有的子项目依赖这个Jar包(必须确保这些对象是稳定的,不然出现的是ALL-Commen.JAR
一改,所以的子工程都要重新部署)。ALL-Commen.JAR
>各个项目单独通信
不晓得有没有别的模块依赖方式。
你是不是想复杂了。大概看了你的描述,不同的业务模块都需要对外提供接口,对吗?
那么每个模块专门有个接口层(假设就叫ApiUtils),通讯方式是http、或者socket都行。
模块b调用模块a的接口,发送一个http的request,拿到response就好了。就这么简单,搞什么jar包弄来弄去。
当然还有跟简单的方式,RPC。
很多吧,rmi,hessian,thrift 一类的远程方法调用,或是提供RESTful风格的api接口,或是通过消息队列等
用消息机制来解耦就可以了,你那么做太复杂,一旦复杂bug和维护都会有问题。