本文 GitHub https://github.com/SmileLionCoder/JavaFullStack 已收錄，有程式員進階技術堆疊全系列規劃以及我的系列文章，

在微服務架構或分布式環境下，服務注冊與發現技術不可或缺?，這也是程式員進階之路必須要掌握的核心技術之一，本文通過圖解的方式帶領大家輕輕松松掌握，

一、引入服務注冊與發現組件的原因

先來看一個問題，假如現在我們要做一個商城專案，作為架構師的你應該怎樣設計系統的架構？你心里肯定在想：這還不容易直接照搬淘寶的架構不就行了，但在現實的創業環境中一個專案可能是九死一生，如果一開始投入巨大的人力和財力，一旦專案失敗損失就很大，

作為一位有經驗的架構師需要結合公司財力、人力投入預算等現狀選擇最適合眼下的架構才是王道，大型網站都是從小型網站發展而來，架構也是一樣，

任何一個大型網站的架構都不是從一開始就一層不變的，而是隨著用戶量和資料量的不斷增加不斷迭代演進的結果，

在架構不斷迭代演進的程序中我們會遇到很多問題，技術發展的本質就是不斷發現問題再解決問題，解決問題又發現問題，

單體架構

在系統建立之初可能不會有特別多的用戶，將所有的業務打成一個應用包放在tomcat容器中運行，與資料庫共用一臺服務器，這種架構一般稱之為單體架構，

在初期這種架構的效率非常高，根據用戶的反饋可以快速迭代上線，但是隨著用戶量增加，一臺服務的記憶體和CPU吃緊，很容易造成瓶頸，新的問題來了怎么解決呢？

應用與資料分離

隨著用戶請求量增加，一臺服務器的記憶體和CPU持續飆升，用戶請求回應時間變慢，這時候可以考慮將應用與資料庫拆開，各自使用一臺服務器，你看問題又解決了吧，

突然有一天掃地阿姨不小心碰了電線，其中一臺服務器掉電了，用戶所有的請求都報錯，隨之而來的是一系列投訴電話，

集群部署

單實體很容易造成單點問題，比如遇到服務器故障或者服務能力瓶頸，那怎么辦？聰明的你肯定想到了，用集群呀，

集群部署是指將應用部署在多個服務器或者虛機上，用戶通過服務均衡隨機訪問其中的一個實體，從而使多個實體的流量均衡，如果一個實體出現故障可以將其下線，其他實體不受影響仍然可以對外提供服務，

隨著用戶數量快速增加，老板決定增加投入擴大團隊規模，開發團隊壯大后效率并沒有得到顯著的提高，以前小團隊可以一周迭代上線一次，現在至少需要兩到三周時間，

業務邏輯越來越復雜，代碼間耦合很嚴重，修改一行代碼可能引入幾個線上問題，架構師意識到需要進行架構重構，

微服務架構

當單體架構演進到一定階段后開發測驗的復雜性都會成本增加，團隊規模的擴大也會使得各自作業耦合性更嚴重，牽一發而動全身就是這種場景，

單體架構遇到瓶頸了，微服務架構就橫空出世了，微服務就是將之前的單體服務按照業務維度進行拆分，拆分粒度可大可小，拆分時機可以分節奏進行，最佳實踐是先將一些獨立的功能從單體中剝離出來抽成一個或多個微服務，這樣可以保障業務的連續性和穩定性，

如上圖將一個商用應用拆分為六個獨立微服務，六個微服務可以使用Docker容器化進行多實體部署，

架構演化到這里遇到了一個難題，如果要查詢用戶所有的訂單，用戶服務可能會依賴訂單服務，用戶服務如何與訂單服務互動呢？訂單服務有多個實體該訪問哪一個？

通常有幾種解決辦法：

（1）服務地址硬編碼

服務的地址寫死在資料庫或者組態檔，通過訪問DNS域名進行尋址路由，

服務B的地址硬編碼在資料庫或者組態檔中，服務A首先需要拿到服務B的地址，然后通過DNS服務器決議獲取其中一實體的真實地址，最后可以向服務B發起請求，

如果遇到大促活動需要對服務實體擴容，大促完需要對服務實體進行下線，運維人員要做大量的手工操作，非常容易誤操作，

（2）服務動態注冊與發現

服務地址硬編碼還有一個非常致命的問題，如果一臺實體掛了，運維人員可能不能及時感知到，導致一部分用戶的請求會例外，

引入服務注冊與發現組件可以很好解決上面遇到的問題，避免過多的人工操作，

架構演進總結

在單體架構中一個應用程式就是一個服務包，包內的模塊通過函式方法相互呼叫，模型足夠簡單，根本沒有服務注冊和發現一說，

在微服務架構中會將一個應用程式拆分為多個微服務，微服務會部署在不同的服務器、不同的容器、甚至多資料中心，微服務間要相互呼叫，服務注冊和發現成為了一個不可或缺的組件，

二、服務注冊與發現基本原理

服務注冊與發現是分為注冊和發現兩個關鍵的步驟，

服務注冊：服務行程在注冊中心注冊自己的元資料資訊，通常包括主機和埠號，有時還有身份驗證資訊，協議，版本號，以及運行環境的資訊，

服務發現：客戶端服務行程向注冊中心發起查詢，來獲取服務的資訊，服務發現的一個重要作用就是提供給客戶端一個可用的服務串列，

服務注冊

