-------------------dubbo和cloud對比------------
巧記：組件均衡註冊RPC降級監控鏈路配置
| dubbo+zk（自帶就支持嗎） | cloud（自帶就支持嗎） | |
| 註冊與服務發現 | （自帶） zk(一致性---zk集羣有主從區別，當master宕機，進入選舉模式時，就無法正常對外提供服務。)，關注點： 1、過半選舉算法--無leader時，投票過半選舉，一樣就看兩種Id大小 2、腦裂問題--新leader出現而原leader又復活（解決：重新進行過半選舉，一般新的會保留，因爲它過半了，舊的掛了只有一臺選它） |
（自帶） Eureka(高可用--集羣是對等的，無主從，各自提供服務且相互註冊來解決單點故障，不能保證一致性，但至少有一臺存活可以提供服務) |
| 負載均衡和調用 | （自帶） dubbo: |dubbo/http/rest/hessian等 其中dubbo的RPC調用速度快，少三次握手 |
（自帶） Ribbon和feign: http請求 |
| 服務降級和熔斷機制（可以防止雪崩） |
（自帶）Admin mock配置，實現dubbo服務降級---比如 屏蔽：屏蔽請求，直接返回某個值，如mock="return 123456.." 容錯：允許請求，在請求失敗的時候，再返回某個值，如：mock="fail:return 123456."; |
（自帶） Hystrix斷路器---自定義降級返回值 附：還支持ginx進行流量控制 |
| 分佈式配置中心 | （非自帶） zk的持久節點唯一性； zk客戶端寫一個監聽zk持久節點變更的方法，代碼動態地同步至本地緩存 缺點---不同環境得弄不同的zk服務 |
（自帶）cloud-config
手動---actuator開啓監控斷點pom及配置，引用refreshscope註解 |
| 消息總線 | （非自帶） |
（自帶） 一般bus是與cloud config整合： 手動去調一個服務A拉取到配置改動（訪問/bus/refresh接口），A會發布消息總線的隊列，其他訂閱監聽事件的服務會接收變更事件消息，也會去消費拉取一次最新的配置。 |
| 消息驅動 | （非自帶） |
（自帶） 集成不同消息中間件的實現 |
| 網關 | （非自帶） |
（自帶）Zuul 聚合API接口，統一接口轉發 |
| API文檔收集 | （非自帶） |
（自帶）Swagger2 在網關統一收集API文檔 l限流 重試機制 負載均衡 |
| 監控中心可視化界面 |
（自帶）monitor 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心，監控中心則使用數據繪製圖表來顯示。 |
（自帶） 監控中心Actuator+可視化AdminUI： 看到Http接口接口調用情況/內存變化/服務連接情況/bean數量 |
| 鏈路監控跟蹤系統（耗時、日誌等） | （非自帶）客戶端字節碼注入探針+skywalking+ES
主導----用 Skywalking 做dubbo分佈式鏈路追蹤，Skywalking 分析調用關係、調用時間爲主 輔助----可集成elk來看服務調用異常及日誌爲主
|
（自帶）Sleuth+MQ+Zipkin+ES Zipkin優點：輕量，使用部署簡單（攔截請求，發送（HTTP，mq）數據至zipkin服務） |
-------------------RPC------------
？RPC接口與HTTP接口相比，有什麼優勢？
HTTP協議，需要帶HTTP請求頭，導致傳輸起來效率或者說安全性不如RPC，特別是微服務裏業務請求十分頻繁的情況下不適合；
長鏈接減少3次握手，不必每次通信都要像http 一樣去3次握手什麼的，減少了網絡開銷
其次就是RPC框架一般都有註冊中心，具有SOA服務治理，，有豐富的監控管理、發佈、下線接口、動態擴展等
第三個來說就是安全性
RPC原理？
1.服務消費方（client）調用以本地調用方式調用服務；
2.client stub接收到調用後負責將方法、參數等組裝成能夠進行網絡傳輸的消息體；
3.client stub找到服務地址，並將消息發送到服務端；
4.server stub收到消息後進行解碼；
5.server stub根據解碼結果調用本地的服務；
6.本地服務執行並將結果返回給server stub；
7.server stub將返回結果打包成消息併發送至消費方；
8.client stub接收到消息，並進行解碼；
9.服務消費方得到最終結果。
Dubbo RPC調用的真正原理？（最重點）
巧記版：
1）客戶端用唯一ID與請求報文+callback放入全局ConcurrentHashMap，然後再封裝ID+報文進連接對象發起異步調用，然後當前線程A開始wait等待服務端的回調。
2）服務端收到請求後把帶這個ID的結果返回給客戶端。
3）客戶端socket連接裏，專門監聽消息的線程收到消息後，拿到ID從ConcurrentHashMap取出callback，並把返回結果放進callback，然後通過notifyAll()喚醒之前客戶端等待的線程A，線程A醒了之後事，重新執行callback.get()去抓取剛剛放進去的結果，整個調用完成。
分析源代碼，基本原理如下：
1）dubbo客戶端當前線程，先將請求報文（如調用的接口名稱，方法名稱，參數值列表等），和等待回調對象callback，全部封裝在一個object對象裏。同時，會生成一個唯一的ID（AtomicLong從0累加），把這個ID和object存入全局ConcurrentHashMap裏。
同時，再把將ID和請求報文封裝成一對象connRequest（前面object裏比這裏多了一個callback），使用IoSession.write(connRequest)異步發送出去，正式調用服務器。
同時，客戶端當前線程再使用callback的get()方法去試圖獲取遠程返回的結果，如果沒有就“等待”，（在get()內部，則使用synchronized獲取回調對象callback的鎖， 再先檢測是否已經獲取到結果，如果沒有，然後調用callback的wait()方法，釋放callback上的鎖，讓當前線程處於等待狀態）。
2）服務端接收到請求並處理後，將帶ID的結果發送給客戶端。
3）客戶端socket連接裏，專門監聽消息的線程收到消息，分析結果，取到ID，再從前面的ConcurrentHashMap裏面get(ID)，從而找到callback，將方法調用結果設置到callback對象裏。
該監聽線程接着使用synchronized獲取回調對象callback的鎖（因爲前面調用過wait()，那個線程已釋放callback的鎖了），
再notifyAll()，喚醒前面處於等待狀態的線程繼續執行，callback的get()方法繼續執行就能拿到調用結果了，至此，整個過程結束。
-------------------dubbo+zk+監控的搭建-------------
？我搭建過，如何搭建？
引用：https://blog.csdn.net/mijichui2153/article/details/81102277
0、搭建java和tomcat環境
一、搭建zookeeper
下載zk軟件安裝包zookeeper-3.5.3-beta.tar，存放在tomcat目錄 /usr/mysoftware/tomcat ，創建建立logs文件夾和data文件夾用於存放日誌和數據。修改端口等配置
clientPort使用默認的2181端口即可：
（配集羣再另說）。
在進入到bin目錄，啓動tomcat服務：
二、搭建dubbo監控中心
版本要求：
下載admin軟件安裝包dubbo-admin-2.5.6.war及以上版本，否則會不支持JDK1.8！
存放在tomcat目錄，修改配置dubbo.properties文件指向Zookeeper註冊中心的IP地址 ，（說明監控管理中心是直接讀的zk，由zk去收集提供者和調用者信息）
然後啓動tomcat服務
三、接下來繼續生產者和生產者的系統搭建
提供者：
maven引入zkclient包，dubbo包.
啓動類加上@EnableDubbo，接口實現類直接用dubbo自帶的@Service往註冊中心註冊提供者接口服務，通過配置向註冊中心註冊接口服務信息。
調用者：
maven引入zkclient包，dubbo包，提供者接口所在的pom包.
啓動類加上@EnableDubbo，業務層直接用dubbo自帶的@Reference從註冊中心獲取提供者接口列表，然後本地調用（底層會以真實地址調用）。
分別把它兩放入tomcat啓動。
？搭建和使用過程中遇到哪些問題？
1 、監控項目需要更改配置
Java代碼
- dubbo.jetty.directory=/home/xx/dubbomitor/dubbo-monitor-simple-2.5.5/monitor
- dubbo.charts.directory=${dubbo.jetty.directory}/charts
- dubbo.statistics.directory=/home/xxx/dubbomitor/dubbo-monitor-simple-2.5.5/monitor/statistics
monitor 這個文件夾需要自己創建的。statistics,charts文件夾，監控項目會自動創建。
2 、項目服務端和客戶端增加配置,不然一直找不到服務
statistics 對應的服務端。配置文件中增加
<dubbo:monitor protocol="registry"/>
charts 對應的客戶端
<dubbo:monitor protocol="registry"/>
3、zk的端口和tomcat的端口衝突了。如果tomcat先啓動了那麼zk就無法真正的啓動。歸根結底：zk的默認端口是8080，這個是和tomcat的默認端口衝突，這回造成每次兩者只能啓動一個另一個啓動不成功。
驗證：你直接將tomcat和zk都啓動，然後查看端口占用情況“netstat -an |grep 8080”。如下圖所示顯然是衝突了。
解決辦法：在上面vim zoo.cfg 中加上一句
admin.serverPort=8088 #改爲沒有被佔用的端口號
4、如果還是連不上的話關閉防火牆試試。
5、Service用成了spring的
-------------------dubbo+網關gateway-------------
簡介：
該網關係統，它所使用的web容器仍爲tomcat。
仍會採用nginx作爲反向代理服務器，主要是由於nginx的單機高併發能力，以及後端服務的高可用檢測;
網關的作用？
併發量限制
校驗攔截
-------------------dubbo-------------
？dubbo底層原理？
1.服務容器負責啓動，加載，運行服務提供者。
2.服務提供者在啓動時，向註冊中心註冊自己提供的服務。
3.服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
4.註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
5.服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
6.服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
![]()
？Dubbo的作用或優點（爲什麼要使用dubbo）？
以12306系統爲例，平日裏的訪問量和春運時的訪問量是完全不同的。春運時硬件設備容量不足，肯定需要臨時租用一些硬件設備動態加入，用完又動態撤下來，不影響服務。dubbo就是其中一種解決方案能動態的、流動性的調度各個服務。
Dubbo的心跳機制？（默認心跳間隔時間1分鐘；）
dubbo源碼裏會啓動心跳任務方法；（雙方都有心跳互相調）
比如，消費者最後一次發或收消息的時間差大於心跳間隔時，會觸發心跳方法內的心跳業務塊去調用一次服務發送心跳消息給提供者。如果3次都沒有收到心跳響應，
consumer的定時心跳任務會進行重連服務端。
而provider的定時心跳任務，超時3次，會關閉服務端自已通道channel;；
dubbo客戶端和dubbo服務端之間存在心跳。
dubbo服務端和註冊中心（zk）存在心跳。
？選dubbo的原因(與cloud比)？
1、Dubbo缺省協議採用單一長連接和NIO異步通訊，適合於小數據量大併發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的情況
2、SpringCloud基於Http調用的方式，更加靈活，但是消息封裝臃腫(可以使用gzip壓縮)；Dubbo基於RPC調用的方式（但提供者與zk之間是用的netty,scoket->netty(長連接有狀態)），使服務就像可以調用自己本地的服務一樣調用別人的服務
3、Dubbo 的定位始終是一款 RPC 框架，而 Spring Cloud 的目標是微服務架構下的一站式解決方案.如果公司對效率有極高的要求建議使用 Dubbo，相對比 RPC 的效率會比 HTTP 高很多
(Dubbo缺點是隻支持java)
？選cloud的原因(與dubbo比)？
Dubbo 的定位始終是一款 RPC 框架，而 Spring Cloud 的目標是微服務架構下的一站式解決方案
如果公司選擇微服務架構去重構整個技術體系，那麼
Spring Cloud 是當仁不讓之選，它可以說是目前最好的微服務框架沒有之一，並且可以斷言，將來Dubbo可以很好的整合到Spring Cloud中。
Spring Cloud是一個全家桶。
？dubbo與cloud的相同點和不同點?
引用：https://blog.csdn.net/zhanggqianglovec/article/details/104055255
巧記：組件均衡註冊RPC降級監控鏈路配置
回答1相同點：
dubbo和spring cloud都是微服務框架。
服務發現：就是不用知道服務的ip端口，通過服務名就能使用服務。
回答2不同點：
1、功能組件範圍：Dubbo 關注於服務治理這塊並且以後也會繼續往這個方向去發展，Spring Cloud 關注的是微服務的全套解決方案。Dubbo的功能包括服務註冊發現，遠程調用，監控等等。Cloud包括全套組件。
2、服務註冊和發現：spring cloud服務服務註冊和發現,是Eureka組件，Eureka就是爲了服務發現而設計的。Dubbo的服務發現模塊基於zookeeper實現，是用來保證分佈式一致性的一個軟件。不是爲了服務發現註冊而設計的;
3、調用方式：Spring Cloud 拋棄了 Dubbo 的 RPC 通信，Cloud採用的是基於 HTTP調用 的 REST 方式（當然它也有第二種方式和dubbo類似，即接口實現+註解）， Cloud 的REST 相比 RPC 更爲靈活，服務提供方和調用方不存在代碼級別的強依賴，這在強調快速演化的微服務環境下顯得更加合適。但Dubbo 的 RPC服務調用的性能更好
4、阿里的Dubbo和spring家族的Cloud。
特點比較：
運行流程比較
Dubbo：
SpringCloud：(ribbon可用feign替換，以接口+註解方式替換restTemplate)
-------------------Dubbo負載均衡（需利用zk）-------------
？負載均衡工作原理？
每個服務提供者啓動時創建一個父節點（存在則重複用），應用客戶端通過讀取節點列表獲得可用服務器列表，並訂閱節點事件。若有服務提供者宕機斷開時觸發事件，客戶端監測到後把該Server從可用列表中刪除。若有新增節點，也觸發訂閱的節點事件，列表+1
圖
？負載均衡的作用或優點？
負載均衡作用：高可用。
Zookeeper註冊中心作用：當提供者出現斷電等異常停機時，Zookeeper註冊中心能自動刪除提供者信息，當提供者重啓時，能自動恢復註冊數據，以及訂閱請求。
？我搭建過，如何搭建？
？搭建和使用過程中遇到哪些問題？
？負載均衡dubbo與nginx的區別?
dubbo的負載均衡是服務層面（在http調用之前，本地負載），nginx的負載均衡在http請求層面。
dubbo在服務發現這個地方做的更像一個dns（解析別名找到具體提供者地址）。
-------------------zookeeper自帶集羣（是zk自已，不是客戶端）-------------
？Zookeeper自帶的特性（是zk自已，不是客戶端）？
1、Zookeeper：一個leader，多個follower組成的集羣（只要zk集羣中有半數以上節點存活，集羣就能提供服務）
2、全局數據一致：每個server保存一份相同的數據副本，client無論連接到哪個server，數據都是一致的
3、分佈式讀寫，更新請求轉發，由leader實施
4、更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行
5、數據更新原子性，一次數據更新要麼成功，要麼失敗
6、實時性，在一定時間範圍內，client能讀到最新數據
-------------------Zookeeper註冊中心-------------
？Zookeeper註冊中心的原理？
？Zookeeper與eureka的區別？
檢測節點服務變化的不同：前者長連接發現變化，就立馬事件通知；心跳機制間隔性檢測變化，然後通知
-------------------zookeeper分佈式鎖-------------
？分佈式鎖工作原理？
主要得益於 ZooKeeper 爲我們保證了數據的強一致性.
一個是 保持獨佔，所有客戶端都去創建臨時節點，最終成功創建的那個客戶端也即擁有了這把鎖。
另一個是 控制時序,所有客戶端都去創建臨時有序節點，臨時擁有了這把鎖，用完斷開連接就釋放，全局時序執行下一個。
？zookeeper分佈式鎖怎麼實現的（實現原理）？
答：唯一性和集羣的強一致性（2pc）
通過一起去創建節點同一個節點 的方式來實現。每個節點是唯一的，只能有一個成功
所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。（使用臨時節點，失效時間容易控制，程序執行完成之後此序列節點消失）
步驟：https://www.cnblogs.com/toov5/p/9899489.html
多個客戶端（jvm）同時在Zookeeper上創建同一個相同的臨時節點；（zkClient.createEphemeral(lockPath)）
jvm1創建成功時候，jvm2和jvm3創建節點時候會報錯，該節點已經存在；（這時候 jvm2和jvm3進行等待）
jvm1執行完畢，釋放鎖。關閉當前會話連接（就會清除臨時節點）。臨時節點不復存在了並且事件通知Watcher，jvm2和jvm3繼續創建。
？的作用或優點？
-------------------Zookeeper配置中心-------------
？Zookeeper配置中心的原理？（注意多了一個管理系統和其數據庫）
利用發佈與訂閱模型。
發佈者管理系統負責把數據持久化到數據庫mysql等（服務掛了可再讀mysql，重新發布到zk上，類似dubbo註冊的服務發現）
有數據變更，發佈者管理系統會將數據發佈到ZK服務器節點上。
每個zk客戶端客戶端連接zk後，在zk客戶端本地綁定一個監聽器,開啓事件監聽開關，實現訂閱。如果zk有變更就會通知zk客戶端，執行監聽器類的代碼，把值同步到本地緩存。
？的作用或優點，基於Zookeeper實現分佈式配置中心有什麼好處？
一、答：實時推送穩定性、實效性。
優勢
1、多個環境配置集中管理。
2、配置更改，實時推送，jvm環境變量及時生效。
3、依靠配置變更，動態擴展功能，減少二次上線帶來的成本。
4、減少開發人員、運維人員修改配置帶來的額外開銷。
---------以前的-------
？基於Zookeeper-dubbo的實現原理？
答：dubbo是一個分佈式框架，遠程服務調用的分佈式框架,其實現原理是這樣的：
使用流程：
第一步：zookeeper先搭建一個註冊中心。
第二步：生產者到zk註冊中心註冊發佈服務（發佈服務需要使用spring容器和dubbo標籤來發布服務。並且發佈服務時需要指定註冊中心的位置。）
第三步：消費者到zk註冊中心訂閱服務，zk發現生產者服務變動，會告知消費者，消費者對訂閱到的生產者服務進行調用。
Zookeeper註冊中心的作用主要就是註冊和發現服務的作用。類似於房產中介的作用，在系統中並不參與服務的調用及數據的傳輸。
？服務提供者暴露一個服務的詳細過程？
觀察dubbo的啓動日誌你會發現，dubbo的provider啓動主要是以下幾個過程：
1.首先provider啓動時，先把想要提供的服務暴露在本地。
2.然後再把服務暴露到遠程。(需要網絡通信,如下)
3.啓動netty服務，建立長連接。（注意和rpc的區別，rpc是消費者調服務器;netty是與zk建立長連接）
4.連接到註冊中心zk上。
5.然後監控zk上的消費服務。（dubbo-admin監控中心）
dubbo的所有provider把接口服務通過netty長連接，註冊到註冊中心zk上
？服務消費者消費一個服務的詳細過程？
消費者端，首先ReferenceConfig類的init方法調用Protocol的refer方法生成Invoker實例。
接下來把Invoker轉爲客戶端需要的接口。
？dubbo 負載均衡的實現原理？（本地負載均衡，效率比nginx高，所以不用nginx代理）
dubbo消費者從zookeeper取得了服務器列表之後，會根據配置的負載均衡策略（默認，是隨機調用其中的一個），執行RPC調用提供者，就實現了類似負載均衡，到底是不是真的負載，還得看策略。
由dubbo源碼裏實現的，裏面有各種負載均衡策略。
zookeeper自己本身沒有負載均衡功能，（但是他的特性可以輔助dubbo實現類似負載均衡的能力）
zookeeper只做服務發現，保存服務配置，然後dubbo中調用的時候，根據後臺服務器來做動態均衡
？dubbo 負載均衡策略有幾種？
1.random loadbalance
默認,隨機調用實現負載均衡，可以對 provider 不同實例設置不同的權重，會按照權重來負載均衡，權重越大分配流量越高，一般就用這個默認的就可以了。
2.roundrobin loadbalance
這個的話默認就是輪詢調用，均勻地將流量打到各個機器上去，但是如果各個機器的性能不一樣，容易導致性能差的機器負載過高。所以此時需要調整權重，讓性能差的機器承載權重小一些，流量少一些。
3.leastactive loadbalance
這個就是自動感知機器性能調用，如果某個機器性能越差，那麼接收的請求越少，越不活躍，此時就會給不活躍的性能差的機器更少的請求。
4.consistanthash loadbalance
一致性 Hash 算法，相同參數的請求一定分發到一個 provider 上去，provider 掛掉的時候，會基於虛擬節點均勻分配剩餘的流量，抖動不會太大。如果你需要的不是隨機負載均衡，是要一類請求都到一個節點，那就走這個一致性 Hash 策略。
？Dubbo有幾種容錯機制（某個機器掛了）？
1.failsafe 失敗安全，可以認爲是把錯誤吞掉（記錄日誌）
2.failover(默認) 重試其他服務器；retries(2)重試的次數，默認爲2次---故障轉移
3.failback 失敗後自動恢復
4.forking forks. 設置並行數
5.Broadcast 廣播，任意一臺報錯，則執行的方法報錯，通過cluster方式，配置制定的容錯方案
佈署存在的問題：
但是zk會出現這樣一種情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集羣都是不可用的，這就導致在選舉期間註冊服務癱瘓。
-----Dubbo------
？什麼是RPC框架？
是一種遠程過程調用的技術思想。
一、RPC 框架主要用來解決兩個問題：
解決分佈式系統中，服務之間的調用問題。
遠程調用時，要能夠像本地調用一樣方便，讓調用者感知不到遠程調用的邏輯。
二、調用過程涉及到一個過程和幾個概念:（RPC 的兩個核心模塊是：通訊和序列化透明）
Client：調用端，以本地調用方式調用服務端-------------發起調用，先到本地客服端stub
client stub：接收到調用後，負責將方法、參數等組裝成能夠進行網絡傳輸的消息體（序列化）；client stub找到服務地址，並將消息發送到服務端。-------本地客戶端stub把方法及參數序列化成消息體
server stub：收到消息後進行解碼（反序列化）；server stub根據解碼結果調用本地的服務；本地服務執行並將結果返回給server stub。server stub將返回結果打包成消息體（序列化）併發送至消費方。----------遠程服務端stub收到並把消息體反序列化，再調服務端本地方法，拿到結果再做序列化
client stub接收到消息，並進行解碼（反序列化），調用端得到最終結果。----------客戶端stub把消息體反序列化拿到結果
？RPC傳統有哪些調用方式？dubbo 跟傳統的http請求的區別？
一、答：scoket/netty（是scoket封裝升級版）/httpClient （注意Restful是短連接無狀態，Netty是長連接有狀態）
一、答：
dubbo設計之初基本都是考慮內網通訊，安全上基本沒什麼考慮，比http的安全差遠了。
rpc長連接、傳輸效率較高，適用於內部系統互聯；
http短連接，協議標準化且易讀，容易對接外部系統，適用於上層業務模塊
？Dubbo的核心特性(能做什麼)？
巧記：均衡註冊RPC灰度
高性能 RPC 分佈式服務框架（分佈式服務框架、高性能透明化的RPC遠程調用、SOA服務治理方案）,採用spring的配置方式進行配置，完全透明化的接入應用
一、dubbo的核心特性（核心服務）:
1.RPC長連接調用(序列化透明的遠程通訊): RPC 主要解決遠程調用問題，讓調用者無感知透明，屏蔽了遠程的調用細節
2.集羣負載均衡（服務器均勻調用）: 訪問量越來越大，一臺服務器不夠用了，那就得多放幾臺服務器。dubbo就會看哪臺服務器比較空閒了，然後讓它去處理一下該請求。
3.服務自動註冊發現（zk服務管理）: 引入了註冊中心zk服務，用來感知所有的服務，所有的服務都註冊到這個註冊中心裏，統一管理使服務調用方能動態的查找服務提供方（某服務機器掛了zk還會切別的），使地址透明，使服務提供方可以平滑增加或減少機器。
4.運行期流量調度（灰度發佈）：Dubbo 通過配置路由策略，可以實現灰度發佈，一部分使用舊代碼服務，一部分使用新的
5.可視化的服務治理和運維（SOA服務治理方案-監控，和3有點重合）：可以通過可視化頁面來實時查詢一些服務的狀態，包括基本信息、健康狀況等等，也可以去調節等等，方便來監控和運維
灰度發佈常見一般有三種方式:
-
Nginx+LUA方式
-
根據Cookie實現灰度發佈
-
根據來路IP實現灰度發佈
？@reference和@resource的區別？
@reference是dubbo註解。
@resource是spring 的,按變量名（就是id）注入，（@Resource默認按 byName（就是id）注入；@Autowired是註解類的，按byType注入，只能有一個子類，不然會異常）
？dubbo的服務降級目的是什麼(服務器壓力劇增如何保證服務正常)？降級分幾類？降級是怎麼操作的？
服務降級目的是爲了保證核心服務可用。
降級可以有幾個層面的分類：自動降級，人工降級；按照功能可以分爲：讀服務降級和寫服務降級；
1.對一些非核心服務進行人工降級，在大促之前通過降級開關關閉那些推薦內容，評價等對主流程序沒有影響的功能
2.故障降級，比如調用的遠程服務掛了，網絡故障，或者RPC服務返回異常。那麼可以直接降級，降級的方案比如設置默認值，採用兜底數據（系統推薦的行爲廣告掛了，可以提前準備靜態頁面做返回）等等
3.限流降級，在秒殺這種流量比較集中並且流量特別大的情況下，因爲突發訪問量特別大可能導致系統支撐不了。這個時候可以採用限流來限制訪問量。當達到閾值時，後續的請求被降級，比如進入排隊頁面，比如跳轉到錯誤頁面（活動火爆，請稍後重試）
Dubbo的降級方式：Mock (人工降級的話mock到不再彈出推薦內容，故障和限流分別mock向一些靜頁面和請稍後重試頁)
實現步驟
1.在client端創建一個testmock類，實現對應的接口（需要對哪個接口進行mock，就實現哪個）名稱必須以mock結尾
2.在client端的xml配置文件中，添加如下配置，增加一個mock屬性指向創建的testmock
3.模擬錯誤（設置timeout）模擬超時異常，運行測試代碼即可訪問到testmock這個類，當服務端故障解除以後，調用過程將恢復正常
？配置優先級別是怎麼樣的（以timeout爲例）？
1.以timeout爲例，顯示了配置的查找順序，其他retries，loadbalance等類似。
（1）方法級優先，接口級次之，全局配置在次之
（2）如果級別一樣，則消費方優先，提供方次之
（3）其中，服務提供方配置，通過URL經由註冊中心傳遞給消費方
2.建議由服務提供方設置超時，因爲一個方法需要執行多長時間，服務提供方更清楚，如果一個消費方同時引用多個服務，就不需要關心每個服務的超時設置。
？SpringBoot與Dubbo整合的三種方式？
目的都是把服務提供者或消費端信息（暴露或提供哪個類），zk信息，監控中心配置注入到Dubbo容器裏
1、application.properties中配置自動掃配置包路徑等，因爲集成了dubbo的所有屬性，只需要賦值就行。duboo自帶的@Service註解來暴露服務，使用@Reference來引用服務（啓動類裏要加@EnableDubbo來自動掃配置包路徑下的帶@Service的類發佈服務）
2、引入dubbo.xml配置文件，保留Spring的方式，啓動類中要通過 @ImportResource 註解引入配置xml，服務dubbo.xml及提供者provider.xml，（服務方暴露服務有兩種方式：1）@Service註解只能暴露整個類服務 2）dubbo.xml配置裏能指定暴露某類某個方法）
3、使用註解API的方式（註解類配置類），比如***Config 註解類的配置主要有三點：①註解類加註解@Configuration；②每個註解項添加@Bean注入到容器中；③準確使用註解API。定義完註解類之後，還需要配：@DubboComponentScan註解指定dubbo掃描配置類路徑，這裏值配你要配置所在路徑就好。
----- zookeeper------
？Zookeeper的作用？
分佈式的註冊中心，通過心跳機制可以檢測掛掉的機器並將掛掉機器的ip和服務名對應關係從列表中刪除(集羣是多個機器的ip對應一個服務名)，如果無服務機器存活會通知消費者。
優點：
1.負載均衡，爲了分流而存在的，一個ZooKeeper羣配合相應的Web應用就可以很容易達到負載均衡；
2.資源同步，單單有負載均衡還不 夠，節點之間的數據和資源需要同步，ZooKeeper集羣就天然具備有這樣的功能；
3.命名服務，將樹狀結構用於維護全局的服務地址列表，服務提供者在啓動 的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務的發佈（serviceName和URL地址分別就是持久節點和臨時節點，臨時節點是可以頻繁變更IP這些的）
2.還有分佈式鎖，Mast選舉等