1.什麼是SPI技術？
參考博客：https://blog.csdn.net/qiangcai/article/details/77750541
SPI的全名爲Service Provider Interface.大多數開發人員可能不熟悉，因爲這個是針對廠商或者插件的。在java.util.ServiceLoader的文檔裏有比較詳細的介紹。簡單的總結下java spi機制的思想。我們系統裏抽象的各個模塊，往往有很多不同的實現方案，比如日誌模塊的方案，xml解析模塊、jdbc模塊的方案等。面向的對象的設計裏，我們一般推薦模塊之間基於接口編程，模塊之間不對實現類進行硬編碼。一旦代碼裏涉及具體的實現類，就違反了可拔插的原則，如果需要替換一種實現，就需要修改代碼。爲了實現在模塊裝配的時候能不在程序裏動態指明，這就需要一種服務發現機制。 java spi就是提供這樣的一個機制：爲某個接口尋找服務實現的機制。有點類似IOC的思想，就是將裝配的控制權移到程序之外，在模塊化設計中這個機制尤其重要，java spi的具體約定爲:當服務的提供者，提供了服務接口的一種實現之後，在jar包的META-INF/services/目錄裏同時創建一個以服務接口命名的文件。該文件裏就是實現該服務接口的具體實現類。而當外部程序裝配這個模塊的時候，就能通過該jar包META-INF/services/裏的配置文件找到具體的實現類名，並裝載實例化，完成模塊的注入。 基於這樣一個約定就能很好的找到服務接口的實現類，而不需要再代碼裏制定。jdk提供服務實現查找的一個工具類：java.util.ServiceLoader
2 .多版本
http://dubbo.apache.org/zh-cn/docs/user/demos/multi-versions.html
3.本地存根
http://dubbo.apache.org/zh-cn/docs/user/demos/local-stub.html
https://www.cnblogs.com/hzhuxin/p/8250602.html
遠程服務後，客戶端通常只剩下接口，而實現全在服務器端，但提供方有些時候想在客戶端也執行部分邏輯，比如：做 ThreadLocal 緩存，提前驗證參數，調用失敗後僞造容錯數據等等，此時就需要在 API 中帶上 Stub，客戶端生成 Proxy 實例，會把 Proxy 通過構造函數傳給 Stub [1]，然後把 Stub 暴露給用戶，Stub 可以決定要不要去調 Proxy。
4.負載均衡策略
http://dubbo.apache.org/zh-cn/docs/user/demos/loadbalance.html
在集羣負載均衡時，Dubbo 提供了多種均衡策略，缺省爲 random 隨機調用。負載均衡策略
Random LoadBalance
- 隨機，按權重設置隨機概率。
- 在一個截面上碰撞的概率高，但調用量越大分佈越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。
RoundRobin LoadBalance
- 輪詢，按公約後的權重設置輪詢比率。
- 存在慢的提供者累積請求的問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
LeastActive LoadBalance
- 最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。
- 使慢的提供者收到更少請求，因爲越慢的提供者的調用前後計數差會越大。
ConsistentHash LoadBalance
- 一致性 Hash，相同參數的請求總是發到同一提供者。
- 當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
- 缺省只對第一個參數 Hash，如果要修改，請配置 <dubbo:parameter key="hash.arguments" value="0,1" />
- 缺省用 160 份虛擬節點，如果要修改，請配置 <dubbo:parameter key="hash.nodes" value="320" />
配置：
服務端服務級別
<dubbo:service interface="..." loadbalance="roundrobin" />
客戶端服務級別
<dubbo:reference interface="..." loadbalance="roundrobin" />
服務端方法級別
<dubbo:service interface="...">
<dubbo:method name="..." loadbalance="roundrobin"/></dubbo:service>
客戶端方法級別
<dubbo:reference interface="...">
<dubbo:method name="..." loadbalance="roundrobin"/></dubbo:reference>
5.服務降級
服務降級，當服務器壓力劇增的情況下，根據當前業務情況及流量對一些服務和頁面有策略的降級，以此釋放服務器資源以保證核心任務的正常運行。
服務降級方式：
- 服務接口拒絕服務：無用戶特定信息，頁面能訪問，但是添加刪除提示服務器繁忙。頁面內容也可在Varnish或CDN內獲取。
- 頁面拒絕服務：頁面提示由於服務繁忙此服務暫停。跳轉到varnish或nginx的一個靜態頁面。
- 延遲持久化：頁面訪問照常，但是涉及記錄變更，會提示稍晚能看到結果，將數據記錄到異步隊列或log，服務恢復後執行。
- 隨機拒絕服務：服務接口隨機拒絕服務，讓用戶重試，目前較少有人採用。因爲用戶體驗不佳。
https://blog.csdn.net/wsm0712syb/article/details/61413276
Mock 配置：
在消費方指定配置
<!-- 生成遠程服務代理，可以和本地bean一樣使用demoService --> <dubbo:reference id="fooService" interface="com.test.service.FooService" timeout="10000" check="false" mock="return null"> </dubbo:reference>
- mock="return null" 表示消費方對該服務的方法調用都直接返回 null 值，不發起遠程調用。用來屏蔽不重要服務不可用時對調用方的影響。
- 還可以改爲 mock=fail:return+null 表示消費方對該服務的方法調用在失敗後，再返回 null 值，不拋異常。用來容忍不重要服務不穩定時對調用方的影響。
dubbo服務降級具體實現
通過Dubbo的Filter對Dubbo進行擴展，從而使得每次服務發起調用都可以得到監控，從而可以監控每次服務的調用。
對自動判斷服務提供端是否宕機：通過一個記錄器對每個方法出現RPC異常進行記錄，並且可以配置在某個時間段內連續出現多少個異常可判定爲服務提供端出現了宕機，從而進行服務降級。
自動恢復遠程服務調用：通過配置檢查服務的頻率來達到定時檢查遠程服務是否可用，從而去除服務降級。
6.<dubbo:application name="XXXX" /> 作用
用於計算依賴關係
7.RPC原理
自定義RPC實例 https://www.cnblogs.com/swordfall/p/8683905.html
8.Dubbo Spring Boot 事務測試
在controller 調用該測試方法
- 在類級別使用事務 且 沒有@Service沒有任何屬性
![]()
結果：事務沒有回滾
2. 需要在@Service 裏添加提供服務的接口
結果：服務提供方報錯
InterfaceName 改爲interfaceClass
結果 ：服務方成功 消費方不能發現該服務
取消版本號
結果 事務不能回滾
9: dubbo 配置信息 解析
Dubbo.shutdown.hook=ture :
1 概要說明
我們在關閉或重啓dubbo服務時往往會出現請求超時而導致pv lost。
2 原因分析
- 關閉dubbo服務：部分請求未處理完被直接關閉；
- 啓動dubbo服務：服務剛啓動完畢就瞬間湧入大量流量，而此時的服務吞吐能力有限，服務處理不過來而導致請求超時，因爲服務往往有一個慢熱的過程。深層原因分析：服務一般會使用各種連接池，而剛啓動的服務各種資源連接數有限，如果此時服務瞬間湧入大量流量，則會花較多的時間去創建新的資源連接）。
3 解決之道
dubbo爲我們提供了優雅停機
3.1 使用方式
- 對於通過dubbo Main方式啓動dubbo容器的，只需在啓動前添加java環境變量-Ddubbo.shutdown.hook=true即可。
- 對於tomcat等web容器方式啓動dubbo的，需要在關閉時執行方法ProtocolConfig.destroyAll();
3.2 注意事項：
- kill -9 默認對於dubbo Main方式啓動的，優雅停機不生效
- 對於tomcat等web容器方式啓動，注意tomcat等容器關閉等待超時時長（tomcat默認爲等待5s）應大於等於dubbo優雅停機等待超時時長（dubbo默認爲10s）
- 針對剛啓動dubbo服務吞吐能力有限場景，dubbo2.6.2版本增強了優雅停機，可以考慮升級dubbo至2.6.2版本以上。
作者：會飛之魚
鏈接：https://www.jianshu.com/p/8f721ccb7deb
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯繫作者獲得授權並註明出處。
Dubbo.token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
Dubbo提供了對消費者的 token驗證，防止消費者：
1.防止消費者繞過 註冊中心訪問提供者
2.在註冊中心控制權限，以決定要不要下發令牌給消費者。
3.註冊中心可靈活改變授權方式，而不需要修改或升級提供者。
經過測試，只有消費商提供了與提供商一致的token，才能訪問提供商提供的服務。
Dubbo.service.loadbalance=roundrobin
負載均衡策略
RoundRobin LoadBalance
- 輪循，按公約後的權重設置輪循比率。
- 存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
Dubbo.registry-www.file=/xxxxxxxxxxxx/:
1. dubbo Can not lock the registry cache file：
當本地同時啓動服務端和客戶端的時候就可能產生這個問題。
解決方案
Dubbo通過註冊中心發現服務，發現的服務Dubbo同時也會保存到本地緩存一份，緩存的好處有很多，比如不需要每次使用的時候都通過註冊中心獲取，註冊中心不可用了，不影響消費端的調用，
因爲本地緩存了一份服務提供者列表。Dubbo本地緩存默認採用的文件，會根據註冊中心自動在當前用戶目錄下生成一個緩存文件，類似/home/newad/.dubbo/dubbo-registry-*.*.*.*.cache，
星號表示註冊中心的IP地址，當同一臺機器上同時啓動多個進程，就會出現多個進程爭奪此文件的寫入權限，觖此問題的方法也很簡單，日誌裏面都說了重新配置一下這個緩存文件就。
主要在啓動腳本里面添加配置： -Ddubbo.registry.file=C:\Users\dell.dubbo\dubbo-registry-192.168.1.62-junit.cache 文件名自己配置一個
-Ddubbo.registry.file=C:\Users\dell.dubbo\dubbo-registry-192.168.1.62-junit.cache
參見：http://ask.csdn.net/questions/233826
出現java.io.IOException: Can not lock the registry cache file /home/deployer/.dubbo/dubbo-registry-xxxxx.cache, ignore and retry later的問題解決方法
這個問題的出現是因爲dubbo在用戶目錄下使用一個文件來緩存註冊中心的服務提供者的信息，那麼在使用前會加上文件鎖，所以再一次使用這個文件是獲取鎖就會失敗，解決的方式是：
1:確認應用內只有一個<registry>標籤，不同文件的情況下，也只能有一個
2:在<registry>標籤內指定一個文件，使用file屬性 <registry address="xxx" file="xxx"/>
參見：http://www.cnblogs.com/it-zhoujian/p/4326087.html
10 Dubbo 線程模型
11 Dubbo Invoker
這張圖是站在服務消費方的視角來看的（dubbo的服務治理都是針對服務消費方的），當業務邏輯中需要調用一個服務時，你真正調用的其實是dubbo創建的一個proxy，該proxy會把調用轉化成調用指定的invoker（cluster封裝過的）。而在這一系列的委託調用的過程裏就完成了服務治理的邏輯，最終完成調用。
12.Dubbo限制大數據(文件)傳輸的解決方案
<!-- dubbo默認payload爲8M。爲了傳輸文件，加大上限 -->
<dubbo:provider timeout="${dubbo.provider.timeout}" retries="0" cache="false"
payload="30000000"/>
13.Dubbo服務治理
