Eureka詳解系列(一)--先談談負載均衡器

子月生發表於2021-01-22
負載

這個系列開始研究 Eureka，在此之前，先來談談負載均衡器。

本質上，Eureka 就是一個負載均衡器，可能有的人會說，它是一個服務註冊中心，用來註冊服務的，這種說法不能說錯，只是有點片面。

在這篇部落格裡，我將盡可能循序漸進、圖文並茂地回答下面的幾個問題。至於 Eureka 的使用、配置、原始碼分析、叢集配置等等，這些後續部落格再補充。

  1. 為什麼要用負載均衡器？
  2. 一個合格的負載均衡器是怎樣的？
  3. mid-tier services 的負載均衡器？
  4. 為什麼使用 Eureka？

為什麼要用負載均衡器

那麼，先從一個例子開始。

假設我有一個網上商城的專案，在專案初期，它是一個傳統的單體應用，沒有叢集，沒有微服務。顯然，這個時候我不需要考慮所謂的負載均衡。

zzs_eureka_01

隨著應用的推廣，我的使用者越來越多，當達到流量高峰時，伺服器經常會扛不住。這樣下去可不行，於是，我試著加了兩臺機器。現在，有了三臺伺服器，我不就能處理原來三倍的流量了嗎？

想法是挺好的，但這需要一個前提：要讓請求平攤到多臺伺服器上面，即實現簡單的負載均衡。

那麼，要怎麼做才能將請求平攤到三臺伺服器呢？我嘗試在 DNS 伺服器加上兩臺新伺服器的地址，不出所料，真的可以這麼做。因為 DNS 會基於輪循負載演算法返回地址，只要使用者拿到每個地址的機會是均衡的，請求到我伺服器也會是均衡的。於是，我的目的間接達到了。

zzs_eureka_02

一個合格的負載均衡器是怎樣的

上面的方案看起來挺好的，我自己不需要增加多餘的機器，就輕易實現了負載均衡。但是，我還是遇到了問題。

有一天，使用者訪問商城服務出現大量報錯，原因是第三臺伺服器的服務突然掛掉了，但是 1/3 的請求還是落到這一臺。因為一時排查不出問題的根源，而且重啟沒多久又會馬上掛掉，我試著把這臺伺服器的地址從 DNS 上剔除出來。然而，另一個問題出現了，DNS 的更新並沒有生效，我剔除了故障機器的地址，請求還是會落到這一臺······

經歷了這一回，我總算明白，單純使用 DNS 做負載均衡還是不靠譜。一個合格的負載均衡器至少要做到：當部分服務出現故障時，自動將其遮蔽，當服務恢復後，再將遮蔽放開。顯然，DNS 不能很好地滿足。經過研究，我發現了 nginx、SLB、ALB 等等負載均衡器，它們都可以做到這一點。最後，我選擇了 SLB 作為負載均衡器。

zzs_eureka_03

SLB 配置上要比傳統的 nginx 簡單很多，只要配置好監聽就行。SLB 會檢查後端伺服器的健康狀態，當後端某臺伺服器出現異常時，SLB 會自動將它隔離。 除此之外，它還有很多其他功能，這裡就不再擴充套件了。

有人可能會問，既然要用負載均衡器，為什麼不用 Eureka？其實，還真的不能用，原因後面會說到。我希望能夠說明一點，一個工具再怎麼優秀，它也有不適用的場合。

mid-tier services的負載均衡器

這裡涉及到兩個名詞，有必要解釋一下：

  1. edge services：向終端使用者開放的服務。例如，使用者通過瀏覽器直接訪問到的介面都屬於 edge services。
  2. mid-tier services：向其他後端服務開放的服務。有時，我們會說這種服務的呼叫是內部呼叫。

還是接著上面的例子。

我的商城業務變得越來越複雜，使用者規模也越來越大，傳統單體應用的缺點開始暴露出來：開發維護難以及資料庫瓶頸。於是，我重構了整個專案，做法比較簡單。顯然，我開始搞微服務了。

zzs_eureka_04

但是，不管我怎麼拆分，後端服務都不能做到完全獨立，例如，處理訂單業務時需要查詢客戶資訊，促銷活動有時也需要查詢客戶資訊。這個時候，每個服務都需要開放出對應的 mid-tier services 供其他後端服務呼叫，另外，為了安全以及方便管理，這部分的服務需要和 edge services 區分開（不在同一個應用）。

zzs_eureka_05

這個時候，我需要一個針對 mid-tier services 的負載均衡器。

使用SLB做負載均衡器

理所當然地，我首先想到的還是 SLB。我可以再加一臺 SLB，用於後端伺服器請求 mid-tier services。當然，mid-tier services 之間也可以相互呼叫，只是圖中不好表示出來。

zzs_eureka_06

使用Eureka做負載均衡器

後來，我發現了一個更好的方案，那就是 Eureka。和 SLB 不同，Eureka 是專門針對 mid-tier services 的負載均衡器。它主要包含三個部分：

  1. Eureka Server：存放服務名和服務對應地址的對映表，這就是我們常說的服務註冊中心。開篇的時候我說過，“Eureka 是一個服務註冊中心”這種說法是片面的，這裡就能知道原因了吧。
  2. Eureka Service：服務提供方，向 Eureka Server 註冊自己的地址。例如，mid-tier services 所在應用就屬於這一類。
  3. Eureka Client：服務消費方，從 Eureka Server 獲取 Eureka Service 的地址，並消費對應的服務，它包含內建的負載均衡器。例如，訂單服務呼叫客戶服務的 mid-tier services，那麼訂單服務就是一個 Eureka Client。

當然，這三個部分都可以進行橫向的擴充套件。

下圖只畫出了訂單服務呼叫客戶服務的示例，其他的是一樣的。

zzs_eureka_07

通過 Eureka 的結構可以知道，它並不適合作為 edge services 的負載均衡器，Eureka Client 需要具備和 Eureka Server 進行通訊的能力，而終端使用者並不具備這一點。

為什麼使用Eureka

Eureka 作為一個專門針對 mid-tier services 的負載均衡器，相比 SLB 等，還是存在很多優點。

Eureka詳解系列(一)--先談談負載均衡器
  1. Eureka 的服務註冊是無狀態。如果我新增了一百個新的服務，SLB 需要配置一百個對應的監聽，而 Eureka Server 什麼都不需要做，你只要註冊上來就行，擴充套件起來非常方便。說的直白一點，SLB 知道自己將處理哪些服務，而 Eureka Server 不會事先知道。
  2. Eureka Server 掛了，Eureka Client 還可以正常消費服務。Eureka Client 本地會快取服務地址，即使 Eureka Server 掛了，它還是能夠正常消費服務。

以上基本講完負載均衡器的內容，作為開篇，它讓我們思考：一個工具的本質是什麼？為什麼我們要用它？不用它行不行？

最後，感謝閱讀。

參考資料

https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

相關原始碼請移步：https://github.com/ZhangZiSheng001/eureka-demo

本文為原創文章，轉載請附上原文出處連結：https://www.cnblogs.com/ZhangZiSheng001/p/14313051.html

相關文章