前言
微服務從大規模使用到現在已經有很多年了，從之前的探索到一步步的不斷完善與成熟，微服務已經成爲衆多架構選擇中所必須面對的一個選項。服務註冊與發現是相輔相成的，所以一般會合起來思索。其依託組件有很多，比如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的同步。
總結
服務註冊與發現在服務生命週期中發揮着重要作用。動態的服務註冊和發現變得非常重要，它可以避免服務中斷。在處理服務實例的容災與故障轉移時，儘量實現自動轉移，並提供手動方式處理，而對於跨服務調用，尤其是該服務擁有多實例服務的時候，需要考慮負載平衡。