一個線上問題的思考:Eureka註冊中心集羣如何實現客戶端請求負載及故障轉移?

前言

先拋一個問題給我聰明的讀者,若是大家使用微服務SpringCloud-Netflix進行業務開發,那麼線上註冊中心確定也是用了集羣部署,問題來了:java

你瞭解Eureka註冊中心集羣如何實現客戶端請求負載及故障轉移嗎?算法

能夠先思考一分鐘,我但願你可以帶着問題來閱讀此篇文章,也但願你看完文章後會有所收穫!微信

背景

前段時間線上Sentry平臺報警,多個業務服務在和註冊中心交互時,例如續約註冊表增量拉取等都報了Request execution failed with message : Connection refused 的警告:markdown

鏈接拒絕.jpg

緊接着又看到 Request execution succeeded on retry #2 的日誌。網絡

鏈接重試.jpg

看到這裏,代表咱們的服務在嘗試兩次重連後和註冊中心交互正常了。負載均衡

一切都顯得那麼有驚無險,這裏報Connection refused 是註冊中心網絡抖動致使的,接着觸發了咱們服務的重連,重連成功後一切又恢復正常。dom

此次的報警雖然沒有對咱們線上業務形成影響,而且也在第一時間恢復了正常,但做爲一個愛思考的小火雞,我很好奇這背後的一系列邏輯:Eureka註冊中心集羣如何實現客戶端請求負載及故障轉移?ide

問題思考梳理.png

註冊中心集羣負載測試

線上註冊中心是由三臺機器組成的集羣,都是4c8g的配置,業務端配置註冊中心地址以下(這裏的peer來代替具體的ip地址):微服務

eureka.client.serviceUrl.defaultZone=http://peer1:8080/eureka/,http://peer2:8080/eureka/,http://peer3:8080/eureka/
複製代碼

咱們能夠寫了一個Demo進行測試:oop

註冊中心集羣負載測試

一、本地經過修改EurekaServer服務的端口號來模擬註冊中心集羣部署,分別以87618762兩個端口進行啓動 二、啓動客戶端SeviceA,配置註冊中心地址爲:http://localhost:8761/eureka,http://localhost:8762/eureka

EurekaClient端配置.png

三、啓動SeviceA時在發送註冊請求的地方打斷點:AbstractJerseyEurekaHttpClient.register(),以下圖所示:

8761在前.png

這裏看到請求註冊中心時,鏈接的是8761這個端口的服務。

四、更改ServiceA中註冊中心的配置:http://localhost:8762/eureka,http://localhost:8761/eureka 五、從新啓動SeviceA而後查看端口,以下圖所示:

8762在前.png
此時看到請求註冊中心是,鏈接的是 8762這個端口的服務。

註冊中心故障轉移測試

以兩個端口分別啓動EurekaServer服務,再啓動一個客戶端ServiceA。啓動成功後,關閉一個8761端口對應的服務,查看此時客戶端是否會自動遷移請求到8762端口對應的服務:

一、以87618762兩個端口號啓動EurekaServer 二、啓動ServiceA,配置註冊中心地址爲:http://localhost:8761/eureka,http://localhost:8762/eureka 三、啓動成功後,關閉8761端口的EurekaServer 四、在EurekaClient發送心跳請求的地方打上斷點:AbstractJerseyEurekaHttpClient.sendHeartBeat() 五、查看斷點處數據,第一次請求的EurekaServer8761端口的服務,由於該服務已經關閉,因此返回的responsenull

8761故障.png
六、第二次會從新請求 8762端口的服務,返回的 response爲狀態爲 200,故障轉移成功,以下圖:
8762故障轉移.png

思考

經過這兩個測試Demo,我覺得EurekaClient每次都會取defaultZone配置的第一個host做爲請求EurekaServer的請求的地址,若是該節點故障時,會自動切換配置中的下一個EurekaServer進行從新請求。

那麼疑問來了,EurekaClient每次請求真的是以配置的defaultZone配置的第一個服務節點做爲請求的嗎?這彷佛也太弱了!!?

EurekaServer集羣不就成了僞集羣!!?除了客戶端配置的第一個節點,其它註冊中心的節點都只能做爲備份和故障轉移來使用!!?

真相是這樣嗎?NO!咱們眼見也不必定爲實,源碼面前毫無祕密!

翠花,上乾貨!

客戶端請求負載原理

原理圖解

仍是先上結論,負載原理如圖所示:

負載原理.png

這裏會以EurekaClient端的IP做爲隨機的種子,而後隨機打亂serverList,例如咱們在**商品服務(192.168.10.56)**中配置的註冊中心集羣地址爲:peer1,peer2,peer3,打亂後的地址可能變成peer3,peer2,peer1

**用戶服務(192.168.22.31)**中配置的註冊中心集羣地址爲:peer1,peer2,peer3,打亂後的地址可能變成peer2,peer1,peer3

EurekaClient每次請求serverList中的第一個服務,從而達到負載的目的。

代碼實現

咱們直接看最底層負載代碼的實現,具體代碼在 com.netflix.discovery.shared.resolver.ResolverUtils.randomize() 中:

代碼實現.png

這裏面random 是經過咱們EurekaClient端的ipv4作爲隨機的種子,生成一個從新排序的serverList,也就是對應代碼中的randomList,因此每一個EurekaClient獲取到的serverList順序可能不一樣,在使用過程當中,取列表的第一個元素做爲serverhost,從而達到負載的目的。

負載均衡代碼實現.png

思考

原來代碼是經過EurekaClientIP進行負載的,因此剛纔經過DEMO程序結果就能解釋的通了,由於咱們作實驗都是用的同一個IP,因此每次都是會訪問同一個Server節點。

既然說到了負載,這裏確定會有另外一個疑問:

