如何進行微服務的服務注冊與發(fā)現(xiàn)

本篇文章為大家展示了如何進行微服務的服務注冊與發(fā)現(xiàn)，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

前言

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

我們將探討服務注冊和發(fā)現(xiàn)的概念及其使用機制，以使得微服務能夠在不知道其確切位置（通常是URL）的情況下消費其他服務。

服務注冊與發(fā)現(xiàn)探討

為什么需要

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

如果沒有服務注冊與服務發(fā)現(xiàn)，那么服務的位置將會耦合到消費者服務里面，最終將會導致整個系統(tǒng)的架構(gòu)變得死板而又難以維護。事實上，在比較簡單的系統(tǒng)架構(gòu)里，采用靜態(tài)配置的方式是非常簡單而又效果顯著的，畢竟所有服務都在同一位置，而且很少發(fā)生變更。

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

簡單的通信流程

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

透過這張圖，我們可以知道，服務調(diào)用時，無需知道目標服務的真實地址，只需要知道服務Key，然后到服務發(fā)現(xiàn)系統(tǒng)里獲取對應的地址即可。

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

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

在消費方拿到被消費方的地址以后，應采用何種方式調(diào)用？

我們?nèi)绾翁砑有路詹h除已棄用的服務？

如果服務在運行過程中出現(xiàn)問題，如何快速發(fā)現(xiàn)并提前通知？

作為集中化管理的服務注冊與發(fā)現(xiàn)中心掛了，咋整？

服務信息注冊

一般可以創(chuàng)建服務注冊表，該服務注冊表是服務及其實例及其位置的數(shù)據(jù)庫。服務實例在啟動時注冊到服務注冊表，并在關(guān)閉時注銷?？蛻舳瞬樵兎兆员硪圆檎曳盏目捎脤嵗?。服務注冊表可能會調(diào)用服務實例的運行狀況檢查API來驗證它是否能夠處理請求。我們已經(jīng)有了現(xiàn)成的工具，就是Consul等，那么我們的關(guān)注點就是服務地址的注冊了。

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

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

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

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

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

這個地方更多的是考慮服務消費方的負載均衡策略、調(diào)用策略以及容錯的可配置性。

在被消費方做了集群部署的時候，這就是要求我們根據(jù)實際運行情況及時調(diào)整對服務的調(diào)用，那么該如何判斷呢？在實現(xiàn)上可以考慮權(quán)重參數(shù)，該參數(shù)的設置應該來源于自身以及服務治理系統(tǒng)。

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

來源于服務治理系統(tǒng)，是因為在實際運行中，可能該系統(tǒng)已經(jīng)出現(xiàn)問題，或者需要暫時下線，我們可以設置權(quán)重系數(shù)為0，以從消費服務本身來停止對該服務的調(diào)用。

權(quán)重參數(shù)只是其中一個，也是最容易想到和實現(xiàn)的一個，當然還有其他參數(shù)，只要是為了更好的優(yōu)化服務間的調(diào)用，那么就可以注冊進去，同時實現(xiàn)相應的調(diào)用策略。比如版本號，TTL等等。

一旦信息多了，就需要考慮如何及時獲取變更，以調(diào)整調(diào)用策略。

服務發(fā)現(xiàn)

服務發(fā)現(xiàn)可以分為客戶端發(fā)現(xiàn)或服務器端發(fā)現(xiàn)來確定要向其發(fā)送請求的服務實例的位置?？蛻舳税l(fā)現(xiàn)比較簡單一些，直接向服務發(fā)現(xiàn)中心獲取所需的被消費者服務的信息。而服務端發(fā)現(xiàn)相對來說，比較復雜，需要創(chuàng)建一個路由中心，由路由中心去發(fā)現(xiàn)被消費者的請求。我們這邊用的比較多的是客戶端發(fā)現(xiàn)。

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

服務實例的數(shù)量及其位置是動態(tài)變化的。通常為虛擬機和容器分配動態(tài)IP地址。最復雜的問題自然是如何及時獲得被消費者服務變化后的地址？我們可以創(chuàng)建一個路由功能，用戶可以客戶端查詢服務注冊中心以查找服務的可用實例。服務注冊中心可能會調(diào)用服務實例的運行狀況檢查API來驗證它是否能夠處理請求。

我們在系統(tǒng)啟動的時候，會做個Reload，以加載最新信息。那么之后如何及時獲取最新信息呢？通常情況下有兩種，主動輪詢和獲取推送消息。

主動輪詢帶有隨機性，如果恰恰好，可能會很及時，大多數(shù)情況下，可能沒那么恰恰好，而且還要增加服務發(fā)現(xiàn)中心的負載壓力。

推送方式在效果上可能更好一些，在具體實現(xiàn)上可能沒有那么簡單。

健康檢查

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

首先來說，客戶端心跳，就是客戶端通過TCP或者HTTP的方式，告訴服務端自身的運行情況，當然客戶端通知是有弊端的，比如客戶端在某一時間點出現(xiàn)故障時，無法及時通知服務端，事后恢復運行后，告知的也只是當前的運行狀態(tài)，即便這時再告訴服務端之前的運行狀況，也對服務調(diào)用沒有什么太大意義了，只是對服務本身的運行分析起到了一定作用。即便是保持正常連接的情況下，服務也未必是可以調(diào)用的，比如數(shù)據(jù)庫掛掉。

一般而言，采用服務端探測的比較多一些，調(diào)用方式和客戶端心跳差不多，但是仍然需要我們注意的是，客戶端所提供的探測接口必須具有通用性，比如可以查一下次數(shù)據(jù)庫等等，這樣可以比較全面的反應系統(tǒng)的運行情況。

容災與故障轉(zhuǎn)移

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

容災主要考慮方向是客戶端容災和服務端容災?？蛻舳巳轂闹校绻兆灾行膾斓袅?，恢復運行可能需要一段時間，在這個過程中如果保證服務正常運行。在實際運行中非常有可能發(fā)生這種情況，我們可以將服務發(fā)現(xiàn)中心獲取的信息緩存起來，緩存方式有很多，無外乎是本地內(nèi)存、文件以及外部存儲，本地內(nèi)存還要還要考慮該服務重啟過程中的數(shù)據(jù)丟失，所以可選的方式就有內(nèi)存+文件方式。反之，為了達到容災的要求，我們可以在獲取服務發(fā)現(xiàn)中心返回的數(shù)據(jù)的過程中將數(shù)據(jù)存在到內(nèi)存和文件中，可以采用異步方式存儲。

如下圖所示，在發(fā)現(xiàn)過程中，使用緩存功能，如果緩存都失效了，那就真的要game over一陣子了。

服務端容災，就比較簡單了，因為現(xiàn)在大多數(shù)做的都是服務端容災，比如集群等水平擴展方式， 可主動從其他節(jié)點同步相應的數(shù)據(jù)，也可等待master的同步。

服務注冊與發(fā)現(xiàn)在服務生命周期中發(fā)揮著重要作用。動態(tài)的服務注冊和發(fā)現(xiàn)變得非常重要，它可以避免服務中斷。在處理服務實例的容災與故障轉(zhuǎn)移時，盡量實現(xiàn)自動轉(zhuǎn)移，并提供手動方式處理，而對于跨服務調(diào)用，尤其是該服務擁有多實例服務的時候，需要考慮負載平衡。

上述內(nèi)容就是如何進行微服務的服務注冊與發(fā)現(xiàn)，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。