dubbo學習筆記
一、Dubbo 創造者對於Dubbo的價值與意義作出過精辟的見解
1、單一應用架構
網站流量很小，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本
此時，用於簡化增刪改查工作量的 數據訪問框架(ORM) 是關鍵。
2、垂直應用架構
訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相幹的幾個應用，以提升效率，
此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
3、分布式服務架構
垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求，
此時，用於提高業務復用及整合的 分布式服務框架(RPC)
4、流動計算架構
服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集群容量，提高集群利用率，
此時，用於提高機器利用率的 資源調度和治理中心(SOA) 是關鍵。
關鍵在於第3向第4的轉變，原因在大規模服務化之前，應用可能只是通過RMI或Hessian等工具，簡單的暴露和引用遠程服務，通過配置服務的URL地址進行調用，通過F5等硬件進行負載均衡。
(1) 當服務越來越多時，服務URL配置管理變得非常困難，F5硬件負載均衡器的單點壓力也越來越大。
此時需要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。
並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，降低對F5硬件負載均衡器的依賴，也能減少部分成本。
(2) 當進一步發展，服務間依賴關系變得錯蹤復雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關系。
這時，需要自動畫出應用間的依賴關系圖，以幫助架構師理清理關系。
(3) 接著，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麽時候該加機器？
為了解決這些問題，第一步，要將服務現在每天的調用量，響應時間，都統計出來，作為容量規劃的參考指標。
其次，要可以動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。
二、低侵入式集成
1、獨立服務接口層
單獨打包，服務提供方和消費方都需依賴此包
如：com.alibaba.dubbo.demo.DemoService
2、服務提供方
<!-- 聲明需要暴露的服務接口 -->
<dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" />
<!-- 和本地bean一樣實現服務 -->
<bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" />
註：com.alibaba.dubbo.demo.provider.DemoServiceImpl只存於服務提供方的包裏，對消費者透明。
3、服務消費方
<!-- 生成遠程服務代理-->
<dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" />
<!-- 和本地服務一樣使用遠程服務 -->
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
<property name=“demoService” ref=“demoService” />
</bean>
三、服務信息註冊
1、配置中心ConfigServer
每個Server/Client之間會作一個實時的心跳檢測（因為它們都是建立的Socket長連接），比如幾秒鐘檢測一次。收集每個Server提供的服務的信息，每個Client的信息，整理出一個服務列表，如：
| serviceName | serverAddressList | clientAddressList |
| UserService | 192.168.0.1，192.168.0.2，192.168.0.3，192.168.0.4 | 172.16.0.1，172.16.0.2 |
| ProductService | 192.168.0.3，192.168.0.4，192.168.0.5，192.168.0.6 | 172.16.0.2，172.16.0.3 |
| OrderService | 192.168.0.10，192.168.0.12，192.168.0.5，192.168.0.6 | 172.16.0.3，172.16.0.4 |
2、提供方與消費方都需要的
<dubbo:application name="hello-world-app-xxx" /> //提供方與消費方不要重名就可以了，沒有格式要求，只用於計算依賴關系
<dubbo:registry address="multicast://224.5.6.7:1234" />//使用廣播的方式暴露（提供方）和通知發現（消費方）服務地址
3、提供方專有
<dubbo:protocol name="dubbo" port="20880" />//標明使用哪種協議和端口提供服務
四、多樣化支持
1、多個註冊中心
支持同時有多個服務註冊中心，一個服務也可以註冊到多個註冊中心。
<!-- 多註冊中心配置 -->
<dubbo:registry id="chinaRegistry" address="10.20.141.150:9090" />
<dubbo:registry id="intlRegistry" address="10.20.141.151:9010" default="false" />
<!-- 向多個註冊中心註冊 -->
<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" registry="chinaRegistry,intlRegistry" />
<!-- 向中文站註冊中心註冊 -->
<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" registry="chinaRegistry" />
<!-- 向國際站註冊中心註冊 -->
<dubbo:service interface="com.alibaba.hello.api.DemoService" version="1.0.0" ref="demoService" registry="intlRegistry" />
2、多種服務協議
支持同時使用多個服務協議，一個服務可以用多個協議暴露
如：
<!-- 多協議配置 -->
<dubbo:protocol name="dubbo" port="20880" />
<dubbo:protocol name="rmi" port="1099" />
<!-- 使用dubbo協議暴露服務 -->
<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" protocol="dubbo" />
<!-- 使用rmi協議暴露服務 -->
<dubbo:service interface="com.alibaba.hello.api.DemoService" version="1.0.0" ref="demoService" protocol="rmi" />
<!-- 使用多個協議暴露服務 -->
<dubbo:service id="helloService" interface="com.alibaba.hello.api.HelloService" version="1.0.0" protocol="dubbo,hessian" />
五、多版本
當一個接口實現，出現不兼容升級時，可以用版本號過渡，版本號不同的服務相互間不引用。
1、提供方提供多個版本
<dubbo:service interface="com.foo.BarService" version="1.0.0" />
<dubbo:service interface="com.foo.BarService" version="2.0.0" />
2、消費方可以忽略版本
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />
六、結果緩存
結果緩存，用於加速熱門數據的訪問速度，Dubbo提供聲明式緩存，以減少用戶加緩存的工作量。
1、lru 基於最近最少使用原則刪除多余緩存，保持最熱的數據被緩存。
2、threadlocal 當前線程緩存，比如一個頁面渲染，用到很多portal，每個portal都要去查用戶信息，通過線程緩存，可以減少這種多余訪問。
3、jcache 與JSR107集成，可以橋接各種緩存實現。
如：
<dubbo:reference interface="com.foo.BarService" cache="lru" />
<dubbo:reference interface="com.foo.BarService">
<dubbo:method name="findBar" cache="lru" />
</dubbo:reference>
七、上下文信息
上下文RpcContext中存放的是當前調用過程中所需的環境信息，RpcContext是一個ThreadLocal的臨時狀態記錄器，當接收到RPC請求，或發起RPC請求時，RpcContext的狀態都會變化。
比如：A調B，B再調C，則B機器上，在B調C之前，RpcContext記錄的是A調B的信息，在B調C之後，RpcContext記錄的是B調C的信息。
八、參數回調
參數回調方式與調用本地callback或listener相同，只需要在Spring的配置文件中聲明哪個參數是callback類型即可，Dubbo將基於長連接生成反向代理，這樣就可以從服務器端調用客戶端邏輯。
九、事件通知
在調用之前，調用之後，出現異常時，會觸發oninvoke, onreturn, onthrow三個事件，可以配置當事件發生時，通知哪個類的哪個方法。
十、連接控制
1、限制服務器端接受的連接不能超過10個：（以連接在Server上，所以配置在Provider上）
<dubbo:provider protocol="dubbo" accepts="10" />
<dubbo:protocol name="dubbo" accepts="10" />
2、限制客戶端服務使用連接連接數：(如果是長連接，比如Dubbo協議，connections表示該服務對每個提供者建立的長連接數)
<dubbo:reference interface="com.foo.BarService" connections="10" />
十一、令牌驗證
防止消費者繞過註冊中心訪問提供者，在註冊中心控制權限，以決定要不要下發令牌給消費者，註冊中心可靈活改變授權方式，而不需修改或升級提供者
<!--隨機token令牌，使用UUID生成-->
<dubbo:provider interface="com.foo.BarService" token="true" />
<!--固定token令牌，相當於密碼-->
<dubbo:provider interface="com.foo.BarService" token="123456" />
也可在服務和協議級別上設置
dubbo學習筆記