摘要：所以通過設置一個適中的拉取注冊表以及發送心跳的頻率，保證大規模系統里對的請求壓力不會太大。在注冊表發生變更的時候會在內存中更新變更的注冊表數據，同時過期掉。上述就是架構中，作為微服務注冊中心可以承載大規模系統每天千萬級訪問量的原理。

歡迎關注微信公眾號：石杉的架構筆記

周一至周五早8點！精品技術文章準時送上！！

往期文章
1.拜托！面試請不要再問我Spring Cloud底層原理！

目錄：

一、問題起源

二、Eureka Server設計精妙的注冊表存儲結構

三、Eureka Server端優秀的多級緩存機制

四、總結

一、問題起源

Spring Cloud微服務架構體系中，Eureka是一個至關重要的組件，它扮演著微服務注冊中心的角色，所有的服務注冊與服務發現，都是依賴Eureka的。

之前不少初學Spring Cloud的朋友在落地公司的生產環境部署時，經常會有一個疑問：Eureka Server到底要部署幾臺機器？

我們的系統那么多服務，到底會對Eureka Server產生多大的訪問壓力？Eureka Server能不能抗住一個大型系統的訪問壓力？

你現在心里也一定很多疑問，別著急，咱們這就去探索一下，Eureka作為微服務注冊中心的核心原理。下面這些問題，大伙兒先看看，有個大概的印象。

帶著這些問題，來看后面的內容，效果更佳。

● Eureka注冊中心使用什么樣的方式來儲存各個服務注冊時發送過來的機器地址和端口號？

● 各個服務找Eureka Server拉取注冊表的時候，是什么樣的頻率？

● 各個服務是如何拉取注冊表的？

● 對于一個有幾百個服務，部署上千臺機器的大型分布式系統來說，這套系統會對Eureka Server造成多大的訪問壓力？

● Eureka Server從技術層面是如何抗住日千萬級訪問量的？

先給大家說一個基本知識點，各個服務內的Eureka Client組件，默認情況下，每隔30秒會發送一個請求到Eureka Server，來拉取最近有變化的服務信息

舉個例子：

● 庫存服務原本部署在1臺機器上，現在擴容了，部署到了3臺機器，并且均注冊到了Eureka Server上。

● 然后訂單服務的Eureka Client會每隔30秒去找Eureka Server拉取最近注冊表的變化，看看其他服務的地址有沒有變化。

除此之外，對Eureka Server一個比較常見的請求就是心跳，各個Eureka Client都會每隔30秒發送一次心跳請求到Eureka Server，通知人家說，哥們，我這個服務實例還活著！

如果某個Eureka Client很長時間沒有發送心跳給Eureka Server，那么就說明這個服務實例已經掛了。

光看上面的文字，各位童鞋可能沒什么印象。老規矩！咱們還是來一張圖，一起來直觀的感受一下這個過程。

圖片描述

二、Eureka Server設計精妙的注冊表存儲結構

現在咱們假設你手頭有一套大型的分布式系統，這套系統一共有100個服務，每個服務部署在20臺機器上，機器是4核8G的標準配置。

這相當于什么呢？也就是說相當于你一共部署了100 * 20 = 2000個服務實例，有2000臺機器。

而每臺機器上的服務實例內部都有一個Eureka Client組件，這個Eureka Client組件每隔30秒會請求一次Eureka Server來拉取變化的注冊表。

此外，每個服務實例上的Eureka Client都會每隔30秒發送一次心跳請求給Eureka Server。

那么大家算算，Eureka Server作為一個微服務注冊中心，每秒鐘要被請求多少次？一天要被請求多少次？

● 很簡單，我們就按最標準的算法來算，即每個服務實例每分鐘請求2次拉取注冊表，每分鐘請求2次發送心跳

● 這樣的話，一個服務實例每分鐘會請求4次，2000個服務實例每分鐘請求8000次

● 換算到每秒鐘，則是8000 / 60 = 133次左右，我們直接可以大概估算為Eureka Server每秒鐘會被請求150次

● 所以，一天的話，應該就是8000 60 24 = 1152萬，也就是每天千萬級訪問量

好！經過這么一個測算，大家是否發現這里的奧秘了？

● 首先第一點，對于微服務注冊中心這種組件，在一開始設計他這個注冊表的拉取頻率以及心跳發送頻率的時候，就已經考慮到了一個大型系統的各個服務請求時的壓力，每秒會承載多大的請求量。

● 所以說各個服務實例每隔30秒發起一次請求拉取變化的注冊表，以及每隔30秒發送一次心跳給Eureka Server，其實這個時間安排是有他的用意的。

按照我們的測算，一個上百個服務，部署幾千臺機器的大規模系統，按照這樣的一個頻率請求Eureka Server，日請求量在千萬級，每秒的訪問量應該是固定在150次左右，即使算上其他的一些額外操作，算到每秒鐘請求Eureka Server在200次~300次吧。

所以通過設置一個適中的拉取注冊表以及發送心跳的頻率，保證大規模系統里對Eureka Server的請求壓力不會太大。

