歡迎光臨
每天分享高質量文章

微服務探索與實踐—服務註冊與發現

前言

微服務從大規模使用到現在已經有很多年了,從之前的探索到一步步的不斷完善與成熟,微服務已經成為眾多架構選擇中所必須面對的一個選項。服務註冊與發現是相輔相成的,所以一般會合起來思索。其依托組件有很多,比如Zookeeper,Consul,Eureka等等。

本文,我們將探討服務註冊和發現的概念及其使用機制,以使得微服務能夠在不知道其確切位置(通常是URL)的情況下消費其他服務。由於本文主要是個人實踐的一些總結,總會有不足之處,也希望各位看官幫忙完善。本系列前一篇文章請移步總述

服務註冊與發現探討

為什麼需要

服務是在具有單獨部署周期的不同計算機上運行的單個或較小的代碼庫,可明確解決相關的問題域。不正確的服務設計可能導致重覆的服務創建,同時也無法進行架構層面的復用。

如果沒有服務註冊與服務發現,那麼服務的位置將會耦合到消費者服務裡面,最終將會導致整個系統的架構變得死板而又難以維護。事實上,在比較簡單的系統架構里,採用靜態配置的方式是非常簡單而又效果顯著的,畢竟所有服務都在同一位置,而且很少發生變更。

而在微服務里,其標的之一就是使系統能夠獨立開發、部署及升級擴展,隨著系統的進一步複雜,服務位置也發生變更,那麼靜態配置就會變得十分雞肋,此時我們需要變更我們的策略,那就是在消費其他服務的時候採用靜態配置。那麼核心問題就來了,服務是如何發現它們索要消費的服務的IP地址和端口號的?既是動態配置,在多實體場景下,配置在專門的系統里是最好的選擇,ZK和Consul等也就應運而生。

簡單的通信流程

我們來看一下一個簡單的服務通信流程

透過這張圖,我們可以知道,服務呼叫時,無需知道標的服務的真實地址,只需要知道服務Key,然後到服務發現系統里獲取對應的地址即可。

這張圖雖然比較簡單,但是傳遞的信息卻有很多:

服務如何確定自身的IP地址及端口?

在消費方拿到被消費方的地址以後,應採用何種方式呼叫?

我們如何添加新服務並刪除已棄用的服務?

如果服務在運行過程中出現問題,如何快速發現並提前通知?

作為集中化管理的服務註冊與發現中心掛了,咋整?

服務信息註冊

一般可以創建服務註冊表,該服務註冊表是服務及其實體及其位置的資料庫。服務實體在啟動時註冊到服務註冊表,併在關閉時註銷。客戶端查詢服務註冊表以查找服務的可用實體。服務註冊表可能會呼叫服務實體的運行狀況檢查API來驗證它是否能夠處理請求。我們已經有了現成的工具,就是Consul等,那麼我們的關註點就是服務地址的註冊了。

最簡單的解決方案就是手動配置。我們思考一個問題,如果我們需要對該服務進行水平擴展,再增加一個實體的時候,仍然需要我們手動配置,但是我們已經不想手動配置了,在DevOps時代,再使用手動配置,就顯得不那麼專業了,而且人工的介入,也增加了系統運維的成本與風險。

所以我們選擇,自動獲取本機IP地址,但是這裡有一個問題,也是我在實際運用中遇到的問題就是本地會有多個網卡的情況,這是比較麻煩的,所以那時候我建議每台機器只配置一個網卡,以減少不確定性,但是後來,遇到一個新的問題就是,當我想在服務器上安裝代理,以獲取請求包信息的時候,容易改變系統的運行環境,依然存在著不確定性。後來我在網上查看是否其他方案的時候,始終沒有一個比較好的解決方案,後來有人說,直接往服務註冊中心發送一個Socket連接就可以了,通過Socket實體獲取本機IP,網上也有人介紹這種方案。

至於端口獲取,相對簡單一點,我們使用的就是直接配置在服務里。

服務註冊本身就是要在有限人力干預的情況下,支持不同應用之間的運行與交互。

服務註冊擴展至之其他信息的註冊

這個地方更多的是考慮服務消費方的負載均衡策略、呼叫策略以及容錯的可配置性。

在被消費方做了集群部署的時候,這就是要求我們根據實際運行情況及時調整對服務的呼叫,那麼該如何判斷呢?在實現上可以考慮權重引數,該引數的設置應該來源於自身以及服務治理系統。

來源於自身,是因為我們的服務可能部署在相對較差的機器上或者該服務本身只是一個備用系統,不應該承載過大的流量。

