微服務模式（二）：服務發現

我是獸獸，從事雲計算的健身萌妹紙，不定期更新5G&IoT內容，更多好貨可關注公號：5G物聯網世界。

現代面向服務的體系結構(其中每個微服務通常在一個容器環境中運行)解決了早期單片軟件系統提出的許多問題。它們按需模塊化地伸縮。然而，如果沒有正確的模式，管理服務間調用和在容器集群中動態地轉移服務位置可能是具有挑戰性的。好的服務器端或客戶端服務發現工具可以管理動態服務註冊中心，從而解決這個問題。

對於單片應用程序，服務通過語言級別的方法或過程調用彼此調用。這是相對簡單和可預測的行為，但是隨著應用程序複雜性的增加，單片應用程序變得不適合現代軟件系統的規模和需求。這導致了向SOA或面向服務的體系結構的轉變。這些巨石被拆成更小的塊，通常有特定的用途。

SOA通過服務間調用將其自身的注意事項引入到圖中。SOA服務在眾所周知的固定位置運行，這導致了服務的靜態位置、IP地址和部署的重新配置問題等。

構建微服務系統困難重重

使用微服務，應用程序通常在虛擬或容器化的環境中運行，其中服務的實例數量和這些服務的位置可以動態頻繁地更改。這使我們能夠根據動態應用於應用程序的力來伸縮應用程序，但是這種靈活性本身也存在一些問題。其中一個主要問題是不知道您的服務在哪裡與他們聯繫。沒有正確的模式，這幾乎是不可能的。

通過服務發現，服務在啟動時向動態服務註冊中心註冊。除了正在運行的IP地址和端口之外，它還經常提供元數據，如服務版本或客戶端在查詢註冊中心時可以使用的其他環境參數。

服務註冊中心的一些常見示例是領事和Etcd。這些系統具有高度可伸縮性，並且具有嚴格一致的方法來存儲服務的位置。除此之外，領事還可以對服務進行健康檢查，以確保其可用性和完整性。如果服務未能通過健康檢查，則在註冊中心中將其標記為不可用，任何查詢都不會返回該服務。

服務發現有兩種主要模式:服務器端和客戶端。

服務器端服務發現

服務器端服務發現是同一應用程序中用於服務間調用的微服務反模式。這是我們在SOA環境中用來調用服務的方法。通常，會有一個反向代理充當到服務的網關。它聯繫動態服務註冊中心，並將您的請求轉發到後端服務。然後，客戶端通過使用子域或路徑作為區分器實現一個已知URL來訪問後端服務。

最終，服務器端發現將遇到一些眾所周知的問題，其中之一是反向代理瓶頸。後端服務可以快速擴展，但是需要監控。它還引入了延遲，導致運行和維護應用程序的成本增加。

服務器端發現還可能增加下游調用、內部服務和外部服務的故障模式。有了服務器端發現，您需要在服務器端有一個集中的失敗邏輯，它從客戶端提取大部分API知識，在內部處理失敗，並在內部不斷重試，同時保持客戶端完全的距離，直到成功或災難性的失敗。

客戶端服務發現

對於任何內部服務間通信，服務器端服務發現可能是公共api可以接受的選擇。但是，我更喜歡客戶端模式。這使您能夠更好地控制失敗發生時的情況。您可以在逐個失敗的重試基礎上實現業務邏輯。這還可以防止級聯失敗。

這個模式與它的服務器端夥伴類似。但是，客戶端負責服務發現和負載平衡。仍然需要動態服務註冊中心來獲取將要調用的服務的信息。此邏輯在每個客戶機中都是本地化的，因此可以逐個處理故障邏輯。