這個系列開始研究 Eureka，在此之前，先來談談負載均衡器。
本質上，Eureka 就是一個負載均衡器，可能有的人會說，它是一個服務註冊中心，用來註冊服務的，這種說法不能說錯，只是有點片面。
在這篇博客裏，我將盡可能循序漸進、圖文並茂地回答下面的幾個問題。至於 Eureka 的使用、配置、源碼分析、集羣配置等等，這些後續博客再補充。
- 爲什麼要用負載均衡器？
- 一個合格的負載均衡器是怎樣的？
- mid-tier services 的負載均衡器？
- 爲什麼使用 Eureka？
爲什麼要用負載均衡器
那麼，先從一個例子開始。
假設我有一個網上商城的項目，在項目初期，它是一個傳統的單體應用，沒有集羣，沒有微服務。顯然，這個時候我不需要考慮所謂的負載均衡。
隨着應用的推廣，我的用戶越來越多，當達到流量高峯時，服務器經常會扛不住。這樣下去可不行，於是，我試着加了兩臺機器。現在，有了三臺服務器，我不就能處理原來三倍的流量了嗎？
想法是挺好的，但這需要一個前提：要讓請求平攤到多臺服務器上面，即實現簡單的負載均衡。
那麼，要怎麼做才能將請求平攤到三臺服務器呢？我嘗試在 DNS 服務器加上兩臺新服務器的地址，不出所料，真的可以這麼做。因爲 DNS 會基於輪循負載算法返回地址，只要用戶拿到每個地址的機會是均衡的，請求到我服務器也會是均衡的。於是，我的目的間接達到了。
一個合格的負載均衡器是怎樣的
上面的方案看起來挺好的，我自己不需要增加多餘的機器，就輕易實現了負載均衡。但是，我還是遇到了問題。
有一天，用戶訪問商城服務出現大量報錯，原因是第三臺服務器的服務突然掛掉了，但是 1/3 的請求還是落到這一臺。因爲一時排查不出問題的根源，而且重啓沒多久又會馬上掛掉，我試着把這臺服務器的地址從 DNS 上剔除出來。然而，另一個問題出現了，DNS 的更新並沒有生效，我剔除了故障機器的地址，請求還是會落到這一臺······
經歷了這一回，我總算明白，單純使用 DNS 做負載均衡還是不靠譜。一個合格的負載均衡器至少要做到：當部分服務出現故障時，自動將其屏蔽，當服務恢復後，再將屏蔽放開。顯然，DNS 不能很好地滿足。經過研究，我發現了 nginx、SLB、ALB 等等負載均衡器，它們都可以做到這一點。最後，我選擇了 SLB 作爲負載均衡器。
SLB 配置上要比傳統的 nginx 簡單很多，只要配置好監聽就行。SLB 會檢查後端服務器的健康狀態，當後端某臺服務器出現異常時，SLB 會自動將它隔離。 除此之外，它還有很多其他功能，這裏就不再擴展了。
有人可能會問，既然要用負載均衡器，爲什麼不用 Eureka？其實，還真的不能用，原因後面會說到。我希望能夠說明一點，一個工具再怎麼優秀，它也有不適用的場合。
mid-tier services的負載均衡器
這裏涉及到兩個名詞，有必要解釋一下：
- edge services：向終端用戶開放的服務。例如，用戶通過瀏覽器直接訪問到的接口都屬於 edge services。
- 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 的負載均衡器。它主要包含三個部分：
- Eureka Server：存放服務名和服務對應地址的映射表，這就是我們常說的服務註冊中心。開篇的時候我說過，“Eureka 是一個服務註冊中心”這種說法是片面的，這裏就能知道原因了吧。
- Eureka Service：服務提供方，向 Eureka Server 註冊自己的地址。例如，mid-tier services 所在應用就屬於這一類。
- Eureka Client：服務消費方，從 Eureka Server 獲取 Eureka Service 的地址，並消費對應的服務，它包含內置的負載均衡器。例如，訂單服務調用客戶服務的 mid-tier services，那麼訂單服務就是一個 Eureka Client。
當然，這三個部分都可以進行橫向的擴展。
下圖只畫出了訂單服務調用客戶服務的示例，其他的是一樣的。
通過 Eureka 的結構可以知道，它並不適合作爲 edge services 的負載均衡器，Eureka Client 需要具備和 Eureka Server 進行通信的能力，而終端用戶並不具備這一點。
爲什麼使用Eureka
Eureka 作爲一個專門針對 mid-tier services 的負載均衡器，相比 SLB 等，還是存在很多優點。
- Eureka 的服務註冊是無狀態。如果我新增了一百個新的服務，SLB 需要配置一百個對應的監聽，而 Eureka Server 什麼都不需要做，你只要註冊上來就行，擴展起來非常方便。說的直白一點，SLB 知道自己將處理哪些服務，而 Eureka Server 不會事先知道。
- Eureka Server 掛了，Eureka Client 還可以正常消費服務。Eureka Client 本地會緩存服務地址，即使 Eureka Server 掛了，它還是能夠正常消費服務。
以上基本講完負載均衡器的內容，作爲開篇，它讓我們思考：一個工具的本質是什麼？爲什麼我們要用它？不用它行不行？
最後，感謝閱讀。
參考資料
https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance
本文爲原創文章，轉載請附上原文出處鏈接：https://www.cnblogs.com/ZhangZiSheng001/p/14313051.html