服務注冊有兩種形式：客戶端注冊和代理注冊，

客戶端注冊

客戶端注冊是服務自己要負責注冊與注銷的作業，當服務啟動后注冊執行緒向注冊中心注冊，當服務下線時注銷自己，

這種方式的缺點是注冊注銷邏輯與服務的業務邏輯耦合在一起，如果服務使用不同語言開發，那需要適配多套服務注冊邏輯，

代理注冊

代理注冊由一個單獨的代理服務負責注冊與注銷，當服務提供者啟動后以某種方式通知代理服務，然后代理服務負責向注冊中心發起注冊作業，

這種方式的缺點是多參考了一個代理服務，并且代理服務要保持高可用狀態，

服務發現

服務發現也分為客戶端發現和代理發現，

客戶端發現

客戶端發現是指客戶端負責向注冊中心查詢可用服務地址，獲取到所有的可用實體地址串列后客戶端根據負載均衡演算法選擇一個實體發起請求呼叫，

這種方式非常直接，客戶端可以控制負載均衡演算法，但是缺點也很明顯，獲取實體地址、負載均衡等邏輯與服務的業務邏輯耦合在一起，如果服務發現或者負載平衡有變化，那么所有的服務都要修改重新上線，

代理發現

代理發現是指新增一個路由服務負責服務發現獲取可用的實體串列，服務消費者如果需要呼叫服務A的一個實體可以直接將請求發往路由服務，路由服務根據配置好的負載均衡演算法從可用的實體串列中選擇一個實體將請求轉發過去即可，如果發現實體不可用，路由服務還可以自行重試，服務消費者完全不用感知，

心跳機制

如果服務有多個實體，其中一個實體出現宕機，注冊中心是可以實時感知到，并且將該實體資訊從串列中移出，也稱為摘機，

如何實作摘機？業界比較常用的方式是通過心跳檢測的方式實作，心跳檢測有主動和被動兩種方式，

被動檢測是指服務主動向注冊中心發送心跳訊息，時間間隔可自定義，比如配置5秒發送一次，注冊中心如果在三個周期內比如說15秒內沒有收到實體的心跳訊息，就會將該實體從串列中移除，

上圖中服務A的實體2已經宕機不能主動給注冊中心發送心跳訊息，15秒之后注冊就會將實體2移除掉，

主動檢測是注冊中心主動發起，每隔幾秒中會給所有串列中的服務實體發送心跳檢測訊息，如果多個周期內未發送成功或未收到回復就會主動移除該實體，

三、業界常用的服務注冊與發現組件對比

了解服務注冊與發現的基本原理后，如果你要在專案中使用服務注冊與發現組件，當面對眾多的開源組件該如何進行技術選型？

在互聯網公司里，有研發實力的大公司一般會選擇自研或者基于開源組件進行二次開發，但是對于中小型公司來說直接選用一款開源軟體會是一個不錯的選擇，

常用的注冊與發現組件有eureka，zookeeper，consul，etcd等，由于eureka在2018年已經宣布放棄維護，這里就不再推薦使用了，

下面結合各個維度對比一下各組件，

從整體上看consul的功能更加完備和均衡，接下來以consul為例詳細介紹一下，

四、Consul——值得推薦的服務注冊與發現開源組件

簡單認識一下Consul

Consul是HashiCorp公司推出的開源工，使用Go語言開發，具有開箱即可部署方便的特點，Consul是分布式的、高可用的、 可橫向擴展的用于實作分布式系統的服務發現與配置，

Consul有哪些優勢？

• 服務注冊發現：Consul提供了通過DNS或者restful介面的方式來注冊服務和發現服務，服務可根據實際情況自行選擇，
• 健康檢查：Consul的Client可以提供任意數量的健康檢查，既可以與給定的服務相關聯，也可以與本地節點相關聯，
• 多資料中心：Consul支持多資料中心，這意味著用戶不需要擔心Consul自身的高可用性問題以及多資料中心帶來的擴展接入等問題，

Consul的架構圖

Consul 實作多資料中心依賴于gossip protocol協議，這樣做的目的：

• 不需要使用服務器的地址來配置客戶端；服務發現是自動完成的，
• 健康檢查故障的作業不是放在服務器上，而是分布式的，

Consul的使用場景

Consul的應用場景包括服務注冊發現、服務隔離、服務配置等，

服務注冊發現場景中consul作為注冊中心，服務地址被注冊到consul中以后，可以使用consul提供的dns、http介面查詢，consul支持health check，

服務隔離場景中consul支持以服務為單位設定訪問策略，能同時支持經典的平臺和新興的平臺，支持tls證書分發，service-to-service加密

服務配置場景中consul提供key-value資料存盤功能，并且能將變動迅速地通知出去，借助Consul可以實作配置共享，需要讀取配置的服務可以從Consul中讀取到準確的配置資訊，

-- END --

日常求贊：你好技術人，先贊后看養成習慣，你的贊是我前進道路上的動力，對我非常重要，

加油技術人！

簡介： 博主從華中科技大學碩士畢業，是一個對技術有追求，對生活有激情的程式員，幾年間浪跡于多個一線互聯網大廠，具有多年開發實戰經驗，

微信搜索公眾號【愛笑的架構師】，我有技術和故事，等你來，

文章持續更新，在 github/SmileLionCoder 中可以看到我歸檔的系列文章，有面試經驗和技術干貨，歡迎Star，