響應式微服務 in java 譯 <十二> service discovery

以前的內容重點都是在講構建微服務，可是這節都是關於構建系統，一樣，一個微服務並不能提供服務--它們是經過系統來實現的。當您採用微服務架構風格時，您將擁有數十個微服務。像咱們在上一章中所作的那樣，管理兩個微服務是很容易的。您使用的微服務越多，應用程序就越複雜。

首先，咱們將學習如何使用服務發現來解決位置透明性和移動性問題。而後，咱們將討論恢復力和穩定性模式，如超時、中斷和故障。

Service Discovery

當你有一組微服務時，你必須回答的第一個問題是：這些微服務將如何相互定位？爲了與另外一個對等方通訊，微服務須要知道其地址。正如咱們在上一章中所作的那樣，咱們能夠在代碼中硬編碼地址(事件總線地址、URL、位置細節等)，或者將其外部化爲配置文件。然而，這種解決方案不能有移動性。您的應用程序將至關嚴格，不一樣的部分將沒法移動，這與咱們試圖經過微服務實現的目標相矛盾。

Client- and Server-Side Service Discovery

微型服務須要是可移動的，但也是可尋址的。消費者須要可以與微服務進行通訊，而無需事先知道其確切位置，特別是由於這個位置可能會隨着時間的推移而改變。位置透明性提供了彈性和動態性：消費者可使用循環策略調用不一樣的微服務實例，在兩次調用之間，Microservice可能已被移動或更新。

位置透明性能夠經過一種稱爲服務發現的模式來解決。每一個微服務都應該公佈如何調用它及其特性，固然包括它的位置，還應該公佈其餘元數據，如安全策略或版本。這些公告存儲在服務發現基礎結構中，該基礎結構一般是由執行環境提供的服務註冊中心。微型服務還能夠決定將其服務從註冊表中撤回。一個尋找另外一個服務的微服務也能夠搜索這個服務註冊中心以找到匹配的服務，選擇最好的服務(使用任何類型的標準)，而後開始使用它。

可使用兩種類型的模式來使用服務。當使用客戶端服務發現時，使用者服務根據服務註冊表中的名稱和元數據查找服務，選擇匹配的服務並使用它。從服務註冊中心檢索的引用包含指向微服務的直接連接。因爲微服務是動態實體，服務發現基礎設施不只必須容許提供者發佈其服務，並且容許使用者查找服務，同時也提供了有關航班抵達和離開的信息。當使用客戶端服務發現時，服務註冊中心能夠採起各類形式，例如分佈式數據結構、專用的基礎設施(如Consul)，或者存儲在庫存服務中，例如ApacheZooKeeptor或Redis。

或者，您可使用服務器端服務發現，讓負載均衡器、路由器、代理或API網關爲您管理髮現(圖4-2)。使用者仍然根據服務的名稱和元數據查找服務，但檢索虛擬地址。當使用者調用服務時，請求被路由到實際實現。您能夠在Kubernetes或使用AWS彈性負載均衡器時使用此機制。

Vert.x Service Discovery

Vert.x提供了一種可擴展的服務發現機制。您可使用相同的API使用客戶端或服務器端服務發現。那個Vert.x發現能夠從許多類型的服務發現基礎設施(如Consuer或Kubernetes)導入或導出服務(圖4-3)。它也能夠在沒有任何專用服務發現基礎設施的狀況下使用。在這種狀況下，它使用Vert集羣上共享的分佈式數據結構。

 

您能夠按類型檢索服務，以使已配置的服務客戶端能夠隨時使用。服務類型能夠是HTTP端點、事件總線地址、數據源等。例如，若是您想檢索咱們在上一章中實現的名爲hello的HTTP端點，您能夠編寫如下代碼：

檢索到的WebClient配置了服務位置，這意味着您能夠當即使用它來調用服務。若是您的環境使用客戶端發現，則配置的URL將針對服務的特定實例。若是使用服務器端發現，則客戶端使用虛擬URL。

根據您的運行時基礎結構，您可能必須註冊您的服務。可是在使用服務器端服務發現時，一般沒必要這樣作，由於在部署服務時聲明瞭服務。不然，您須要顯式地發佈服務。要發佈服務，須要建立包含服務名稱、位置和元數據的記錄：

服務發現是微服務基礎結構中的一個關鍵組件。它使動態、位置透明性和流動性成爲可能。當處理一小部分服務時，服務發現可能看起來很麻煩，但當系統增加時，這是必須的。那個Vert.x服務發現爲您提供了惟一的API，而無論您使用的基礎結構和服務發現類型如何。然而，當你的系統增加時，還有另外一個指數增加的變量--失敗

 

原文地址：

https://developers.redhat.com/promotions/building-reactive-microservices-in-java/

有什麼討論的內容，能夠加我微信公衆號：