kl个人博客 首页>>分布式,架构>>记公司项目架构升级DUBBO

记公司项目架构升级DUBBO

记公司项目架构升级DUBBO


接入前的话:

1.MQ的好处

项目历史缘故,我们的远程交互除了http提供服务外,一直以来大部分的服务都是通过MQmessage来交互的,mq性能支撑我们的业务没点问题,而且mq本身也支持高可用,横向扩展分布式部署也很方便,而且基于服务端的负载可以去中心化,不需要使用注册中心来提供服务发现。

 

2.基于MQ服务的不足

但是为什么运行好好的服务需要改造呢?随着业务发展,服务的增多,我们需要的不在是仅仅简单的提供服务发布和服务调用的PRC。随着服务的不断增加,我们迫切需要一个可以提供服务管理的套件,如服务动态上下线,限流,引流,服务监控等。

 

3.探索期spring cloud

在过去的大半年时间里,我们一直在留意spring cloud的发展,spring cloud是个微服务架构的全家桶,提供了服务发布,注册,熔断,限流,等诸多套件。但是spring 本身提供的套件中关于服务治理这一块还是比较弱,而且spring提供的服务需要整合多个套件,概念也多,在服务接入方面不可预计的问题会比较多,特别一点就是spring cloud构建于spring boot之上,我们还有大部分的系统是老的spring mvc框架,短时间内整体服务切换到spring boot比较困难,所以架构升级spring cloud的代价还是比较大。

 

4.选择dubbo

Dubbo是阿里开源的服务治理型的RPC框架,大家肯定都不陌生了,国内还有很多大流量的公司在内部维护着dubbo在提供服务,如当当维护的dubbox。虽然之前的dubbo在开源届一直被人摒弃为阿里自己不用丢出来的,但是dubbo提供的功能都是有目共睹的,而且今年官方发布重磅消息称重点维护dubbo项目,所以我们对这个本土化的治理型rpc明星项目很有信心,除此之外,dubbo的文档也是业界数一数二的,本身涉及到的东西概念非常清晰易懂。基本没啥学习上的代价,各组项目开发成员比较容易接受,而且本身和spring的集成非常方便简单,改造升级的成本基本可以忽略不计。Dubbo支持的传输协议以及注册中心非常多,我们可以根据项目特性业务特性来选择。我们使用redis作为注册中心,使用dubbo协议

 

所以,综上这次我们选择了dubbo

 

项目接入dubbo

.Spring boot项目接入

1.引入spring-boot-dubbo-starter
2.使用@EnableDubbo注解在main实例开启dubbo服务
3.使用@DubboService暴露提供服务,如
注意:因为dubbo代码加载原因,如果该实现类被spring事务代理了,请在注解指定接口类型如@DubboService(interfaceClass =SalesSendCaService.class )

一般建议都把接口类型写上

 
4.使用@AutowiredDubbo注入服务调用如

Checkfalse不检查服务提供者,不写默认为true

5.配置,application.properties加入如下配置即可,使用redis作为注册中心,dubbo传输协议

spring.dubbo.name = sales spring.dubbo.address = redis://192.168.1.204:6379 spring.dubbo.protocol = dubbo

 

boot项目实例上传了,地址http://git.yudianbank.com/tangshd/yudian-springboot-demo

 

二.老的Spring mvc项目

1.引入依赖

2.服务提供者暴露服务

<!-- 公共信息,也可以用dubbo.properties配置 -->

<dubbo:application name="sales-provider" />

<dubbo:registry address="redis://192.168.1.204:6379" />

<dubbo:annotation package="com.yudianbank.sales " />//扫描@Service,注意不是spring@Service


注意:因为dubbo代码加载原因,如果该实现类被spring事务代理了,请在注解指定接口类型如@Service(interfaceClass =SalesSendCaService.class )

一般建议都把接口类型写上

3.服务消费者调用服务

<dubbo:application name="sales-consumer" />

<dubbo:registry address="redis://192.168.1.204:6379" />

<dubbo:annotation package="com.yudianbank.sales " />

使用@Reference注入服务,如

204服务治理中心

http://192.168.1.204:8804/  用户名:root 密码:admin

规范与细节

 
以下为dubbo架构改造过程中需要规范的一些细节,以及注意的地方
1.  接口的定义:一般要求接口定义在服务的提供方,先有服务,后有调用,而且抽象的接口不止一方使用,除非业务原因,只会在两方系统交互。所以一般接口定义写在服务提供方的api模块
2.  传输对象除了需要Serializable外,记得加上SerializableID,如private static final long serialVersionUID = -3004897982973953999L;主要为了接口差异化时间发布时的向下兼容
3.  有些项目可能会存在相关的jar包的冲突,这也是dubbo版本升级导致的一些问题,目前在集成过程中发现的有commons-pooldubbo使用的是pool2
4.  MQRPC间的一些概念区分
DUBBO: 针对服务的
提供者:provder  ===>  暴露服务接口
消费者: cosumer       ===> 调用服务接口
 
MQ:  是针对消息
生产者:producer               ===> 生产message
消费者: consumer    ===》消费message
 
正确理解MQRPC两者之间的异同,在这次架构调整中学到更多
 
kl个人博客