在微服務架構或分佈式環境下，服務註冊與發現技術不可或缺，這也是程序員進階之路必需要掌握的核心技術之一，本文經過圖解的方式帶領你們輕輕鬆鬆掌握。程序員
引入服務註冊與發現組件的緣由
先來看一個問題，假如如今咱們要作一個商城項目，做爲架構師的你應該怎樣設計系統的架構？你內心確定在想：這還不容易直接照搬淘寶的架構不就好了。但在現實的創業環境中一個項目多是九死一輩子，若是一開始投入巨大的人力和財力，一旦項目失敗損失就很大。web
做爲一位有經驗的架構師須要結合公司財力、人力投入預算等現狀選擇最適合眼下的架構纔是王道。大型網站都是從小型網站發展而來，架構也是同樣。面試
任何一個大型網站的架構都不是從一開始就一層不變的，而是隨着用戶量和數據量的不斷增長不斷迭代演進的結果。算法
在架構不斷迭代演進的過程當中咱們會遇到不少問題，技術發展的本質就是不斷髮現問題再解決問題，解決問題又發現問題。數據庫
單體架構
在系統創建之初可能不會有特別多的用戶，將全部的業務打成一個應用包放在tomcat容器中運行，與數據庫共用一臺服務器，這種架構通常稱之爲單體架構。tomcat
單體架構-應用和數據庫共同部署服務器
在初期這種架構的效率很是高，根據用戶的反饋能夠快速迭代上線。可是隨着用戶量增長，一臺服務的內存和CPU吃緊，很容易形成瓶頸，新的問題來了怎麼解決呢？微信
應用與數據分離
隨着用戶請求量增長，一臺服務器的內存和CPU持續飆升，用戶請求響應時間變慢。這時候能夠考慮將應用與數據庫拆開，各自使用一臺服務器，你看問題又解決了吧。restful
單體架構-應用和數據庫分離架構
忽然有一天掃地阿姨不當心碰了電線，其中一臺服務器掉電了，用戶全部的請求都報錯，隨之而來的是一系列投訴電話。
集羣部署
單實例很容易形成單點問題，好比遇到服務器故障或者服務能力瓶頸，那怎麼辦？聰明的你確定想到了，用集羣呀。
應用集羣部署
集羣部署是指將應用部署在多個服務器或者虛機上，用戶經過服務均衡隨機訪問其中的一個實例，從而使多個實例的流量均衡，若是一個實例出現故障能夠將其下線，其餘實例不受影響仍然能夠對外提供服務。
隨着用戶數量快速增長，老闆決定增長投入擴大團隊規模。開發團隊壯大後效率並無獲得顯著的提升，之前小團隊能夠一週迭代上線一次，如今至少須要兩到三週時間。
業務邏輯愈來愈複雜，代碼間耦合很嚴重，修改一行代碼可能引入幾個線上問題。架構師意識到須要進行架構重構。
微服務架構
當單體架構演進到必定階段後開發測試的複雜性都會成本增長，團隊規模的擴大也會使得各自工做耦合性更嚴重，牽一髮而動全身就是這種場景。
單體架構遇到瓶頸了，微服務架構就橫空出世了。微服務就是將以前的單體服務按照業務維度進行拆分，拆分粒度可大可小，拆分時機能夠分節奏進行。最佳實踐是先將一些獨立的功能從單體中剝離出來抽成一個或多個微服務，這樣能夠保障業務的連續性和穩定性。
微服務架構
如上圖將一個商用應用拆分爲六個獨立微服務。六個微服務可使用Docker容器化進行多實例部署。
架構演化到這裏遇到了一個難題，若是要查詢用戶全部的訂單，用戶服務可能會依賴訂單服務，用戶服務如何與訂單服務交互呢？訂單服務有多個實例該訪問哪個？
一般有幾種解決辦法：
（1）服務地址硬編碼
服務的地址寫死在數據庫或者配置文件，經過訪問DNS域名進行尋址路由。
服務元數據硬編碼
服務B的地址硬編碼在數據庫或者配置文件中，服務A首先須要拿到服務B的地址，而後經過DNS服務器解析獲取其中一實例的真實地址，最後能夠向服務B發起請求。
若是遇到大促活動須要對服務實例擴容，大促完須要對服務實例進行下線，運維人員要作大量的手工操做，很是容易誤操做。
（2）服務動態註冊與發現
服務地址硬編碼還有一個很是致命的問題，若是一臺實例掛了，運維人員可能不能及時感知到，致使一部分用戶的請求會異常。
引入服務註冊與發現組件能夠很好解決上面遇到的問題，避免過多的人工操做。
架構演進總結
在單體架構中一個應用程序就是一個服務包，包內的模塊經過函數方法相互調用，模型足夠簡單，根本沒有服務註冊和發現一說。
在微服務架構中會將一個應用程序拆分爲多個微服務，微服務會部署在不一樣的服務器、不一樣的容器、甚至多數據中心，微服務間要相互調用，服務註冊和發現成爲了一個不可或缺的組件。
服務註冊與發現基本原理
服務註冊與發現是分爲註冊和發現兩個關鍵的步驟。
服務註冊：服務進程在註冊中心註冊本身的元數據信息。一般包括主機和端口號，有時還有身份驗證信息，協議，版本號，以及運行環境的信息。
服務發現：客戶端服務進程向註冊中心發起查詢，來獲取服務的信息。服務發現的一個重要做用就是提供給客戶端一個可用的服務列表。
服務註冊
服務註冊有兩種形式：客戶端註冊和代理註冊。
客戶端註冊
客戶端註冊是服務本身要負責註冊與註銷的工做。當服務啓動後註冊線程向註冊中心註冊，當服務下線時註銷本身。
客戶端註冊
這種方式的缺點是註冊註銷邏輯與服務的業務邏輯耦合在一塊兒，若是服務使用不一樣語言開發，那須要適配多套服務註冊邏輯。
代理註冊
代理註冊由一個單獨的代理服務負責註冊與註銷。當服務提供者啓動後以某種方式通知代理服務，而後代理服務負責向註冊中心發起註冊工做。
代理註冊
這種方式的缺點是多引用了一個代理服務，而且代理服務要保持高可用狀態。
服務發現
服務發現也分爲客戶端發現和代理髮現。
客戶端發現
客戶端發現是指客戶端負責向註冊中心查詢可用服務地址，獲取到全部的可用實例地址列表後客戶端根據負載均衡算法選擇一個實例發起請求調用。
客戶端發現
這種方式很是直接，客戶端能夠控制負載均衡算法。可是缺點也很明顯，獲取實例地址、負載均衡等邏輯與服務的業務邏輯耦合在一塊兒，若是服務發現或者負載平衡有變化，那麼全部的服務都要修改從新上線。
代理髮現
代理髮現是指新增一個路由服務負責服務發現獲取可用的實例列表，服務消費者若是須要調用服務A的一個實例能夠直接將請求發往路由服務，路由服務根據配置好的負載均衡算法從可用的實例列表中選擇一個實例將請求轉發過去便可，若是發現實例不可用，路由服務還能夠自行重試，服務消費者徹底不用感知。
代理路由服務註冊
心跳機制
若是服務有多個實例，其中一個實例出現宕機，註冊中心是能夠實時感知到，而且將該實例信息從列表中移出，也稱爲摘機。
如何實現摘機？業界比較經常使用的方式是經過心跳檢測的方式實現，心跳檢測有主動和被動兩種方式。
被動檢測是指服務主動向註冊中心發送心跳消息，時間間隔可自定義，好比配置5秒發送一次，註冊中心若是在三個週期內好比說15秒內沒有收到實例的心跳消息，就會將該實例從列表中移除。
心跳機制-被動檢測
上圖中服務A的實例2已經宕機不能主動給註冊中心發送心跳消息，15秒以後註冊就會將實例2移除掉。
主動檢測是註冊中心主動發起，每隔幾秒中會給全部列表中的服務實例發送心跳檢測消息，若是多個週期內未發送成功或未收到回覆就會主動移除該實例。
心跳機制-主動檢測
業界經常使用的服務註冊與發現組件對比
瞭解服務註冊與發現的基本原理後，若是你要在項目中使用服務註冊與發現組件，當面對衆多的開源組件該如何進行技術選型？
在互聯網公司裏，有研發實力的大公司通常會選擇自研或者基於開源組件進行二次開發，可是對於中小型公司來講直接選用一款開源軟件會是一個不錯的選擇。
經常使用的註冊與發現組件有eureka，zookeeper，consul，etcd等，因爲eureka在2018年已經宣佈放棄維護，這裏就再也不推薦使用了。
業界開源組件
下面結合各個維度對比一下各組件。
| 組件 | 優勢 | 缺點 | 接口類型 | 一致性算法 |
|---|---|---|---|---|
| zookeeper | 1.功能強大，不只僅只是服務發現； 2.提供watcher機制能夠實時獲取服務提供者的狀態； 3.普遍使用，dubbo等微服務框架已支持； |
1.沒有健康檢查； 2.須要在服務中引入sdk，集成複雜度高； 3.不支持多數據中心； |
sdk | Paxos |
| consul | 1.開箱即用，方便集成； 2.帶健康檢查； 3.支持多數據中心； 4.提供web管理界面； |
不能實時獲取服務變換通知 | restful/dns | Raft |
| etcd | 1.開箱即用，方便集成； 2.可配置性強 |
1.沒有健康檢查； 2.需配合三方工具完成服務發現功能； 3.不支持多數據中心； |
restful | Raft |
從總體上看consul的功能更加完備和均衡。接下來以consul爲例詳細介紹一下。
Consul——值得推薦的服務註冊與發現開源組件
簡單認識一下Consul
Consul是HashiCorp公司推出的開源工，使用Go語言開發，具備開箱便可部署方便的特色。Consul是分佈式的、高可用的、 可橫向擴展的用於實現分佈式系統的服務發現與配置。
Consul有哪些優點？
-
服務註冊發現：Consul提供了經過DNS或者restful接口的方式來註冊服務和發現服務。服務可根據實際狀況自行選擇。
-
健康檢查：Consul的Client能夠提供任意數量的健康檢查，既能夠與給定的服務相關聯，也能夠與本地節點相關聯。
-
多數據中心：Consul支持多數據中心，這意味着用戶不須要擔憂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 -
絮叨：天氣愈來愈冷，你們能夠可添加個人我的微信號：smileCoder1024，拉你進技術交流羣，一塊兒抱團取暖吧~
熱門推薦（點擊可閱讀）：
做者簡介：
博主從華中科技大學碩士畢業，是一個對技術有追求，對生活有激情的程序員。幾年間浪跡於多個一線互聯網大廠，具備多年開發實戰經驗，若是你熱愛技術或者你也不知足現狀喜歡搞事情，那你不妨關注我，讓咱們一路同行，一塊兒分享技術乾貨、交流面試技巧，吐槽職場故事。我有技術和故事，你來嗎？
大家點個「在看」雷架會興奮一夜睡不着~
架構師必定要懂啊~
本文分享自微信公衆號 - 愛笑的架構師（DancingOnYourCode）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。