Dubbo知識點

 

1.Dubbo是什麼？

        40道題目 參考： http://www.javashuo.com/article/p-pjrygoyr-ha.html

        dubbo系列講解   https://www.cnblogs.com/wangzhuxing/category/1308133.html

        dubbo官方文檔   http://dubbo.apache.org/zh-cn/docs/dev/impls/protocol.html

 

Dubbo是阿里巴巴開源的一個分佈式、高性能、透明化的 RPC 服務框架，提供服務自動註冊、自動發現等高效服務治理方案， 能夠和 Spring框架無縫集成。

 

    服務治理緣由：

          過多的服務URL配置困難

            負載均衡分配節點壓力過大的狀況下也須要部署集羣

            服務依賴混亂，啓動順序不清晰

            過多服務致使性能指標分析難度較大，須要監控

       

　　

 

  

2.dubbo底層實現原理？

 

Dubbo缺省協議採用單一長鏈接和NIO異步通信，適合於小數據量大併發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的狀況。

 客服端一個線程調用遠程接口，生成一個惟一的ID（好比一段隨機字符串，UUID等），Dubbo是使用AtomicLong從0開始累計數字的

2.   將打包的方法調用信息（如調用的接口名稱，方法名稱，參數值列表等），和處理結果的回調對象callback，所有封裝在一塊兒，組成一個對象object

3.   向專門存放調用信息的全局ConcurrentHashMap裏面put(ID, object)

4.   將ID和打包的方法調用信息封裝成一對象connRequest，使用IoSession.write(connRequest)異步發送出去

5.   當前線程再使用callback的get()方法試圖獲取遠程返回的結果，在get()內部，則使用synchronized獲取回調對象callback的鎖， 再先檢測是否已經獲取到結果，若是沒有，而後調用callback的wait()方法，釋放callback上的鎖，讓當前線程處於等待狀態。

6.   服務端接收到請求並處理後，將結果（此結果中包含了前面的ID，即回傳）發送給客戶端，客戶端socket鏈接上專門監聽消息的線程收到消息，分析結果，取到ID，再從前面的ConcurrentHashMap裏面get(ID)，從而找到callback，將方法調用結果設置到callback對象裏。

7.   監聽線程接着使用synchronized獲取回調對象callback的鎖（由於前面調用過wait()，那個線程已釋放callback的鎖了），再notifyAll()，喚醒前面處於等待狀態的線程繼續執行（callback的get()方法繼續執行就能拿到調用結果了），至此，整個過程結束。

 

三、dubbo都支持什麼協議，推薦用哪一種？ protocol屬性

      dubbo： 單一長鏈接和NIO異步通信，適合大併發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議TCP，異步，Hessian序列化；

     rmi： 採用JDK標準的rmi協議實現，傳輸參數和返回參數對象須要實現Serializable接口，使用java標準序列化機制，使用阻塞式短鏈接，傳輸數據包大小混合，消費者和提供者個數差很少，可傳文件，傳輸協議TCP。 多個短鏈接，TCP協議傳輸，同步傳輸，適用常規的遠程服務調用和rmi互操做。在依賴低版本的Common-Collections包，java序列化存在安全漏洞；

    webservice： 基於WebService的遠程調用協議，集成CXF實現，提供和原生WebService的互操做。多個短鏈接，同步傳輸，適用系統集成和跨語言調用，走SOAP文本序列化。

    http： 基於Http表單提交的遠程調用協議，使用Spring的HttpInvoke實現。多個短鏈接， JSON序列化。

    hessian： 集成Hessian服務，基於HTTP通信，採用Servlet暴露服務，Dubbo內嵌Jetty做爲服務器時默認實現，提供與Hession服務互操做。多個短鏈接，同步HTTP傳輸，Hessian序列化，傳入參數較大，提供者大於消費者，提供者壓力較大，可傳文件；

    redis： 基於redis實現的RPC協議

 

四、dubbo哪幾種節點角色？

Provider: 暴露服務的服務提供方。

Consumer: 調用遠程服務的服務消費方。

Registry: 服務註冊與發現的註冊中心。

