Dubbo 服務注冊與發現的流程？
-
Provider(提供者)綁定指定端口并啟動服務
指供者連接配接注冊中心，并發本機 IP、端口、應用資訊和提供服務資訊發送至注冊中心存儲
- Consumer(消費者），連接配接注冊中心 ，并發送應用資訊、所求服務信
息至注冊中心
注冊中心根據 消費 者所求服務資訊比對對應的提供者清單發送至
Consumer 應用緩存。
Consumer 在發起遠端調用時基于緩存的消費者清單擇其一發起調
用。
Provider 狀态變更會實時通知注冊中心、在由注冊中心實時推送至
Consumer
設計的原因：
Consumer 與 Provider 解偶，雙方都可以橫向增減節點數。
注冊中心對本身可做對等叢集，可動态增減節點，并且任意一台宕掉
後，将自動切換到另一台
去中心化，雙方不直接依懶注冊中心，即使注冊中心全部當機短時間
内也不會影響服務的調用
服務提供者無狀态，任意一台宕掉後，不影響使用
Dubbo 的架構設計？
Dubbo 架構設計一共劃分了 10 個層：
服務接口層（Service）：該層是與實際業務邏輯相關的，根據服務提
供方和服務消費方的業務設計對應的接口和實作。
配置層（Config）：對外配置接口，以 ServiceConfig 和
ReferenceConfig 為中心。
服務代理層（Proxy）：服務接口透明代理，生成服務的用戶端 Stub
和伺服器端 Skeleton。
服務注冊層（Registry）：封裝服務位址的注冊與發現，以服務 URL
為中心。
叢集層（Cluster）：封裝多個提供者的路由及負載均衡，并橋接注冊
中心，以 Invoker 為中心。
監控層（Monitor）：RPC 調用次數和調用時間監控。
遠端調用層（Protocol）：封将 RPC 調用，以 Invocation 和 Result
為中心，擴充接口為 Protocol、Invoker 和 Exporter。 資訊交換層（Exchange）：封裝請求響應模式，同步轉異步，以
Request 和 Response 為中心。
網絡傳輸層（Transport）：抽象 mina 和 netty 為統一接口，以
Message 為中心。
Dubbo 的服務調用流程？
Dubbo 支援哪些協定，每種協定的應用場景，優缺點？
dubbo： 單一長連接配接和 NIO 異步通訊，适合大并發小資料量的服務
調用，以及消費者遠大于提供者。傳輸協定 TCP，異步，Hessian 序
列化；
rmi： 采用 JDK 标準的 rmi 協定實作，傳輸參數和傳回參數對象需要
實作 Serializable 接口，使用 java 标準序列化機制，使用阻塞式短連
接，傳輸資料包大小混合，消費者和提供者個數差不多，可傳檔案，
傳輸協定 TCP。 多個短連接配接，TCP 協定傳輸，同步傳輸，适用正常的
遠端服務調用和 rmi 互操作。在依賴低版本的 Common-Collections
包，java 序列化存在安全漏洞；
webservice： 基于 WebService 的遠端調用協定，內建 CXF 實作，
提供和原生 WebService 的互操作。多個短連接配接，基于 HTTP 傳輸，
同步傳輸，适用系統內建和跨語言調用；
http： 基于 Http 表單送出的遠端調用協定，使用 Spring 的
HttpInvoke 實作。多個短連接配接，傳輸協定 HTTP，傳入參數大小混
合，提供者個數多于消費者，需要給應用程式和浏覽器 JS 調用；
hessian： 內建 Hessian 服務，基于 HTTP 通訊，采用 Servlet 暴露
服務，Dubbo 内嵌 Jetty 作為伺服器時預設實作，提供與 Hession 服
務互操作。多個短連接配接，同步 HTTP 傳輸，Hessian 序列化，傳入參
數較大，提供者大于消費者，提供者壓力較大，可傳檔案；
memcache： 基于 memcached 實作的 RPC 協定
redis： 基于 redis 實作的 RPC 協定
dubbo 推薦用什麼協定？
預設使用 dubbo 協定
Dubbo 有些哪些注冊中心？
Multicast 注冊中心： Multicast 注冊中心不需要任何中心節點，隻
要廣播位址，就能進行服務注冊和發現。基于網絡中多點傳播傳輸實作；
Zookeeper 注冊中心： 基于分布式協調系統 Zookeeper 實作，采用
Zookeeper 的 watch 機制實作資料變更；
redis 注冊中心： 基于 redis 實作，采用 key/Map 存儲，住 key 存儲
服務名和類型，Map 中 key 存儲服務 URL，value 服務過期時間。基
于 redis 的釋出/訂閱模式通知資料變更；
Simple 注冊中心
Dubbo 預設采用注冊中心？
采用 Zookeeper
為什麼需要服務治理？
過多的服務 URL 配置困難
負載均衡配置設定節點壓力過大的情況下也需要部署叢集
服務依賴混亂，啟動順序不清晰
過多服務導緻性能名額分析難度較大，需要監控
Dubbo 的注冊中心叢集挂掉，釋出者和訂閱者之間還能通信麼？
可以的，啟動 dubbo 時，消費者會從 zookeeper 拉取注冊的生産者
的位址接口等資料，緩存在本地。
每次調用時，按照本地存儲的位址進行調用。
Dubbo 與 Spring 的關系？
Dubbo 采用全 Spring 配置方式，透明化接入應用，對應用沒有任何
API 侵入，隻需用 Spring 加載 Dubbo 的配置即可，Dubbo 基于
Spring 的 Schema 擴充進行加載。
Dubbo 使用的是什麼通信架構?
預設使用 NIO Netty 架構
Dubbo 叢集提供了哪些負載均衡政策？
Random LoadBalance: 随機選取提供者政策，有利于動态調整提供
者權重。截面碰撞率高，調用次數越多，分布越均勻；
RoundRobin LoadBalance: 輪循選取提供者政策，平均分布，但是
存在請求累積的問題；
LeastActive LoadBalance: 最少活躍調用政策，解決慢提供者接收
更少的請求；
ConstantHash LoadBalance: 一緻性 Hash 政策，使相同參數請求
總是發到同一提供者，一台機器當機，可以基于虛拟節點，分攤至其
他提供者，避免引起提供者的劇烈變動；
預設時為 Random 随機調用
Dubbo 的叢集容錯方案有哪些？
Failover Cluster
失敗自動切換，當出現失敗，重試其它伺服器。通常用于讀操作，但
重試會帶來更長延遲。
Failfast Cluster
快速失敗，隻發起一次調用，失敗立即報錯。通常用于非幂等性的寫
操作，比如新增記錄。
Failsafe Cluster
失敗安全，出現異常時，直接忽略。通常用于寫入審計日志等操作。
Failback Cluster
失敗自動恢複，背景記錄失敗請求，定時重發。通常用于消息通知操
作。
Forking Cluster
并行調用多個伺服器，隻要一個成功即傳回。通常用于實時性要求較
高的讀操作，但需要浪費更多服務資源。可通過 forks=“2” 來設定最
大并行數。
Broadcast Cluster
廣播調用所有提供者，逐個調用，任意一台報錯則報錯 。通常用于通
知所有提供者更新緩存或日志等本地資源資訊。
Dubbo 的預設叢集容錯方案？
Failover Cluster
Dubbo 支援哪些序列化方式？
預設使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列
化。
Dubbo 逾時時間怎樣設定？
Dubbo 逾時時間設定有兩種方式：
服務提供者端設定逾時時間，在 Dubbo 的使用者文檔中，推薦如果能
在服務端多配置就盡量多配置，因為服務提供者比消費者更清楚自己
提供的服務特性。
服務消費者端設定逾時時間，如果在消費者端設定了逾時時間，以消
費者端為主，即優先級更高。因為服務調用方設定逾時時間控制性更
靈活。如果消費方逾時，服務端線程不會定制，會産生警告。
服務調用逾時問題怎麼解決？
dubbo 在調用服務不成功時，預設是會重試兩次的。
Dubbo 在安全機制方面是如何解決？
Dubbo 通過 Token 令牌防止使用者繞過注冊中心直連，然後在注冊中
心上管理授權。Dubbo 還提供服務黑白名單，來控制服務所允許的調
用方。
Dubbo 和 Dubbox 之間的差別？
dubbox 基于 dubbo 上做了一些擴充，如加了服務可 restful 調
用，更新了開源元件等。
Dubbo 和 Spring Cloud 的關系？
Dubbo 是 SOA 時代的産物，它的關注點主要在于服務的調用，流
量分發、流量監控和熔斷。而 Spring Cloud 誕生于微服務架構時
代，考慮的是微服務治理的方方面面，另外由于依托了 Spirng、
Spirng Boot 的優勢之上，兩個架構在開始目标就不一緻，Dubbo
定位服務治理、Spirng Cloud 是一個生态。
Dubbo 和 Spring Cloud 的差別？
最大的差別：Dubbo 底層是使用 Netty 這樣的 NIO 架構，是基于
TCP 協定傳輸的，配合以 Hession 序列化完成 RPC 通信。
而 SpringCloud 是基于 Http 協定+Rest 接口調用遠端過程的通信，
相對來說，Http 請求會有更大的封包，占的帶寬也會更多。但是
REST 相比 RPC 更為靈活，服務提供方和調用方的依賴隻依靠一紙契
約，不存在代碼級别的強依賴。
如果注冊中心叢集都挂掉，釋出者和訂閱者之間還能通信嗎？
Dubbo 中 zookeeper 做注冊中心。
可以通信。
啟動 dubbo 時，消費者會從 zk 拉取注冊的生産者的位址接口等資料，緩存在本地。
每次調用時，按照本地存儲的位址進行調用；
注冊中心對等叢集，任意一台當機後，将會切換到另一台；
注冊中心全部當機後，服務的提供者和消費者仍能通過本地緩存通訊。
服務提供者無狀态，任一台當機後，不影響使用；
服務提供者全部當機，服務消費者會無法使用，并無限次重連等待服務者恢複；
挂掉是不要緊的，但前提是你沒有增加新的服務，如果你要調用新的服務，則是不能辦到的。
服務負載均衡政策？
Random LoadBalance
随機，按權重設定随機機率。在一個截面上碰撞的機率高，但調用量越大分布越均勻，而且按機率使用權重後也比較均勻，有利于動态調整提供者權重。(權重可以在 dubbo 管控台配置)
RoundRobin LoadBalance
輪循，按公約後的權重設定輪循比率。存在慢的提供者累積請求問題，比如：第二台機器很慢，但沒挂，當請求調到第二台時就卡在那，久而久之，所有請求都卡在調到第二台上。
LeastActive LoadBalance
最少活躍調用數，相同活躍數的随機，活躍數指調用前後計數差。使慢的提供者收到更少請求，因為越慢的提供者的調用前後計數差會越大。
ConsistentHash LoadBalance
一緻性 Hash，相同參數的請求總是發到同一提供者。當某一台提供者挂時，原本發往該提供者的請求，基于虛拟節點，平攤到其它提供者，不會引起劇烈變動。預設隻對第一個參數 Hash，如果要修改，請配置
<dubbo:parameter key="hash.arguments" value="0,1" /> 預設用 160 份虛拟節點，如果要修改，請配置
<dubbo:parameter key="hash.nodes" value="320" />
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)