dubbo
1.服務provider 提供服務時，需要將當前service進行在provider.xml中註冊，通過<dubbo:service>進行暴露，這樣才能被其他消費者進行消費
2.服務consumer 消費服務時，需要將使用的服務在consum.xml中引入，通過<dubbo:reference>進行引用，這樣才能使用方法。(向註冊中心訂閱“服務提供者”提供的服務地址，並生成服務接口的實際代理對象。)
spring
可以將服務 在xml中通過<bean>進行容器注入，這種方式和利用註解是一樣的。@Service等。
core.xml
<context:annotation-config />
<context:component-scan base-package="com.sun.core" />
<context:component-scan base-package="com.sun.sync" />
<aop:aspectj-autoproxy />
<!-- 任務調度器 -->
<task:scheduler id="scheduler" pool-size="10"/>
<!-- 任務執行器 -->
<task:executor id="executor" pool-size="10"/>
<!-- task Schedule-->
<task:annotation-driven executor="executor" scheduler="scheduler" proxy-target-class="true"/>
用 Spring 配置聲明暴露服務
provider.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
<!-- 提供方應用信息，用於計算依賴關係 -->
<dubbo:application name="hello-world-app" />
<!-- 使用multicast廣播註冊中心暴露服務地址 -->
<dubbo:registry address="multicast://224.5.6.7:1234" />
<!-- 用dubbo協議在20880端口暴露服務 -->
<dubbo:protocol name="dubbo" port="20880" />
<!-- 聲明需要暴露的服務接口 -->
<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" />
<!-- 和本地bean一樣實現服務 -->
<bean id="demoService" class="org.apache.dubbo.demo.provider.DemoServiceImpl" />
</beans>
通過 Spring 配置引用遠程服務
consumer.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
<!-- 消費方應用名，用於計算依賴關係，不是匹配條件，不要與提供方一樣 -->
<dubbo:application name="consumer-of-helloworld-app" />
<!-- 使用multicast廣播註冊中心暴露發現服務地址 -->
<dubbo:registry address="multicast://224.5.6.7:1234" />
<!-- 生成遠程服務代理，可以和本地bean一樣使用demoService -->
<dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" />
</beans>
服務目錄
，通過服務目錄，服務消費者可獲取到服務提供者的信息，比如 ip、端口、服務協議等。
實際上服務目錄在獲取註冊中心的服務配置信息後，會爲每條配置信息生成一個 Invoker 對象，並把這個 Invoker 對象存儲起來，這個 Invoker 纔是服務目錄最終持有的對象。一個具有遠程調用功能的對象。
RPC(Remote Procedure Call Protocol)是一種遠程調用協議， 允許像調用本地服務那樣調用遠程其它服務，即實現跨進程交互。
1.在微服務架構中，一個服務可用提供接口和調用rpc接口。
2.調用者執行接口時可找到其他進程的函數體，是通過socket交互字節流實現的。
3.rpc是介於應用層和傳輸層之間的協議
4.調用者是通過服務註冊中心（zookeeper）找到被調用者的
Dubbo服務端接口export(導出)是將接口信息註冊到註冊中心Registry的過程。而客戶端import(導入)遠程接口是通過從註冊中心Registry訂閱遠程服務接口，收到通知後拉取到本地的過程。
註冊和訂閱的過程，不需要修改服務端本地的類和方法，只需保證客戶端和服務端共同引用一個包含接口的jar包。服務端和客戶端分別編寫簡單的dubbo接口配置xml文件（或註解的方式），容器啓動時就自動註冊和訂閱了。
DUBBO總體架構：各個層次的設計要點
服務接口層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。
配置層（Config）：對外配置接口，以ServiceConfig和ReferenceConfig爲中心，可以直接new配置類，也可以通過spring解析配置生成配置類。
服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端Stub和服務器端Skeleton，以ServiceProxy爲中心，擴展接口爲ProxyFactory。
服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL爲中心，擴展接口爲RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心，此時服務提供方直接暴露服務。
集羣層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker爲中心，擴展接口爲Cluster、Directory、Router和LoadBalance。將多個服務提供方組合爲一個服務提供方，實現對服務消費方來透明，只需要與一個服務提供方進行交互。
監控層（Monitor）：RPC調用次數和調用時間監控，以Statistics爲中心，擴展接口爲MonitorFactory、Monitor和MonitorService。
遠程調用層（Protocol）：封將RPC調用，以Invocation和Result爲中心，擴展接口爲Protocol、Invoker和Exporter。Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命週期管理。Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke調用，它有可能是一個本地的實現，也可能是一個遠程的實現，也可能一個集羣實現。
信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以Request和Response爲中心，擴展接口爲Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
網絡傳輸層（Transport）：抽象mina和netty爲統一接口，以Message爲中心，擴展接口爲Channel、Transporter、Client、Server和Codec。
數據序列化層（Serialize）：可複用的一些工具，擴展接口爲Serialization、 ObjectInput、ObjectOutput和ThreadPool。
對於上述各層之間關係的描述，如下所示：
> 在RPC中，Protocol是核心層，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC調用，然後在Invoker的主過程上Filter攔截點。
> 圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的瞭解哪些類分屬於客戶端與服務器端，不用Client和Server的原因是Dubbo在很多場景下都使用Provider、Consumer、Registry、Monitor劃分邏輯拓普節點，保持統一概念。
> 而Cluster是外圍概念，所以Cluster的目的是將多個Invoker僞裝成一個Invoker，這樣其它人只要關注Protocol層Invoker即可，加上Cluster或者去掉Cluster對其它層都不會造成影響，因爲只有一個提供者時，是不需要Cluster的。
> Proxy層封裝了所有接口的透明化代理，而在其它層都以Invoker爲中心，只有到了暴露給用戶使用時，才用Proxy將Invoker轉成接口，或將接口實現轉成Invoker，也就是去掉Proxy層RPC是可以Run的，只是不那麼透明，不那麼看起來像調本地服務一樣調遠程服務。
> 而Remoting實現是Dubbo協議的實現，如果你選擇RMI協議，整個Remoting都不會用上，Remoting內部再劃爲Transport傳輸層和Exchange信息交換層，Transport層只負責單向消息傳輸，是對Mina、Netty、Grizzly的抽象，它也可以擴展UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。
> Registry和Monitor實際上不算一層，而是一個獨立的節點，只是爲了全局概覽，用層的方式畫在一起。
集羣容錯：失敗自動切換，當出現失敗，重試其它服務器。通常用於讀操作，但重試會帶來更長延遲。可通過 retries="2" 來設置重試次數(不含第一次)。
負載均衡：從多個服務提者方中選擇一個進行調用（隨機，輪詢，一致性 Hash）
https://baijiahao.baidu.com/s?id=1612574809664801766&wfr=spider&for=pc
看下一次完整的 RPC 調用是如何進行的。
首先從圖的左邊開始，服務消費者從 Proxy 層發起一次 RPC 調用，Dubbo 從 Registry 層拿到服務的地址列表，再通過 Cluster 層選擇其中的一個作爲目標地址，再流經 Protocol 決定的執行鏈，最後將服務信息，包括要調用的服務名、方法名、參數等序列化，再經過應用協議編碼，通過 Transport 層發送到網絡上。
右邊的服務提供者從網絡上收到數據以後，從下往上，依次通過應用協議解碼、反序列化得到要調用的服務信息，再經由執行鏈，最終通過 Invoker 找到目標服務的目標方法，執行並返回結果。