一、問題起源

Spring Cloud架構(gòu)體系中，Eureka是一個至關(guān)重要的組件，它扮演著微服務(wù)注冊中心的角色，所有的服務(wù)注冊與服務(wù)發(fā)現(xiàn)，都是依賴Eureka的。 不少初學(xué)Spring Cloud的朋友在落地公司生產(chǎn)環(huán)境部署時，經(jīng)常會問：

• Eureka Server到底要部署幾臺機器？
• 我們的系統(tǒng)那么多服務(wù)，到底會對Eureka Server產(chǎn)生多大的訪問壓力？
• Eureka Server能不能抗住一個大型系統(tǒng)的訪問壓力？

如果你也有這些疑問，別著急！咱們這就一起去看看，Eureka作為微服務(wù)注冊中心的核心原理

下面這些問題，大家先看看，有個大概印象。帶著這些問題，來看后面的內(nèi)容，效果更佳。

1. Eureka注冊中心使用什么樣的方式來儲存各個服務(wù)注冊時發(fā)送過來的機器地址和端口號？
2. 各個服務(wù)找Eureka Server拉取注冊表的時候，是什么樣的頻率？
3. 各個服務(wù)是如何拉取注冊表的？
4. 一個幾百服務(wù)，部署上千臺機器的大型分布式系統(tǒng)，會對Eureka Server造成多大的訪問壓力？
5. Eureka Server從技術(shù)層面是如何抗住日千萬級訪問量的？

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

舉個例子：

• 庫存服務(wù)原本部署在1臺機器上，現(xiàn)在擴容了，部署到了3臺機器，并且均注冊到了Eureka Server上。
• 然后訂單服務(wù)的Eureka Client會每隔30秒去找Eureka Server拉取最近注冊表的變化，看看其他服務(wù)的地址有沒有變化。

除此之外，Eureka還有一個心跳機制，各個Eureka Client每隔30秒會發(fā)送一次心跳到Eureka Server，通知人家說，哥們，我這個服務(wù)實例還活著！

如果某個Eureka Client很長時間沒有發(fā)送心跳給Eureka Server，那么就說明這個服務(wù)實例已經(jīng)掛了。

光看上面的文字，大家可能沒什么印象。老規(guī)矩！咱們還是來一張圖，一起來直觀的感受一下這個過程。

二、Eureka Server設(shè)計精妙的注冊表存儲結(jié)構(gòu)

現(xiàn)在咱們假設(shè)手頭有一套大型的分布式系統(tǒng)，一共100個服務(wù)，每個服務(wù)部署在20臺機器上，機器是4核8G的標準配置。

也就是說，相當于你一共部署了100 * 20 = 2000個服務(wù)實例，有2000臺機器。

每臺機器上的服務(wù)實例內(nèi)部都有一個Eureka Client組件，它會每隔30秒請求一次Eureka Server，拉取變化的注冊表。

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

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

• 按標準的算法，每個服務(wù)實例每分鐘請求2次拉取注冊表，每分鐘請求2次發(fā)送心跳。
• 這樣一個服務(wù)實例每分鐘會請求4次，2000個服務(wù)實例每分鐘請求8000次。
• 換算到每秒，則是8000 / 60 = 133次左右，我們就大概估算為Eureka Server每秒會被請求150次。
• 那一天的話，就是8000 * 60 * 24 = 1152萬，也就是每天千萬級訪問量。

好！經(jīng)過這么一個測算，大家是否發(fā)現(xiàn)這里的奧秘了？

• 首先，對于微服務(wù)注冊中心這種組件，在一開始設(shè)計它的拉取頻率以及心跳發(fā)送頻率時，就已經(jīng)考慮到了一個大型系統(tǒng)的各個服務(wù)請求時的壓力，每秒會承載多大的請求量。?
• 所以各服務(wù)實例每隔30秒發(fā)起請求拉取變化的注冊表，以及每隔30秒發(fā)送心跳給Eureka Server，其實這個時間安排是有其用意的。

按照我們的測算，一個上百個服務(wù)，幾千臺機器的系統(tǒng)，按照這樣的頻率請求Eureka Server，日請求量在千萬級，每秒的訪問量在150次左右。

即使算上其他一些額外操作，我們姑且就算每秒鐘請求Eureka Server在200次~300次吧。

所以通過設(shè)置一個適當?shù)睦∽员硪约鞍l(fā)送心跳的頻率，可以保證大規(guī)模系統(tǒng)里對Eureka Server的請求壓力不會太大。

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

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

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

