服務註冊與發現 | 上手實踐Spring Cloud Eureka 和 Feign(一)

語言: CN / TW / HK

theme: scrolls-light

這是我參與11月更文挑戰的第8天,活動詳情檢視:2021最後一次更文挑戰

在微服務時代,服務的註冊發現主要是為了解決兩個問題,一個是遮蔽服務與服務之間依賴的細節,即解耦;另一個是滿足對服務的動態管理。這篇文章就服務註冊和發現,上手實現Netflix的Eureka和Feign。

一、服務註冊發現模式

在實踐之前,我們先來了解服務註冊與發現的一些簡單概念。
服務發現與註冊 一般有兩種實現模式: - 伺服器端模式 - 客戶端模式

伺服器端模式通過使用一箇中間的伺服器,來遮蔽被呼叫服務的複雜性與變動性,當有新的服務加入或老服務剔除時,只需要修改中間伺服器上的配置即可。

這種模式,常見的做法是提供一個具備負載均衡的伺服器作為中間層,比如Nginx,F5,網路傳輸層的Ip負載均衡,即配置集中在獨立的中間伺服器端完成,對程式碼沒有任何侵入性。缺點是,呼叫鏈過程中,要透穿中間伺服器,中間層勢必成為一個呼叫鏈中的單點,很有可能成為效能的瓶頸。

藍圖編排設計.png

客戶端服務發現模式允許服務在沒有硬編碼主機名和埠的情況下彼此查詢和通訊。這種架構中比較核心的概念是,服務必須統一註冊到服務註冊中心。比較有代表性的有Eureka、Consul、Zookeeper等等,其異同如下:

image.png

這種模式不需要穿透中間伺服器,所以效能損耗比較小,但是需要在服務內部維護註冊資訊,負載均衡策略,對程式碼有侵入性,並且要引入一個新的註冊中心服務,如果要考慮到服務的可用性以及可靠性,其維護維護成本也會增加。

image.png


少年,沒看夠?點選石頭的主頁,隨便點點看看,說不定有驚喜呢?歡迎支援點贊/關注/評論,有你們的支援是我更文最大的動力,多謝啦!