接入前的话：
1.MQ的好处
项目历史缘故，我们的远程交互除了http提供服务外，一直以来大部分的服务都是通过MQ的message来交互的，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注入服务调用如
Check为false不检查服务提供者，不写默认为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-pool，dubbo使用的是pool2的
4. MQ和RPC间的一些概念区分
DUBBO： 针对服务的
提供者：provder ===> 暴露服务接口
消费者： cosumer ===> 调用服务接口
MQ: 是针对消息
生产者：producer ===> 生产message
消费者： consumer ===》消费message
正确理解MQ和RPC两者之间的异同，在这次架构调整中学到更多
