dubbo 進行服務治理、服務降級、失敗重試

面試題

如何基於 dubbo 進行服務治理、服務降級、失敗重試以及超時重試？

面試官心理分析

服務治理，這個問題若是問你，其實就是看看你有沒有服務治理的思想，由於這個是作過複雜微服務的人確定會遇到的一個問題。

服務降級，這個是涉及到複雜分佈式系統中必備的一個話題，由於分佈式系統互相來回調用，任何一個系統故障了，你不降級，直接就全盤崩潰？那就太坑爹了吧。

失敗重試，分佈式系統中網絡請求如此頻繁，要是由於網絡問題不當心失敗了一次，是否是要重試？

超時重試，同上，若是不當心網絡慢一點，超時了，如何重試？

面試題剖析

服務治理

1. 調用鏈路自動生成

一個大型的分佈式系統，或者說是用如今流行的微服務架構來講吧，分佈式系統由大量的服務組成。那麼這些服務之間互相是如何調用的？調用鏈路是啥？說實話，幾乎到後面沒人搞的清楚了，由於服務實在太多了，可能幾百個甚至幾千個服務。

那就須要基於 dubbo 作的分佈式系統中，對各個服務之間的調用自動記錄下來，而後自動將各個服務之間的依賴關係和調用鏈路生成出來，作成一張圖，顯示出來，你們才能夠看到對吧。

)

2. 服務訪問壓力以及時長統計

須要自動統計各個接口和服務之間的調用次數以及訪問延時，並且要分紅兩個級別。

• 一個級別是接口粒度，就是每一個服務的每一個接口天天被調用多少次，TP50/TP90/TP99，三個檔次的請求延時分別是多少；
• 第二個級別是從源頭入口開始，一個完整的請求鏈路通過幾十個服務以後，完成一次請求，天天全鏈路走多少次，全鏈路請求延時的 TP50/TP90/TP99，分別是多少。

這些東西都搞定了以後，後面才能夠來看當前系統的壓力主要在哪裏，如何來擴容和優化啊。

3. 其它

• 服務分層（避免循環依賴）
• 調用鏈路失敗監控和報警
• 服務鑑權
• 每一個服務的可用性的監控（接口調用成功率？幾個 9？99.99%，99.9%，99%）

服務降級

好比說服務 A 調用服務 B，結果服務 B 掛掉了，服務 A 重試幾回調用服務 B，仍是不行，那麼直接降級，走一個備用的邏輯，給用戶返回響應。

舉個栗子，咱們有接口 HelloService。HelloServiceImpl 有該接口的具體實現。

public interface HelloService {

   void sayHello();

}

public class HelloServiceImpl implements HelloService {

    public void sayHello() {
        System.out.println("hello world......");
    }
	
}

複製代碼

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <dubbo:application name="dubbo-provider" />
    <dubbo:registry address="zookeeper://127.0.0.1:2181" />
    <dubbo:protocol name="dubbo" port="20880" />
    <dubbo:service interface="com.zhss.service.HelloService" ref="helloServiceImpl" timeout="10000" />
    <bean id="helloServiceImpl" class="com.zhss.service.HelloServiceImpl" />

</beans>

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <dubbo:application name="dubbo-consumer" />

    <dubbo:registry address="zookeeper://127.0.0.1:2181" />

    <dubbo:reference id="fooService" interface="com.test.service.FooService" timeout="10000" check="false" mock="return null">
    </dubbo:reference>

</beans>

複製代碼

咱們調用接口失敗的時候，能夠經過 mock 統一返回 null。

mock 的值也能夠修改成 true，而後再跟接口同一個路徑下實現一個 Mock 類，命名規則是 「接口名稱+Mock」 後綴。而後在 Mock 類裏實現本身的降級邏輯。

public class HelloServiceMock implements HelloService {

    public void sayHello() {
        // 降級邏輯
    }
}

複製代碼

失敗重試和超時重試

所謂失敗重試，就是 consumer 調用 provider 要是失敗了，好比拋異常了，此時應該是能夠重試的，或者調用超時了也能夠重試。配置以下：

<dubbo:reference id="xxxx" interface="xx" check="true" async="false" retries="3" timeout="2000"/>
複製代碼

舉個栗子。

某個服務的接口，要耗費 5s，你這邊不能幹等着，你這邊配置了 timeout 以後，我等待 2s，還沒返回，我直接就撤了，不能幹等你。

能夠結合大家公司具體的場景來講說你是怎麼設置這些參數的：

• timeout：通常設置爲 200ms，咱們認爲不能超過 200ms 還沒返回。
• retries：設置 retries，通常是在讀請求的時候，好比你要查詢個數據，你能夠設置個 retries，若是第一次沒讀到，報錯，重試指定的次數，嘗試再次讀取。