前言

微服務從大規模使用到現在已經有很多年了，從之前的探索到一步步的不斷完善與成熟，微服務已經成為眾多架構選擇中所必須面對的一個選項。服務注冊與發現是相輔相成的，所以一般會合起來思索。其依托組件有很多，比如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的同步。

總結

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

總結

以上是生活随笔為你收集整理的微服务探索与实践—服务注册与发现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。