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

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

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

在這篇博客裏，我將盡量按部就班、圖文並茂地回答下面的幾個問題。至於 Eureka 的使用、配置、源碼分析、集羣配置等等，這些後續博客再補充。

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

爲何要用負載均衡器

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

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

隨着應用的推廣，個人用戶愈來愈多，當達到流量高峯時，服務器常常會扛不住。這樣下去可不行，因而，我試着加了兩臺機器。如今，有了三臺服務器，我不就能處理原來三倍的流量了嗎？

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

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

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

上面的方案看起來挺好的，我本身不須要增長多餘的機器，就輕易實現了負載均衡。可是，我仍是遇到了問題。

有一天，用戶訪問商城服務出現大量報錯，緣由是第三臺服務器的服務忽然掛掉了，可是 1/3 的請求仍是落到這一臺。由於一時排查不出問題的根源，並且重啓沒多久又會立刻掛掉，我試着把這臺服務器的地址從 DNS 上剔除出來。然而，另外一個問題出現了，DNS 的更新並無生效，我剔除了故障機器的地址，請求仍是會落到這一臺······

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

SLB 配置上要比傳統的 nginx 簡單不少，只要配置好監聽就行。SLB 會檢查後端服務器的健康狀態，當後端某臺服務器出現異常時，SLB 會自動將它隔離。 除此以外，它還有不少其餘功能，這裏就再也不擴展了。

有人可能會問，既然要用負載均衡器，爲何不用 Eureka？其實，還真的不能用，緣由後面會說到。我但願可以說明一點，一個工具再怎麼優秀，它也有不適用的場合。

mid-tier services的負載均衡器

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

1. edge services：向終端用戶開放的服務。例如，用戶經過瀏覽器直接訪問到的接口都屬於 edge services。
2. mid-tier services：向其餘後端服務開放的服務。有時，咱們會說這種服務的調用是內部調用。

仍是接着上面的例子。

個人商城業務變得愈來愈複雜，用戶規模也愈來愈大，傳統單體應用的缺點開始暴露出來：開發維護難以及數據庫瓶頸。因而，我重構了整個項目，作法比較簡單。顯然，我開始搞微服務了。

可是，無論我怎麼拆分，後端服務都不能作到徹底獨立，例如，處理訂單業務時須要查詢客戶信息，促銷活動有時也須要查詢客戶信息。這個時候，每一個服務都須要開放出對應的 mid-tier services 供其餘後端服務調用，另外，爲了安全以及方便管理，這部分的服務須要和 edge services 區分開（不在同一個應用）。

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

使用SLB作負載均衡器

理所固然地，我首先想到的仍是 SLB。我能夠再加一臺 SLB，用於後端服務器請求 mid-tier services。固然，mid-tier services 之間也能夠相互調用，只是圖中很差表示出來。

使用Eureka作負載均衡器

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

1. Eureka Server：存放服務名和服務對應地址的映射表，這就是咱們常說的服務註冊中心。開篇的時候我說過，「Eureka 是一個服務註冊中心」這種說法是片面的，這裏就能知道緣由了吧。
2. Eureka Client for application service：服務提供方，向 Eureka Server 註冊本身的地址。例如，mid-tier services 所在應用就屬於這一類。
3. Eureka Client for application client：服務消費方，從 Eureka Server 獲取 application service 的地址，並消費對應的服務，它包含內置的負載均衡器。例如，訂單服務調用客戶服務的 mid-tier services，那麼訂單服務就是一個 application client。

固然，這三個部分均可以進行橫向的擴展。

下圖只畫出了訂單服務調用客戶服務的示例，其餘的是同樣的。

經過 Eureka 的結構能夠知道，它並不適合做爲 edge services 的負載均衡器，Eureka Client 須要具有和 Eureka Server 進行通訊的能力，而終端用戶並不具有這一點。

爲何使用Eureka

Eureka 做爲一個專門針對 mid-tier services 的負載均衡器，相比 SLB 等，仍是存在不少優勢。

1. Eureka 的服務註冊是無狀態。若是我新增了一百個新的服務，SLB 須要配置一百個對應的監聽，而 Eureka Server 什麼都不須要作，你只要註冊上來就行，擴展起來很是方便。說的直白一點，SLB 知道本身將處理哪些服務，而 Eureka Server 不會事先知道。
2. Eureka Server 掛了，Eureka Client 還能夠正常消費服務。Eureka Client 本地會緩存服務地址，即便 Eureka Server 掛了，它仍是可以正常消費服務。

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

最後，感謝閱讀。

參考資料

Eureka github文檔

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

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