經過IP進行的負載均衡,每次請求都會均勻分散到每個Server節點嗎?

好比第一次訪問Peer1,第二次訪問Peer2,第三次訪問Peer3,第四次繼續訪問Peer1等,循環往復......

咱們能夠繼續作個試驗,假如咱們有10000個EurekaClient節點,3個EurekaServer節點。

Client節點的IP區間爲:192.168.0.0 ~ 192.168.255.255,這裏面共覆蓋6w多個ip段,測試代碼以下:

/** * 模擬註冊中心集羣負載,驗證負載散列算法 * * @author 一枝花算不算浪漫 * @date 2020/6/21 23:36 */
public class EurekaClusterLoadBalanceTest {

    public static void main(String[] args) {
        testEurekaClusterBalance();
    }

    /** * 模擬ip段測試註冊中心負載集羣 */
    private static void testEurekaClusterBalance() {
        int ipLoopSize = 65000;
        String ipFormat = "192.168.%s.%s";
        TreeMap<String, Integer> ipMap = Maps.newTreeMap();
        int netIndex = 0;
        int lastIndex = 0;
        for (int i = 0; i < ipLoopSize; i++) {
            if (lastIndex == 256) {
                netIndex += 1;
                lastIndex = 0;
            }

            String ip = String.format(ipFormat, netIndex, lastIndex);
            randomize(ip, ipMap);
            System.out.println("IP: " + ip);
            lastIndex += 1;
        }

        printIpResult(ipMap, ipLoopSize);
    }

    /** * 模擬指定ip地址獲取對應註冊中心負載 */
    private static void randomize(String eurekaClientIp, TreeMap<String, Integer> ipMap) {
        List<String> eurekaServerUrlList = Lists.newArrayList();
        eurekaServerUrlList.add("http://peer1:8080/eureka/");
        eurekaServerUrlList.add("http://peer2:8080/eureka/");
        eurekaServerUrlList.add("http://peer3:8080/eureka/");

        List<String> randomList = new ArrayList<>(eurekaServerUrlList);
        Random random = new Random(eurekaClientIp.hashCode());
        int last = randomList.size() - 1;
        for (int i = 0; i < last; i++) {
            int pos = random.nextInt(randomList.size() - i);
            if (pos != i) {
                Collections.swap(randomList, i, pos);
            }
        }

        for (String eurekaHost : randomList) {
            int ipCount = ipMap.get(eurekaHost) == null ? 0 : ipMap.get(eurekaHost);
            ipMap.put(eurekaHost, ipCount + 1);
            break;
        }
    }

    private static void printIpResult(TreeMap<String, Integer> ipMap, int totalCount) {
        for (Map.Entry<String, Integer> entry : ipMap.entrySet()) {
            Integer count = entry.getValue();
            BigDecimal rate = new BigDecimal(count).divide(new BigDecimal(totalCount), 2, BigDecimal.ROUND_HALF_UP);
            System.out.println(entry.getKey() + ":" + count + ":" + rate.multiply(new BigDecimal(100)).setScale(0, BigDecimal.ROUND_HALF_UP) + "%");
        }
    }
}
複製代碼

負載測試結果以下:

負載測試結果.png

能夠看到第二個機器會有**50%的請求,最後一臺機器只有17%**的請求,負載的狀況並非很均勻,我認爲經過IP負載並非一個好的方案。

還記得咱們以前講過Ribbon默認的輪詢算法RoundRobinRule【一塊兒學源碼-微服務】Ribbon 源碼四:進一步探究Ribbon的IRule和IPing

這種算法就是一個很好的散列算法,能夠保證每次請求都很均勻,原理以下圖:

Ribbon輪詢算法.png

故障轉移原理

原理圖解

仍是先上結論,以下圖:

故障轉移原理.png

咱們的serverList按照client端的ip進行重排序後,每次都會請求第一個元素做爲和Server端交互的host,若是請求失敗,會嘗試請求serverList列表中的第二個元素繼續請求,此次請求成功後,會將這次請求的host放到全局的一個變量中保存起來,下次client端再次請求 就會直接使用這個host

這裏最多會重試請求兩次。

代碼實現

直接看底層交互的代碼,位置在 com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute() 中:

重試代碼.png

咱們來分析下這個代碼:

  1. 第101行,獲取client上次成功server端的host,若是有值則直接使用這個host
  2. 第105行,getHostCandidates()是獲取client端配置的serverList數據,且經過ip進行重排序的列表
  3. 第114行,candidateHosts.get(endpointIdx++),初始endpointIdx=0,獲取列表中第1個元素做爲host請求
  4. 第120行,獲取返回的response結果,若是返回的狀態碼是200,則將這次請求的host設置到全局的delegate變量中
  5. 第133行,執行到這裏說明第120行執行的response返回的狀態碼不是200,也就是執行失敗,將全局變量delegate中的數據清空
  6. 再次循環第一步,此時endpointIdx=1,獲取列表中的第二個元素做爲host請求
  7. 依次執行,第100行的循環條件numberOfRetries=3,最多重試2次就會跳出循環

咱們還能夠第123和129行,這也正是咱們業務拋出來的日誌信息,全部的一切都對應上了。

總結

感謝你看到這裏,相信你已經清楚了開頭提問的問題。

上面已經分析完了Eureka集羣下Client端請求時負載均衡的選擇以及集羣故障時自動重試請求的實現原理。

若是還有不懂的問題,能夠添加個人微信或者給我公衆號留言,我會單獨和你討論交流。

本文首發自:一枝花算不算浪漫 公衆號,如若轉載請在文章開頭標明出處,如需開白可直接公衆號回覆便可。

原創乾貨分享.png
相關文章
相關標籤/搜索