來源於服務治理系統,是因為在實際運行中,可能該系統已經出現問題,或者需要暫時下線,我們可以設置權重繫數為0,以從消費服務本身來停止對該服務的呼叫。

權重引數只是其中一個,也是最容易想到和實現的一個,當然還有其他引數,只要是為了更好的優化服務間的呼叫,那麼就可以註冊進去,同時實現相應的呼叫策略。比如版本號,TTL等等。

一旦信息多了,就需要考慮如何及時獲取變更,以調整呼叫策略。

服務發現

服務發現可以分為客戶端發現或服務器端發現來確定要向其發送請求的服務實體的位置。客戶端發現比較簡單一些,直接向服務發現中心獲取所需的被消費者服務的信息。而服務端發現相對來說,比較複雜,需要創建一個路由中心,由路由中心去發現被消費者的請求。我們這邊用的比較多的是客戶端發現。

確保發現的穩定性,首先就要確保服務註冊中心的穩定性,其地址不應該頻繁發生變化,所以我們可以在服務中配置我們的服務註冊中的地址。此處需要多說明一下,就是作為服務註冊中心系統,一定要保持高可用性,可以通過集群以及負載均衡來增強可用性。

服務實體的數量及其位置是動態變化的。通常為虛擬機和容器分配動態IP地址。最複雜的問題自然是如何及時獲得被消費者服務變化後的地址?我們可以創建一個路由功能,用戶可以客戶端查詢服務註冊中心以查找服務的可用實體。服務註冊中心可能會呼叫服務實體的運行狀況檢查API來驗證它是否能夠處理請求。

我們在系統啟動的時候,會做個Reload,以加載最新信息。那麼之後如何及時獲取最新信息呢?通常情況下有兩種,主動輪詢和獲取推送訊息。

主動輪詢帶有隨機性,如果恰恰好,可能會很及時,大多數情況下,可能沒那麼恰恰好,而且還要增加服務發現中心的負載壓力。

推送方式在效果上可能更好一些,在具體實現上可能沒有那麼簡單。

健康檢查

一般而言,健康檢查包括,客戶端心跳和服務端主動探測兩種方式,

首先來說,客戶端心跳,就是客戶端通過TCP或者HTTP的方式,告訴服務端自身的運行情況,當然客戶端通知是有弊端的,比如客戶端在某一時間點出現故障時,無法及時通知服務端,事後恢復運行後,告知的也只是當前的運行狀態,即便這時再告訴服務端之前的運行狀況,也對服務呼叫沒有什麼太大意義了,只是對服務本身的運行分析起到了一定作用。即便是保持正常連接的情況下,服務也未必是可以呼叫的,比如資料庫掛掉。

一般而言,採用服務端探測的比較多一些,呼叫方式和客戶端心跳差不多,但是仍然需要我們註意的是,客戶端所提供的探測接口必須具有通用性,比如可以查一下次資料庫等等,這樣可以比較全面的反應系統的運行情況。

容災與故障轉移

容災的原因有很多,比如服務不再使用、雙11大流量的涌進,使得其中一些服務不可用,也就不得不針對性的對一些服務進行容災處理,以集中資源給核心應用。在容災過程中,可以給服務下線功能可以制定一些策略,以豐富功能的使用。.NET Core裡面可以使用IApplicationLifetime來顯示下線功能。當然也需要提供手動下線的接口。

容災主要考慮方向是客戶端容災和服務端容災。客戶端容災中,如果服務註冊中心掛掉了,恢復運行可能需要一段時間,在這個過程中如果保證服務正常運行。在實際運行中非常有可能發生這種情況,我們可以將服務發現中心獲取的信息快取起來,快取方式有很多,無外乎是本地記憶體、檔案以及外部儲存,本地記憶體還要還要考慮該服務重啟過程中的資料丟失,所以可選的方式就有記憶體+檔案方式。反之,為了達到容災的要求,我們可以在獲取服務發現中心傳回的資料的過程中將資料存在到記憶體和檔案中,可以採用異步方式儲存。

如下圖所示,在發現過程中,使用快取功能,如果快取都失效了,那就真的要game over一陣子了。

服務端容災,就比較簡單了,因為現在大多數做的都是服務端容災,比如集群等水平擴展方式, 可主動從其他節點同步相應的資料,也可等待master的同步。

總結

服務註冊與發現在服務生命周期中發揮著重要作用。動態的服務註冊和發現變得非常重要,它可以避免服務中斷。在處理服務實體的容災與故障轉移時,儘量實現自動轉移,並提供手動方式處理,而對於跨服務呼叫,尤其是該服務擁有多實體服務的時候,需要考慮負載平衡。

赞(0)

分享創造快樂