摘要：所以通過設(shè)置一個(gè)適中的拉取注冊表以及發(fā)送心跳的頻率，保證大規(guī)模系統(tǒng)里對的請求壓力不會(huì)太大。在注冊表發(fā)生變更的時(shí)候會(huì)在內(nèi)存中更新變更的注冊表數(shù)據(jù)，同時(shí)過期掉。上述就是架構(gòu)中，作為微服務(wù)注冊中心可以承載大規(guī)模系統(tǒng)每天千萬級訪問量的原理。

歡迎關(guān)注微信公眾號：石杉的架構(gòu)筆記

周一至周五早8點(diǎn)！精品技術(shù)文章準(zhǔn)時(shí)送上??！

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

目錄：

一、問題起源

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

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

四、總結(jié)

一、問題起源

Spring Cloud微服務(wù)架構(gòu)體系中，Eureka是一個(gè)至關(guān)重要的組件，它扮演著微服務(wù)注冊中心的角色，所有的服務(wù)注冊與服務(wù)發(fā)現(xiàn)，都是依賴Eureka的。

之前不少初學(xué)Spring Cloud的朋友在落地公司的生產(chǎn)環(huán)境部署時(shí)，經(jīng)常會(huì)有一個(gè)疑問：Eureka Server到底要部署幾臺(tái)機(jī)器？

我們的系統(tǒng)那么多服務(wù)，到底會(huì)對Eureka Server產(chǎn)生多大的訪問壓力？Eureka Server能不能抗住一個(gè)大型系統(tǒng)的訪問壓力？

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

帶著這些問題，來看后面的內(nèi)容，效果更佳。

● Eureka注冊中心使用什么樣的方式來儲(chǔ)存各個(gè)服務(wù)注冊時(shí)發(fā)送過來的機(jī)器地址和端口號？

● 各個(gè)服務(wù)找Eureka Server拉取注冊表的時(shí)候，是什么樣的頻率？

● 各個(gè)服務(wù)是如何拉取注冊表的？

● 對于一個(gè)有幾百個(gè)服務(wù)，部署上千臺(tái)機(jī)器的大型分布式系統(tǒng)來說，這套系統(tǒng)會(huì)對Eureka Server造成多大的訪問壓力？

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

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

舉個(gè)例子：

● 庫存服務(wù)原本部署在1臺(tái)機(jī)器上，現(xiàn)在擴(kuò)容了，部署到了3臺(tái)機(jī)器，并且均注冊到了Eureka Server上。

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

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

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

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

圖片描述

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

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

這相當(dāng)于什么呢？也就是說相當(dāng)于你一共部署了100 * 20 = 2000個(gè)服務(wù)實(shí)例，有2000臺(tái)機(jī)器。

而每臺(tái)機(jī)器上的服務(wù)實(shí)例內(nèi)部都有一個(gè)Eureka Client組件，這個(gè)Eureka Client組件每隔30秒會(huì)請求一次Eureka Server來拉取變化的注冊表。

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

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

● 很簡單，我們就按最標(biāo)準(zhǔn)的算法來算，即每個(gè)服務(wù)實(shí)例每分鐘請求2次拉取注冊表，每分鐘請求2次發(fā)送心跳

● 這樣的話，一個(gè)服務(wù)實(shí)例每分鐘會(huì)請求4次，2000個(gè)服務(wù)實(shí)例每分鐘請求8000次

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

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

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

● 首先第一點(diǎn)，對于微服務(wù)注冊中心這種組件，在一開始設(shè)計(jì)他這個(gè)注冊表的拉取頻率以及心跳發(fā)送頻率的時(shí)候，就已經(jīng)考慮到了一個(gè)大型系統(tǒng)的各個(gè)服務(wù)請求時(shí)的壓力，每秒會(huì)承載多大的請求量。

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

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

所以通過設(shè)置一個(gè)適中的拉取注冊表以及發(fā)送心跳的頻率，保證大規(guī)模系統(tǒng)里對Eureka Server的請求壓力不會(huì)太大。

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

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

接下來咱們就一起進(jìn)入Eureka的源碼里一探究竟：

圖片描述

● 如上圖所示，圖中名為registry的CocurrentHashMap，就是注冊表的核心結(jié)構(gòu)。看完之后忍不住先贊嘆一下，真是精妙的設(shè)計(jì)！

● 從代碼中可以看到，Eureka Server的注冊表直接基于純內(nèi)存，就是在內(nèi)存里維護(hù)了一個(gè)數(shù)據(jù)結(jié)構(gòu)。

● 各個(gè)服務(wù)發(fā)起注冊、服務(wù)下線、服務(wù)故障，全部會(huì)在內(nèi)存里維護(hù)和更新這個(gè)注冊表。