Monitor: 統計服務的調用次調和調用時間的監控中心。

Container: 服務運行容器。

 　　　　

　　

 

五、dubbo服務註冊與發現的流程？

 

Provider(提供者)綁定指定端口並啓動服務，鏈接註冊中心，併發本機IP、端口、應用信息和提供服務信息發送至註冊中心存儲

Consumer(消費者），鏈接註冊中心 ，併發送應用信息、所求服務信息至註冊中心

註冊中心根據 消費 者所求服務信息匹配對應的提供者列表發送至Consumer 應用緩存。

Consumer 在發起遠程調用時基於緩存的消費者列表擇其一發起調用。

Provider 狀態變動會實時通知註冊中心、在由註冊中心實時推送至Consumer

 

六、Dubbo內置了哪幾種服務容器？

    

目前已有的容器實現 Spring Container、Jetty Container、Log4j Container、Logback Container。dubbo的服務容器只是一個簡單的 Main 方法，並加載一個簡單的 Spring 容器，用於暴露服務。不須要web容器。

 

 

7.dubbo的 SPI擴展

       SPI(Service Provider Interface)服務提供商接口， 是一種動態替換髮現服務實現者的機制。 JDK 爲SPI提供了工具類 java.util.ServiceLoader，指定加載 resource目錄META-INF/services下，文件名就是服務接口的全限定名。缺點：ServiceLoader也算是使用的延遲加載。可是經過遍歷獲取，接口的實現類所有實例化一遍，不靈活浪費。

       Dubbo SPI對JDK SPI進行了擴展， 由原來的提供者類的全限定名列表改爲了KV形式的列表，這也致使了Dubbo中沒法直接使用JDK ServiceLoader，因此，與之對應的，在Dubbo中有 ExtensionLoader是擴展點載入器，用於載入Dubbo中的各類可配置組件。Dubbo默認依次掃描META-INF/dubbo/internal/、META-INF/dubbo/、META-INF/services/三個classpath目錄下的配置文件。配置文件以具體擴展接口全名命名。

 

　　

 

    參考地址： https://www.jianshu.com/p/7daa38fc9711

 

八、Dubbo默認使用什麼註冊中心，還有別的選擇嗎？

         Zookeeper註冊中心： 基於分佈式協調系統Zookeeper實現，採用Zookeeper的watcher機制實現數據變動；

        redis註冊中心： 基於redis實現，採用key/Map存儲，住key存儲服務名和類型，Map中key存儲服務URL，value服務過時時間。基於redis的發佈/訂閱模式通知數據變動；

        Multicast註冊中心： Multicast註冊中心不須要任何中心節點，只要廣播地址，就能進行服務註冊和發現。基於網絡中組播傳輸實現；

 

 

九、Dubbo有哪幾種配置方式？

        1. XML 配置文件方式；

        2. properties 配置文件方式(Dubbo 將自動加載 classpath 根目錄下的 dubbo.properties)；

        3. annotation 配置方式；

        4. API 配置方式；

10.在Provider能夠配置的屬性

        timeout，方法調用超時 ，若是消費者也配置了，以消費者爲準。

        retries，失敗重試次數，缺省是2（表示加上第一次調用，會調用3次）

        loadbalance，負載均衡算法（有多個Provider時，如何挑選Provider調用），缺省是隨機（random）。

        actives，消費者端，最大併發調用限制，即當Consumer對一個服務的併發調用到上限後，新調用會Wait直到超時。

        group，針對接口多實現配置

        version  接口實現升級版本控制

        check=「false」消費者啓動不檢查是否可用，消費者配置。

     以 timeout 爲例，顯示了配置的查找順序，其它 retries, loadbalance, actives 等相似   

• 方法級優先，接口級次之，全局配置再次之。
• 若是級別同樣，則消費方優先，提供方次之。

 

11.Dubbo服務之間的調用是阻塞的嗎？
        默認是同步等待結果阻塞的，支持異步調用。
        Dubbo 是基於 NIO 的非阻塞實現並行調用，客戶端不須要啓動多線程便可完成並行調用多個遠程服務，相對多線程開銷較小，異步調用會返回一個 Future 對象。

 

        

12.Dubbo的管理控制檯能作什麼？
管理控制檯主要包含：路由規則，動態配置，服務降級，訪問控制，權重調整，負載均衡，等管理功能。    

 

13.在使用過程當中都遇到了些什麼問題？
Dubbo 的設計目的是爲了知足高併發小數據量的 rpc 調用，在大數據量下的性能表現並很差，建議使用 rmi 或 http 協議。

 

 

1四、Dubbo 中止維護了嗎？

 

     Dubbo 2014 年開始中止維護過幾年，17 年開始從新維護，並進入了 Apache 項目。

     Dubbox 是繼 Dubbo 中止維護後，噹噹網基於 Dubbo 作的一個擴展項目，如加了服務可 Restful 調用，更新了開源組件等。

 

 

1五、說說 Dubbo 服務暴露的過程。

 

              Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置便可，Dubbo基於Spring的Schema擴展進行加載。

            基於 dubbo.jar 內的 META-INF/spring.handlers 配置，Spring 在遇到 dubbo 名稱空間時，會回調 DubboNamespaceHandler。

            全部 dubbo 的標籤，都統一用 DubboBeanDefinitionParser 進行解析，基於一對一屬性映射，將 XML 標籤解析爲 Bean 對象。

            在 ServiceConfig.export() 或 ReferenceConfig.get() 初始化時，將 Bean 對象轉換 URL 格式，全部 Bean 屬性轉成 URL 的參數。

            而後將 URL 傳給 協議擴展點，基於擴展點的 擴展點自適應機制，根據 URL 的協議頭，進行不一樣協議的服務暴露或引用。

 

    ServiceBean 同時也是service標籤解析以後的bean之一，繼承ServiceConfig

        該Bean實現了不少spring接口，關於 InitializingBean， DisposableBean， ApplicationContextAware， BeanNameAware。

    Spring初始化完成Bean的組裝，會調用InitializingBean的afterPropertiesSet方法，在Spring容器加載完成，會接收到事件ContextRefreshedEvent，調用ApplicationListener的onApplicationEvent方法。


在 afterPropertiesSet中，和 onApplicationEvent中，會調用 export()，在 export()中， 會暴露dubbo服務，具體區別在因而否配置了 delay屬性，是否延遲暴露，若是 delay不爲 null，或者不爲 -1時，會在 afterPropertiesSet中調用 export()暴露dubbo服務，若是爲 null,或者爲 -1時，會在Spring容器初始化完成，接收到 ContextRefreshedEvent事件，調用 onApplicationEvent，暴露dubbo服務。

        

 

　　　　

 

 

1七、如何解決服務調用鏈過長的問題？

Dubbo 可使用 Pinpoint 和 Apache Skywalking(Incubator) 實現分佈式服務追蹤，固然還有其餘不少方案。能夠結合zipkin實現分佈式服務追蹤。

 

 

1八、註冊了多個同同樣的服務，若是測試指定的某一個服務呢？

能夠配置環境點對點直連，繞過註冊中心。Dubbo 容許配置多協議，在不一樣服務上支持不一樣協議或者同一服務上同時支持多種協議。

 

 

1九、Dubbo 和 Spring Cloud 有什麼區別？

 

    1）通訊方式不一樣，Dubbo 使用的是 RPC 通訊，而 Spring Cloud 使用的是 HTTP RESTFul 方式。
   2）組成部分不一樣

 

 

20、dubbo集羣負載均衡策略？loadbalance 屬性

     隨機，按權重設置隨機機率（默認）。

     輪詢，按公約後的權重設置輪詢比率

     最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差。

     一致性 Hash，相同參數的請求老是發到同一提供者。

默認使用 javassist 動態字節碼生成，建立代理類。

可是能夠經過 spi 擴展機制配置本身的動態代理策略。   

 

　　

　　

 

21.dubbo隱士傳參數

 

        有些參數須要RPC帶着傳遞，可是又不想寫入到業務代碼裏。好比實現dubbo調用鏈。但是使用dubbo的隱式傳參，能夠經過  RpcContext (ThreadLocal 實現)上的  setAttachment 和  getAttachment 在服務消費方和提供方之間進行參數的隱式傳遞。實現filter 接口。

        RpcContext.getContext().setAttachment("index",  "1"); // 隱式傳參，後面的遠程調用都會隱式將這些參數發送到服務器端，相似cookie，用於框架集成，不建議常規業務使用

        

 　　　　

 

 

20、dubbo 熔斷限流降級

 

         http://www.javashuo.com/article/p-fnynveto-nc.html

 

 

 

2一、服務提供者能實現失效踢出是什麼原理？

        

 

 

 

2二、Dubbo的集羣容錯方案有哪些？

                Failover Cluster  失敗自動切換，重試 共3次，一般用於讀操做。默認的

                Failfast Cluster    只發起一次調用，失敗即報錯。用於寫入記錄。

                Failsafe Cluster   失敗安全，出現異常忽略。用於寫日誌等。

                Failback Cluster  失敗後，後臺記錄失敗請求，定時重發。用於消息通知。

                Forking Cluster  並行調用多個服務器，成功一個即返回，經過forks="N" 設置並行數。

                Broadcast Cluster 廣播調用模式，逐個調用，任意一臺報錯即報錯。用於刷新緩存

 

 

2三、Zookeeper是什麼框架？

            參考： http://www.javashuo.com/article/p-hytevajq-gc.html

            ZooKeeper是一個分佈式應用程序協調服務，解決了分佈式一致性問題，是集羣的管理者提供文件系統和通知機制。用於dubbo框架的註冊中心，提供註冊服務與負載均衡功能。Dubbo框架的提供者會向Zookeeper下的provider目錄註冊本身的URL。消費者訂閱提供者的註冊URL，並在consumer下注冊本身的URL,以便在後續執行中調用提供者。消費者獲取到URL以後，netty調用提供者提供的服務。

 

 

 

ZAB協議

         Zookeeper 的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫作Zab協議。Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和 leader的狀態同步之後，恢復模式就結束了。狀態同步保證了leader和Server具備相同的系統狀態。

 

 

 

zk集羣 至少須要 集羣規則爲2N+1臺，N>0，即至少3臺。主要是爲了選舉算法。

 

Zookeeper分佈式鎖 

        基於 zookeeper的一致性文件系統 實現的分佈式鎖，性 能開銷比較高。由於其須要動態產生、銷燬瞬時節點來實現鎖功能。

        實現原理在zookeeper上的與該功能對應的指定節點的目錄下，生成一個惟一的瞬時有序節點。判斷是否獲取鎖的方式很簡單，只須要判斷有序節點中序號最小的一個。當釋放鎖的時候，只需將這個瞬時節點刪除便可。同時，其能夠避免服務宕機致使的鎖沒法釋放，而產生的死鎖問題。直接採用zookeeper第三方庫curator便可方便地實現分佈式鎖。

                

 

1）zookeeper是一個開源的分佈式協調服務框架。

2）應用場景：分佈式通知/協調、負載均衡、配置中心、分佈式鎖、分佈式隊列等。

3）使用ZAB協議。

4）Paxos算法。

5）選舉算法及流程。

6）節點類型：持久節點、持久順序節點、臨時節點、臨時順序節點。

7）不是永久的，一次性的，須要藉助第三方工具實現重複註冊。

8）部署模式：單機模式、僞集羣模式、集羣模式。

9）集羣角色：leader、foller、observer。

10）集羣規則爲2N+1臺，N>0，即3臺。

11）集羣須要一半以上的機器可用，因此，3臺掛掉1臺還能工做，2臺不能。

12）3.5版本開始支持動態擴容。

13）java客戶端：zk自帶的zkclient及Apache開源的Curator。

14）chubby是google的，徹底實現paxos算法，不開源。zookeeper是chubby的開源實現，使用zab協議，paxos算法的變種。

15）經常使用命令：ls get set create delete等。

 

Zookeeper 的節點？

zookeeper節點分兩種（持久節點Persistent、臨時節點Ephemeral），若是嚴謹的話還須要加上時序節點