1. 程式人生 > >java B2B2C電子商務平臺分析之十五-----EureKa服務註冊與發現

java B2B2C電子商務平臺分析之十五-----EureKa服務註冊與發現

什麼是服務發現與服務註冊

簡單的來說就是一個微服務要呼叫另一個微服務,就必須知道這個微服務的地址及埠資訊。採用一張登錄檔,註冊上線可用的微服務及相關資訊,微服務則從登錄檔上查詢所需的其它微服務的相關資訊。有兩種主要的服務發現模式:客戶端服務發現(client-side discovery)和伺服器端服務發現(server-side discovery)願意瞭解原始碼的朋友直接求求交流分享技術:二一四七七七五六三三

客戶端發現

服務端服務發現

當傳送請求到一個service的時候,客戶端傳送請求到一個router,這個router是在一個已知的地址上執行的。router查詢service registry(可能在這個router中實現), 然後把請求傳送到可用的service例項。如下所示: 

服務發現元件的功能

服務登錄檔 
服務登錄檔是一個記錄當前可用服務例項的網路資訊的資料庫,是服務發現機制的核心。服務登錄檔提供查詢API和管理API,使用查詢API獲得可用的服務例項,使用管理API實現註冊和登出;
服務註冊 
服務註冊:服務啟動時,將服務的網路地址註冊到服務登錄檔中;
健康檢查 
服務發現元件會通過一些機制定時檢測已註冊的服務,如果發現某服務無法訪問了(可能是某幾個心跳週期後),就將該服務從服務登錄檔中移除。
服務發現元件:Eureka

Eureka是客戶端發現型別的服務發現模式
Eureka來自生產環境
Spring Cloud對Eureka支援很好

上圖是來自Eureka官方的架構圖,大致描述了Eureka叢集的工作過程。 
Eureka有兩個概念,區域(Region)與可用區(Zone),不太理解,先抄過來佔個位置。

區域(Region):

AWS雲服務在全球不同的地方都有資料中心,比如北美、南美、歐洲和亞洲等。與此對應,根據地理位置我們把某個地區的基礎設施服務集合稱為一個區域。通過AWS的區域,一方面可以使得AWS雲服務在地理位置上更加靠近我們的使用者,另一方面使得使用者可以選擇不同的區域儲存他們的資料以滿足法規遵循方面的要求。美東(北佛吉尼亞)、美西(俄勒岡)、美西(北加利佛尼亞)、歐洲(愛爾蘭)、亞太(新加坡)、亞太(東京)等。每個區域都有自己對應的編碼,如:編碼對應
可用區(Zone):

AWS的每個區域一般由多個可用區(AZ)組成,而一個可用區一般是由多個數據中心組成。AWS引入可用區設計主要是為了提升使用者應用程式的高可用性。因為可用區與可用區之間在設計上是相互獨立的,也就是說它們會有獨立的供電、獨立的網路等,這樣假如一個可用區出現問題時也不會影響另外的可用區。在一個區域內,可用區與可用區之間是通過高速網路連線,從而保證有很低的延時。AWS的區域與可用區的關係示意如下圖所示:可用區 
每次當用戶需要使用EC2相關資源的時候,他需要首先選擇目標區域,如美東(北佛傑尼亞)us-east-1。然後在建立EC2例項的時候,使用者可以選擇例項所在的可用區,比如可以是us-east-1a或us-east-1b等。可用區的編碼就是區域後面順序新增不同的英文字母。
Eureka在springcloud中的使用

Eureka包含兩個元件:Eureka Server 和 Eureka Client。

Eureka Server提供服務註冊服務,各個節點啟動後,會在Eureka Server中進行註冊,這樣Eureka Server中的服務登錄檔中將會儲存所有可用服務節點的資訊,服務節點的資訊可以在介面中直觀的看到。
Eureka Client是一個Java客戶端,用於簡化與Eureka Server的互動,客戶端同時也具備一個內建的、使用輪詢(round-robin)負載演算法的負載均衡器。
在應用啟動後,將會向Eureka Server傳送心跳(預設週期為30秒)。如果Eureka Server在多個心跳週期內沒有接收到某個節點的心跳,Eureka Server將會從服務登錄檔中把這個服務節點移除(預設90秒)。
Eureka Server之間將會通過複製的方式完成資料的同步。
Eureka還提供了客戶端快取的機制,即使所有的Eureka Server都掛掉,客戶端依然可以利用快取中的資訊消費其他服務的API。
綜上,Eureka通過心跳檢測、健康檢查、客戶端快取等機制,確保了系統的高可用性、靈活性和可伸縮性。

整體程式碼結構如下: