隨著項目越來越大，局勢就是項目拆分，大項目拆分成很多項目，各種技術也應允而生。
從應用交互層面，按我的理解dubbo和rabbitmq就對比分析進行學習。
dubbo和zookeeper結合
1.zookeeper基於服務發布和治理
2.dubbo註冊服務和發布應用接口
配置說明：
<!-- 提供方 -->
<dubbo:application name="productor-batman"></dubbo:application>
<!-- 使用zookeeper註冊中心暴露服務地址 -->
<dubbo:registry protocol="zookeeper" address="192.168.153.147:2181" />
<!-- 用dubbo協議在20880端口暴露服務 -->
<dubbo:protocol name="dubbo" port="20880" />
<!-- 用戶服務接口 -->
<dubbo:service interface="com.batman.model.Apple" ref="apple" />
<!-- 消費方 -->
<dubbo:application name="consumer-batman" />
<!-- 使用zookeeper註冊中心暴露服務地址 -->
<dubbo:registry protocol="zookeeper" address="192.168.153.147:2181" />
<!-- 用戶服務接口 -->
<dubbo:reference interface="com.batman.model.Apple" id="apple" check="false" />
3.發布服務說白了就是對需要發布的接口封裝成外部調用的jar包讓其它應用程序調用
消費者如果引用了jar並調用，那麽生產者要引用並實現該接口
流程就是這麽簡單，註冊並發布接口，消費者和生產者之間就可以通訊
rabbitmq
1.安裝mq，建立連接
2.聲明一個rabbitTemplate,指定連接信息
3.建立消息隊列
4.發布服務
我們使用的rabbitmq其實就是對spring的amqp做了封裝，應用之間通過接口關聯指定的消息隊列
來達到通訊的目的。好處就是接口不用發布，但是需要指定使用的隊列名稱
二者比較：
相同點
1.都需要安裝第三方插件，一個是zookeeper一個是rabbitmq
2.都是通過發布接口的方式
不同點
1.dubbo直接發布接口，消費方可以直接調用；rabbitmq需要指定消息隊列
dubbo的缺點是每個需要調用的接口都要發布，rabbitmq寫在業務處理類裏面
2.dubbo直接一個dubbo:reference搞定，rabbitmq要對springamqp做多層封裝才能達到通用的目標
3.dubbo支持負債均衡，rabbitmq？？
4.關於socket通訊和rpc框架的使用，dubbo和rabbitmq底層框架原理有待學習

dubbo和rabbitmq對比