一、場景引入

         本人所在的專案由於直接面向消費者，迭代週期迅速，所以服務端框架一直採用Springboot+dubbo的組合模式，每個服務由service模組+web模組構成，service模組通過公司API閘道器向安卓端暴

露restful介面，web模組通過dubbo服務向service模組獲取資料渲染頁面。測試環境dubbo的註冊中心採用的單例項的zookeeper，隨著時間的發現註冊在zookeeper上的生產者和消費者越來越多，測試

人員經常在大規模的壓測後發現zookeeper掛掉的現象。因為自己用過springcloud，所以想由此談一下springcloud是如何對註冊中心叢集化以及如何應對高併發場景的。

二、Spring Cloud的註冊中心 Eureka

       首先看一下Spring Cloud的架構，整個架構圖在抽象之後大概就是這個樣子。Spring cloud Eureka是Spring Cloud Netflix 微服務套件中的一部分，它基於 Netflix做了二次封裝，主要負責完成

微服務架構中的服務治理功能。不同於dubbo註冊中心的是：dubbo的註冊中心是第三方元件，可以是zookeeper、可以是Redis。而Spring Cloud的註冊中心不是第三方元件，而是自身二次封裝專門用於服

務註冊與服務發現的註冊中心，在使用時只需要依賴相應的jar包即可。

三、註冊中心叢集化

       在微服務這樣的分散式架構中，我們要考慮故障發生的場景，所以在生產環境中要對各元件進行高可用部署，即叢集化。故springcloug的註冊中心也一樣，生產環境中單節點的註冊中心顯然是十

分不安全的，我們需要構建高可用的服務註冊中心以增強系統的可用性。

      EurekaServer在設計之初就考慮到了高可用問題，在Eureka的服務治理設計中，所有節點既是服務提供者同時也是服務消費者。Eureka  Server的高可用實際上就是將自己作為服務向其他服務注

冊中心註冊自己，從而形成一組互相註冊的服務註冊中心，因此能夠實現服務清單的互相同步，達到服務高可用的效果，例如構建一個雙節點的註冊中心：

• 建立application-dev1.properties作為註冊中心1的配置，並將serviceUrl指向註冊中心2(dev2)：

 • 建立application-dev2.properties作為註冊中心2的配置，並將serviceUrl指向註冊中心1(dev1)：

  然後分別啟動兩個服務即可組成雙節點的註冊中心，若叢集不止兩個例項，只需要在eureka.client.serviceUrl.defaultZone配置項後面用","隔開然後啟動專案即可。此時啟動服務提供者與服務消費

者，客戶端是分別註冊到每一個註冊中心的例項上的，若此時斷開一個或者幾個註冊中心例項，只要叢集中還有例項存活就依然可以提供正常服務，從而實現了服務註冊中心的高可用。

四、註冊中心與高併發

         Spring Cloud的架構體系中，Eureka扮演著一個至關重要的角色，所有的服務註冊與服務發現都是依賴著Eureka。上面介紹了註冊中心的叢集化，那真正的生產環境中註冊中心到底要部署多少臺？Eureka能不能抗住系統中大量的併發訪問？想要弄清楚這個，先從註冊中心與客戶端的工作原理說起。

        首先，各個服務內的Eureka Client在預設情況下每隔30s傳送一個請求到Eureka Server來拉取最近有變化的服務資訊。

舉個栗子~

       電商的支付模組原本是部署在1臺機器上，現在增加部署例項，部署到3臺機器上，並且都已經註冊到Eureka Server上，然後Eureka Client會每隔30s去Eureka Server拉取登錄檔資訊的變化，看

服務的地址有沒有變化。

       其次，Eureka有一個心跳機制，各個Eureka Client每隔30s會發送一次心跳資料到Eureka Server，告訴註冊中心自己還活著。如果某個Eureka Client很長時間沒有傳送心跳資料給Eureka

Server，那麼就說明這個例項已經掛了！

       在另一方面，服務註冊中心這種元件在一開始設計的時候，它的拉取頻率及心跳傳送機制就已經兼顧到了一個大型系統的各個服務請求的壓力，每秒能夠承受多大的請求量。預設的30s時間間隔

其實是經過理論上研究後得出的。一個上百個服務，幾千臺機器的服務系統，按照這個體量請求Eureka Server，日請求量大概在千萬級，每秒的訪問量大概在160次左右，再加上一些其他的請求操

作，每秒在200次左右。所以通過設定一個拉取登錄檔及心跳傳送機制來保證高併發下場景下Eureka Server的壓力不會太大。

       那麼問題來了，Eureka Server是如何抗住每秒200次的請求的呢？

這個問題其實看原始碼即可一目瞭然，Eureka Server登錄檔的核心是一個CocurrentHashMap,也就是說整個登錄檔的資料時完全儲存在記憶體裡的，各個服務的註冊、下線、故障、全部會在記憶體中維護

和更新。也就是說，Eureka Client每隔30s拉取註冊資訊和傳送心跳資料也是完全基於記憶體，這個是能抗住每秒200次併發重要原因之一！

       通過以上分析，Eureka通過設定適當的請求頻率（拉取註冊資訊30s間隔，傳送心跳資料30s間隔）可以保證一個大規模的系統每秒的請求在200次左右，同時通過記憶體維護登錄檔資訊，保證了所

有的請求都在記憶體中處理，確保了效能。所以在生產環境中到底需要部署多少臺註冊中心的例項，還是要根據自身系統的訪問體量大小決定。