概述
- 前言
- 什麼是服務註冊、服務發現
- 兩種服務註冊方式
- 兩種服務發現方式
- 常見的第三方註冊工具
- 後記
前言
好一陣子沒有更新了，有些小夥伴在後臺問我有沒有更新，看來大家還是挺喜歡看我的文章的嘛。主要是這段是間忙著複習演算法的一些東西，也不想隨便寫一篇繁衍。**如果我的文章對你有幫助，歡迎關注、點贊、轉發，這樣我會更有動力做原創分享。**OK，進入正題！
什麼是服務註冊、服務發現
我們來回顧一下上一盤文章的微服務架構圖，假如這個產品已經線上上執行，有一天運營想搞一場促銷活動，那麼我們相對應的【產品服務】可能就要新開啟三個微服務例項來支撐這場促銷活動。而與此同時，作為苦逼程式設計師的你就只有手動去 API gateway 中新增新增的這三個微服務例項的 ip 與port ，一個真正線上的微服務系統可能有成百上千微服務，難道也要一個一個去手動新增嗎？有沒有讓系統自動去實現這些操作的方法呢？答案當然是有的。且看，
如圖所示，當我們新新增一個微服務例項的時候，微服務就會將自己的 ip 與 port 傳送到註冊中心，在註冊中心裡面記錄起來。當 API gateway 需要訪問某些微服務的時候，就會去註冊中心取到相應的 ip 與 port。從而實現自動化操作。
以下是一個比較完整的服務註冊與服務發現的流程：
服務註冊的兩種方式
服務註冊方式有以下兩種：
-
客戶端註冊
客戶端註冊即為：將服務註冊與服務登出的邏輯寫進程式碼裡面，當一個微服務啟動的時候，將資訊寫入註冊中心，當一個微服務下線的時候，登出相應的資訊。且，需要不同的程式語言實現相同的一套邏輯。對業務程式碼有一定的入侵。期間，註冊中心與各個微服務之間還需要保持心跳。 -
第三方註冊
第三方註冊由一個獨立的服務 Registrar 負責註冊與登出。當服務啟動後以某種方式通知Registrar，然後Registrar負責向註冊中心發起註冊工作。同時註冊中心要維護與服務之間的心跳，當服務不可用時，向註冊中心登出服務。
服務發現的兩種方式
- 客戶端發現
客戶端負責向註冊中心獲取相應的 ip 與 port ，多種語言需要實現同一套邏輯，有點冗餘的感覺。 - 服務端發現
由 API gateway 實現服務發現的功能，這樣一套語言便可輕鬆維護服務發現的功能。
常見的第三方註冊工具
registrator
registrator 通過檢查容器線上或者停止執行狀態自動註冊和去註冊服務，它目前支援 etcd、consul、zookeeper 和 SkyDNS 2。連結傳送。它通常會和下面的工具配合使用，實現自動化服務註冊功能。
zookeeper
zookeeper 起源於 Hadoop ，它非常成熟、穩定，有比較多的大公司在使用一個高效能、分散式應用程式協調服務，用於名稱服務、分散式鎖定、共享資源同步和分散式配置管理。
etcd
etcd 是一個採用 HTTP 協議的健/值對儲存系統，它是一個分散式和功能層次配置系統，可用於構建服務發現系統。其很容易部署、安裝和使用，提供了可靠的資料持久化特性。它是安全的並且文件也十分齊全。它需要搭配一些第三方工具才可以提供服務發現功能。
consul
Consul 是強一致性的資料儲存，使用 gossip 形成動態叢集。它提供分級鍵/值儲存方式，不僅可以儲存資料，而且可以用於註冊器件事各種任務，從傳送資料改變通知到執行健康檢查和自定義命令，具體如何取決於它們的輸出。consul web 介面，使用者可以檢視所有的服務和節點、監控健康檢查狀態以及通過切換資料中心讀取設定鍵/值對資料。
後記
下一篇文章將是實戰篇，主要是手把手編寫一個小型的微服務架構，將之前學到的東西實踐一下，不實踐其實是很難掌握到的，盡請期待。
個人的知識儲備總是有限的，如有錯誤的地方，還請大佬斧正。點選閱讀原文，連結到我的知乎，我會在知乎上對文章錯誤的地方進行修改。
本篇文章首發於公眾號「zone7」，關注公眾號獲取最新推文，後臺回覆【小白微服務】獲取原始碼。
參考文獻：
服務發現：Zookeeper vs etcd vs Consul
服務註冊與發現