• ?如上圖所示，圖中的這個名字叫做registry的CocurrentHashMap，就是注冊表的核心結(jié)構(gòu)?？赐曛笕滩蛔∠荣潎@一下，精妙的設(shè)計！
• 從代碼中可以看到，Eureka Server的注冊表直接基于純內(nèi)存，即在內(nèi)存里維護了一個數(shù)據(jù)結(jié)構(gòu)。
• 各個服務(wù)的注冊、服務(wù)下線、服務(wù)故障，全部會在內(nèi)存里維護和更新這個注冊表。
• 各個服務(wù)每隔30秒拉取注冊表的時候，Eureka Server就是直接提供內(nèi)存里存儲的有變化的注冊表數(shù)據(jù)給他們就可以了。
• 同樣，每隔30秒發(fā)起心跳時，也是在這個純內(nèi)存的Map數(shù)據(jù)結(jié)構(gòu)里更新心跳時間。

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

搞清楚了這個，咱們再來分析一下registry這個東西的數(shù)據(jù)結(jié)構(gòu)，大家千萬別被它復(fù)雜的外表唬住了，沉下心來，一層層的分析！

• 首先，這個ConcurrentHashMap的key就是服務(wù)名稱，比如“inventory-service”，就是一個服務(wù)名稱。
• value則代表了一個服務(wù)的多個服務(wù)實例。
• 舉例：比如“inventory-service”是可以有3個服務(wù)實例的，每個服務(wù)實例部署在一臺機器上。

再來看看作為value的這個Map：

Map<String, Lease<InstanceInfo>>

• 這個Map的key就是服務(wù)實例的id
• value是一個叫做Lease的類，它的泛型是一個叫做InstanceInfo的東東，你可能會問，這倆又是什么鬼？
• 首先說下InstanceInfo，其實啊，我們見名知義，這個InstanceInfo就代表了服務(wù)實例的具體信息，比如機器的ip地址、hostname以及端口號。
• 而這個Lease，里面則會維護每個服務(wù)最近一次發(fā)送心跳的時間?。

三、Eureka Server端優(yōu)秀的多級緩存機制

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

• 根據(jù)之前的測試，單臺4核8G的機器，處理純內(nèi)存操作，哪怕加上一些網(wǎng)絡(luò)的開銷，每秒處理幾百請求也是輕松加愉快的。
• 而且Eureka Server為了避免同時讀寫內(nèi)存數(shù)據(jù)結(jié)構(gòu)造成的并發(fā)沖突問題，還采用了多級緩存機制來進一步提升服務(wù)請求的響應(yīng)速度。
• 在拉取注冊表的時候：

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

• 若沒有，就找ReadWriteCacheMap里緩存的注冊表。
• 如果還沒有，就從內(nèi)存中獲取實際的注冊表數(shù)據(jù)。
• 在注冊表發(fā)生變更的時候：
• 會在內(nèi)存中更新變更的注冊表數(shù)據(jù)，同時過期掉ReadWriteCacheMap。
• 此過程不會影響ReadOnlyCacheMap提供人家查詢注冊表。
• 一段時間內(nèi)（默認30秒），各服務(wù)拉取注冊表會直接讀ReadOnlyCacheMap
• 30秒過后，Eureka Server的后臺線程發(fā)現(xiàn)ReadWriteCacheMap已經(jīng)清空了，也會清空ReadOnlyCacheMap中的緩存
• 下次有服務(wù)拉取注冊表，又會從內(nèi)存中獲取最新的數(shù)據(jù)了，同時填充各個緩存。

多級緩存機制的優(yōu)點是什么？

• 盡可能保證了內(nèi)存注冊表數(shù)據(jù)不會出現(xiàn)頻繁的讀寫沖突問題。
• 并且進一步保證對Eureka Server的大量請求，都是快速從純內(nèi)存走，性能極高。

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

四、總結(jié)

• 通過上面的分析可以看到，Eureka通過設(shè)置適當?shù)恼埱箢l率（拉取注冊表30秒間隔，發(fā)送心跳30秒間隔），可以保證一個大規(guī)模的系統(tǒng)每秒請求Eureka Server的次數(shù)在幾百次。
• 同時通過純內(nèi)存的注冊表，保證了所有的請求都可以在內(nèi)存處理，確保了極高的性能。
• 另外,多級緩存機制，確保了不會針對內(nèi)存數(shù)據(jù)結(jié)構(gòu)發(fā)生頻繁的讀寫并發(fā)沖突操作，進一步提升性能。

上述就是Spring Cloud架構(gòu)中，Eureka作為微服務(wù)注冊中心可以承載大規(guī)模系統(tǒng)每天千萬級訪問量的原理。