關鍵問題來了，Eureka Server是如何保證輕松抗住這每秒數百次請求，每天千萬級請求的呢？

要搞清楚這個，首先得清楚人家Eureka Server到底是用什么來存儲注冊表的？三個字，看源碼！

接下來咱們就一起進入Eureka的源碼里一探究竟：

圖片描述

● 如上圖所示，圖中名為registry的CocurrentHashMap，就是注冊表的核心結構。看完之后忍不住先贊嘆一下，真是精妙的設計！

● 從代碼中可以看到，Eureka Server的注冊表直接基于純內存，就是在內存里維護了一個數據結構。

● 各個服務發起注冊、服務下線、服務故障，全部會在內存里維護和更新這個注冊表。

● 各個服務每隔30秒拉取注冊表的時候，其實Eureka Server就是直接提供內存里存儲的有變化的注冊表數據給他們就可以了。

● 同樣，每隔30秒發起心跳的時候，也是在這個純內存的CocurrentHashMap數據結構里更新心跳時間。

一句話概括：維護注冊表、拉取注冊表、更新心跳時間，全部發生在內存里！這就是Eureka Server非常核心的一個點。

搞清楚了這一點，咱們再來分析一下這個叫做registry的東西的數據結構，大家千萬別被它復雜的外表唬住了，沉下心來，一層層的分析！

● 首先，這個ConcurrentHashMap的key就是服務名稱，比如說“inventory-service”，就是一個服務名稱。

● 而value：Map則代表了一個服務的多個服務實例。

● 舉個例子：比如說“inventory-service”是可以有3個服務實例的，每個服務實例部署在一臺機器上

接下來咱們再來看里面這個小Map：

Map

● 這個Map的key就是服務實例的id

● value是一個叫做 Lease的東西。這又是什么鬼呢？

■ 首先說下InstanceInfo，其實啊，我們見名知義，這個InstanceInfo就代表了服務實例的具體信息，比如機器的ip地址、hostname以及端口號

■ 而Lease的這個Lease，里面則會維護每個服務最近一次發送心跳的時間

三、Eureka Server端優秀的多級緩存機制

假設Eureka Server部署在4核8G的普通機器上，那么基于內存來承載各個服務的請求，每秒鐘最多可以處理多少請求呢？

● 根據之前做過的測試，單臺4核8G的機器，處理一些純內存的操作，哪怕加上一些網絡請求的開銷，每秒處理幾百請求是很輕松的。哪怕是更大規模的機器和請求量，處理起來，也是輕松加愉快。

● 而且Eureka Server為了避免同時讀寫內存數據結構造成的并發沖突問題，還采用了多級緩存機制來進一步提升服務請求的響應速度。

● 在拉取注冊表的時候：

? 首先從ReadOnlyCacheMap里查緩存的注冊表。

? 如果沒有，就找ReadWriteCacheMap里緩存的注冊表。

? 如果還沒有，就從內存中獲取實際的注冊表數據。

● 在注冊表發生變更的時候：

? 會在內存中更新變更的注冊表數據，同時過期掉ReadWriteCacheMap。

? 這個過程不會影響ReadOnlyCacheMap提供人家查詢注冊表。

? 在一段時間內，默認是30秒，各個服務拉取注冊表數據都會直接讀ReadOnlyCacheMap。

? 在30秒過后，Eureka Server的后臺線程發現ReadWriteCacheMap已經清空了，那么也會清空ReadOnlyCacheMap中的緩存

? 下次有服務拉取注冊表，又會從內存中獲取最新的數據了，同時填充各個緩存。

多級緩存機制的優點是什么？

1.這種多級緩存機制的設計，盡可能保證了內存注冊表數據不會出現頻繁的讀寫沖突問題。

2.并且進一步保證對Eureka Server的大量請求，都是快速從純內存走，性能極高。

為方便大家更好的理解，同樣來一張圖，大家跟著圖再來回顧一下這整個過程：

圖片描述

四、總結

● 通過上面的分析可以看到，Eureka通過設置適當的請求頻率（拉取注冊表30秒間隔，發送心跳30秒間隔），可以保證一個大規模的系統每秒請求Eureka Server的次數在幾百次。

● 同時還通過純內存的注冊表，保證了所有的請求都可以在內存處理，這樣確保了極高的性能，普通機器一秒鐘處理幾百請求都是輕松+愉快的。

● 另外還有多級緩存機制，確保說不會針對內存數據結構發生頻繁的讀寫并發沖突操作，進一步提升性能。

上述就是Spring Cloud架構中，Eureka作為微服務注冊中心可以承載大規模系統每天千萬級訪問量的原理。

如有收獲，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！

一大波微服務、分布式、高并發、高可用的原創系列文章正在路上：

《雙11每秒上萬并發下的Spring Cloud參數優化實戰》，敬請期待

《微服務架構如何保障雙11狂歡下的99.99%高可用》，敬請期待

歡迎關注微信公眾號：石杉的架構筆記（id：shishan100）

周一至周五早八點！精品技術文章準時送上！

十余年BAT架構經驗傾囊相授。