面試官心理分析
服務治理，這個問題如果問你，其實就是看看你有沒有服務治理的思想，因為這個是做過復雜微服務的人肯定會遇到的一個問題。
服務降級，這個是涉及到復雜分布式系統(tǒng)中必備的一個話題，因為分布式系統(tǒng)互相來回調用，任何一個系統(tǒng)故障了，你不降級，直接就全盤崩潰？那就太坑爹了吧。
失敗重試，分布式系統(tǒng)中網(wǎng)絡請求如此頻繁，要是因為網(wǎng)絡問題不小心失敗了一次，是不是要重試？
超時重試，跟上面一樣，如果不小心網(wǎng)絡慢一點，超時了，如何重試？
面試題剖析
服務治理
1. 調用鏈路自動生成
一個大型的分布式系統(tǒng)，或者說是用現(xiàn)在流行的微服務架構來說吧，分布式系統(tǒng)由大量的服務組成。那么
這些服務之間互相是如何調用的？調用鏈路是啥？說實話，幾乎到后面沒人搞的清楚了，因為服務實在太多了，可能幾百個甚至幾千個服務。
那就需要基于 dubbo 做的分布式系統(tǒng)中，對各個服務之間的調用自動記錄下來，然后自動將各個服務之間的依賴關系和調用鏈路生成出來，做成一張圖，顯示出來，大家才可以看到對吧。
2. 服務訪問壓力以及時長統(tǒng)計
需要自動統(tǒng)計各個接口和服務之間的調用次數(shù)以及訪問延時，而且要分成兩個級別。
1.一個級別是接口粒度，就是每個服務的每個接口每天被調用多少次，TP50/TP90/TP99，三個檔次的請求延時分別是多少；
2.第二個級別是從源頭入口開始，一個完整的請求鏈路經(jīng)過幾十個服務之后，完成一次請求，每天全鏈路走多少次，全鏈路請求延時的 TP50/TP90/TP99，分別是多少。
這些東西都搞定了之后，后面才可以來看當前系統(tǒng)的壓力主要在哪里，如何來擴容和優(yōu)化啊。
3. 其它
????????? 服務分層（避免循環(huán)依賴）
????????? 調用鏈路失敗監(jiān)控和報警
????????? 服務鑒權
????????? 每個服務的可用性的監(jiān)控（接口調用成功率？幾個 9？99.99%，99.9%，99%）
服務降級
比如說服務 A 調用服務 B，結果服務 B 掛掉了，服務 A 重試幾次調用服務 B，還是不行，那么直接降級，走一個備用的邏輯，給用戶返回響應。
舉個栗子，我們有接口 HelloService。HelloServiceImpl 有該接口的具體實現(xiàn)。
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 統(tǒng)一返回 null。
mock 的值也可以修改為 true，然后再跟接口同一個路徑下實現(xiàn)一個 Mock 類，命名規(guī)則是 “接口名稱+Mock” 后綴。然后在 Mock 類里實現(xiàn)自己的降級邏輯。
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，還沒返回，我直接就撤了，不能干等你。
可以結合你們公司具體的場景來說說你是怎么設置這些參數(shù)的：
? ? ?timeout：一般設置為 200ms，我們認為不能超過 200ms 還沒返回。
? ? ?retries：設置 retries，一般是在讀請求的時候，比如你要查詢個數(shù)據(jù)，你可以設置個 retries，如果第一次沒讀到，報錯，重試指定的次數(shù)，嘗試再次讀取。??
