项目结构如下:
web 项目名
-- server sercice 层
-- web controller 层
transfer_server
-- transferCore dao 接口
-- transferServer
transfer_api POJO 类,工具类
web 作为 consumer,transfer_server 作为 provider,用 dubbo 做服务注册发现,多个 web 项目调用 transfer_server
transfer_server 项目中 dubbo-provider.xml 中只暴露一个接口,配置如下:
<!-- Api 服务 Service -->
<dubbo:service interface="com.iyunche.transfer.api.server.TransferInvoker"
ref="transferInvoker" owner="owner1" version="${dubbo.service.versions}"
delay="${dubbo.service.delay}" timeout="${dubbo.service.delay}"
retries="${dubbo.retries}"/>
web 项目中 dubbo-consumer.xml 配置如下
<!--==================== transferApiInvoker =============== -->
<dubbo:reference id="transferApiInvoker" check="${dubbo.is_check}"
interface="com.iyunche.transfer.api.server.TransferInvoker" version="${dubbo.service.versions}"
timeout="${dubbo.service.delay}" />
分割线
1、问题一:在 dubbo 配置文件中只暴露一个接口有什么优缺点?
web 项目中接口调用方式如下:
transferInvoker.invokeObject("logisticsOrderService#getLogisticsOrderById", logisticsId);
transfer_server 通过反射找到接口和实现类
目前我知道的好处是不用每次都配置 dubbo 配置文件,但是在 dubbo 监控中心里监控接口调用次数等功能全部失效。
2、问题二:项目分层问题
目前项目中 controller 层和 service 层在同一个项目,在 service 层做业务逻辑,然后通过 dubbo 调用 transfer_server,transfer_server 中直接调用 dao 层。
依我的看法是项目中 controller 层封装完数据之后,通过 dubbo 调用 transfer_server,在 transfer_server 中处理业务逻辑,复用 transfer_server 中的方法
组长说在项目中 controller 层封装数据,service 层处理业务逻辑,之后通过 dubbo 调用 transfer_server,会在 transfer_server 中写通用的业务逻辑,达到复用的目的,然后调用 dao 层
但是我看来目前 transfer_server 什么都没做,直接调用 dao 层,transfer_server 中方法的复用其实就是 dao 层接口的复用,transfer_server 相当于鸡肋,方法复用性很小
求大家指教,谢谢
1
MotherShip 2019-06-24 23:18:53 +08:00 via iPhone 1
这事应该取决于具体有哪些共有的逻辑吧……
|
2
MotherShip 2019-06-25 09:52:22 +08:00 1
昨晚困了没仔细回,我先试着纸上谈兵一番,说错了轻喷)
仔细看了一下,这是把 dubbo 用成了单纯的负载均衡。。充分一点的用法应该是按业务把项目拆开,在多台机器上启动多个实例,全部注册到注册中心去,然后在 web 层校验参数后按业务向注册中心发请求。。 可以看看李智慧那本大型网站技术架构的 1.2 章,dubbo 本来是在 1.2.10 阶段用的工具,你们用在了 1.2.4 这个阶段上。。 |
3
renyapeng OP @MotherShip 谢谢李智慧的书正好有,再去看下
|