● 各個(gè)服務(wù)每隔30秒拉取注冊表的時(shí)候，其實(shí)Eureka Server就是直接提供內(nèi)存里存儲(chǔ)的有變化的注冊表數(shù)據(jù)給他們就可以了。

● 同樣，每隔30秒發(fā)起心跳的時(shí)候，也是在這個(gè)純內(nèi)存的CocurrentHashMap數(shù)據(jù)結(jié)構(gòu)里更新心跳時(shí)間。

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

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

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

● 而value：Map則代表了一個(gè)服務(wù)的多個(gè)服務(wù)實(shí)例。

● 舉個(gè)例子：比如說“inventory-service”是可以有3個(gè)服務(wù)實(shí)例的，每個(gè)服務(wù)實(shí)例部署在一臺(tái)機(jī)器上

接下來咱們再來看里面這個(gè)小Map：

Map

● 這個(gè)Map的key就是服務(wù)實(shí)例的id

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

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

■ 而Lease的這個(gè)Lease，里面則會(huì)維護(hù)每個(gè)服務(wù)最近一次發(fā)送心跳的時(shí)間

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

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

● 根據(jù)之前做過的測試，單臺(tái)4核8G的機(jī)器，處理一些純內(nèi)存的操作，哪怕加上一些網(wǎng)絡(luò)請求的開銷，每秒處理幾百請求是很輕松的。哪怕是更大規(guī)模的機(jī)器和請求量，處理起來，也是輕松加愉快。

● 而且Eureka Server為了避免同時(shí)讀寫內(nèi)存數(shù)據(jù)結(jié)構(gòu)造成的并發(fā)沖突問題，還采用了多級緩存機(jī)制來進(jìn)一步提升服務(wù)請求的響應(yīng)速度。

● 在拉取注冊表的時(shí)候：

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

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

? 如果還沒有，就從內(nèi)存中獲取實(shí)際的注冊表數(shù)據(jù)。

● 在注冊表發(fā)生變更的時(shí)候：

? 會(huì)在內(nèi)存中更新變更的注冊表數(shù)據(jù)，同時(shí)過期掉ReadWriteCacheMap。

? 這個(gè)過程不會(huì)影響ReadOnlyCacheMap提供人家查詢注冊表。

? 在一段時(shí)間內(nèi)，默認(rèn)是30秒，各個(gè)服務(wù)拉取注冊表數(shù)據(jù)都會(huì)直接讀ReadOnlyCacheMap。

? 在30秒過后，Eureka Server的后臺(tái)線程發(fā)現(xiàn)ReadWriteCacheMap已經(jīng)清空了，那么也會(huì)清空ReadOnlyCacheMap中的緩存

? 下次有服務(wù)拉取注冊表，又會(huì)從內(nèi)存中獲取最新的數(shù)據(jù)了，同時(shí)填充各個(gè)緩存。

多級緩存機(jī)制的優(yōu)點(diǎn)是什么？

1.這種多級緩存機(jī)制的設(shè)計(jì)，盡可能保證了內(nèi)存注冊表數(shù)據(jù)不會(huì)出現(xiàn)頻繁的讀寫沖突問題。

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

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

圖片描述

四、總結(jié)

● 通過上面的分析可以看到，Eureka通過設(shè)置適當(dāng)?shù)恼埱箢l率（拉取注冊表30秒間隔，發(fā)送心跳30秒間隔），可以保證一個(gè)大規(guī)模的系統(tǒng)每秒請求Eureka Server的次數(shù)在幾百次。

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

● 另外還有多級緩存機(jī)制，確保說不會(huì)針對內(nèi)存數(shù)據(jù)結(jié)構(gòu)發(fā)生頻繁的讀寫并發(fā)沖突操作，進(jìn)一步提升性能。

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

如有收獲，請幫忙轉(zhuǎn)發(fā)，您的鼓勵(lì)是作者最大的動(dòng)力，謝謝！

一大波微服務(wù)、分布式、高并發(fā)、高可用的原創(chuàng)系列文章正在路上：

《雙11每秒上萬并發(fā)下的Spring Cloud參數(shù)優(yōu)化實(shí)戰(zhàn)》，敬請期待

《微服務(wù)架構(gòu)如何保障雙11狂歡下的99.99%高可用》，敬請期待

歡迎關(guān)注微信公眾號：石杉的架構(gòu)筆記（id：shishan100）

周一至周五早八點(diǎn)！精品技術(shù)文章準(zhǔn)時(shí)送上！

十余年BAT架構(gòu)經(jīng)驗(yàn)傾囊相授。