服務註冊與發現之ETCD

[TOC]

服務註冊與發現之ETCD

咱們一塊兒來回顧一下上次的分享：

• 通道是什麼，通道的種類
• 無緩衝，有緩衝，單向通道具體對應什麼
• 對於通道的具體實踐
• 分享了關於通道的異常狀況整理
• 簡單分享了sync包的使用

要是對上述 GO 的通道 和 sync 包有點興趣的話，歡迎查看文章 GO通道和 sync 包的分享

今天咱們來看看服務註冊與發現

什麼是服務註冊和發現？

服務註冊和發現的基本原理以下：

服務註冊

指服務實例啓動的時候將自身的信息註冊到服務註冊與發現中心，並在運行的時候經過心跳的方式向服務註冊發現中心彙報自身服務狀態

服務發現

指服務實例向服務註冊與發現中心獲取的其餘服務實例信息，用於進行後續的遠程調用。

服務註冊和發現的做用？

根據網絡資源和 GO 相關的書籍介紹，簡單梳理了以下 3 個點：

• 管理實例信息

管理當前註冊到服務註冊與發現中心的微服務實例元數據信息，這些信息包括服務實例的服務名，IP地址，端口號，服務狀態和服務描述等等信息

• 健康檢查

服務註冊與發現中心會與已經註冊 ok 的微服務實例維持心跳，按期檢查註冊表中的服務是否正常在線，而且會在過程當中剔除掉無效的服務實例信息

• 提供服務發現的做用

如一我的服務須要調用服務註冊與發現中心中的微服務實例，能夠經過服務註冊與發現中心獲取到其具體的服務實例信息

對於服務註冊和發現，不得不說的一個定理是 CAP 定理

CAP原理是個啥？

是描述分佈式系統下節點數據同步的基本定理

有以下 3 個特性：

• 一致性

指數據的一致性。

系統的數據信息，這裏包括備份的數據信息，在同一時刻下都是一致的。

在咱們如今的分佈式系統中，同一份數據可能存在多個實例當中，在這個特性的要求下，每個實例若修改了其中一份數據，都必須同步到他全部的備份當中

• 可用性

指服務的可用性

這裏是要求服務實例，在接收到客戶端的請求後，都可以給出相應的響應

這裏是考量系統的可用性 ，例如在系統中某個節點宕機了，客戶端請求服務的時候，服務端仍然能夠作出對應的響應

• 分區容忍性

這個特性是這樣理解的

如今咱們分佈式的系統環境中，每個節點之間都是經過網絡通訊鏈接起來的，

但是，咱們要知道，基於網絡通訊，仍是會存在不可靠的地方，處在不一樣的網絡環境，該環境下的服務節點是會有可能出現鏈接不上，通訊失敗的。

對於以上這個問題，若系統能夠容忍，那麼這個系統就知足了 分區容忍性

服務註冊和發現都有哪些組件？

經常使用的服務註冊和發現框架有以下一些，我這裏列舉幾個：

• ETCD

基於HTTP 協議的分佈式 key/value 存儲組件

• Consul

基於 Raft 算法的開箱即用的服務發現組件

• Zookeeper

重量級一致性服務組件

• Eureka

基於集羣配置的組件

咱們今天來看看這些服務註冊和發現組件中的 ETCD ，也是由於他比較簡單，易於使用，而且是 GO 開發的

ETCD 是個啥？

ETCD 一個開源的、高可用的分佈式key-value存儲系統，能夠用於配置共享和服務的註冊和發現

那麼 ETCD 自身有啥特色？

整理梳理了一下，有以下幾個特色：

• 高可用性

ETCD 可用於避免硬件的單點故障或網絡問題

• 一致性

每次讀取 ETCD 上的數據，都會返回跨多主機的最新寫入的數據

• 簡單

能夠簡單的定義良好、面向用戶的API（此處說的API 指的是 gRPC 的接口）

• 安全

ETCD 裏面還實現了帶有可選的客戶端證書身份驗證 TLS

• 快速

資料上表示，每秒 10000次 寫入的基準速度

• 可靠性

使用 Raft算法 實現了強一致、高可用的服務存儲目錄

• 徹底複製

集羣中的每一個節點均可以使用完整的存檔數據

根據以上特性，有沒有發現這些特性都是圍繞 CAP定理 來的

來咱們對比一下爲何選擇 ETCD 而不是 Zookeeper？

仍是剛纔說到的 ETCD ，用起來很簡單，且還有以下特色：

• 支持HTTP/JSON API ， 使用簡單；使用 通用的 Raft 算法保證強一致性這讓用戶更加容易理解一些
• ETCD 默認數據一更新，就會進行持久化，這一點很香
• ETCD 還支持 SSL 客戶端安全認證，可以作到既簡單，又安全

來講一說爲啥不用Zookeeper呢？

• Zookeeper 部署和維護起來，相對複雜，而且 Zookeeper 使用的強一致性算法 是 Paxos 算法，相對晦澀難懂
• 官方提供的接口裏面沒有 Go 的，這就很尷尬了，只有JAVA 和 C 的

GO 如何 用 ETCD

咱們在使用 ETCD 的時候 ，咱們就直接把 ETCD 當作是一個配置中心便可 ，系統內的全部服務的配置都會在ETCD上進行管理

有小夥伴會有疑問，那麼 註冊的服務實際配置信息改變了怎麼辦呢？

ETCD 都給你想好了，咱們是這樣使用 ETCD 的

咱們服務啓動的時候，會主動從 ETCD 上獲取一次配置信息

而且在 ETCD 節點上註冊一個 Watcher 並等待

那麼之後自身服務配置信息改變的時候，ETCD 就會知道某個服務配置改變了，且會將該變更的狀況通知到這個服務的訂閱者

這樣子就達到了其餘服務獲取最新配置的目的了

ETCD 的分佈式鎖

上面有說到 服務註冊與發現，會遵循 CAP 定理

ETCD 的強一致性，得益於 Raft 算法，在 ETCD 裏面，對ETCD 的操做，存儲到集羣中，必定是全局惟一的，根據 ETCD 的這一個特性， 咱們就能夠用來實現 分佈式鎖了

ETCD 的鎖服務有 2 種方式：

• 保持獨佔鎖

同一個時刻，全局只有一個服務能夠拿到鎖

• 控制好客戶端請求的時序

得到鎖的順序也是全局惟一的，若小A得到了鎖，那麼在 ETCD 裏面，會有相應的key value 來標識 這一個客戶端

總結

• 分享了服務註冊和發現是什麼
• CAP 定理是什麼
• ETCD 是什麼，以及ETCD 和 Zookeeper的對比
• ETCD 的分佈式鎖實現的簡單原理

關於 GO 編碼中 ETCD 的應用案例，下一次咱們能夠關注一下

歡迎點贊，關注，收藏

朋友們，你的支持和鼓勵，是我堅持分享，提升質量的動力

好了，本次就到這裏，下一次 GO 中 ETCD 的編碼案例分享

技術是開放的，咱們的心態，更應是開放的。擁抱變化，向陽而生，努力向前行。

我是小魔童哪吒，歡迎點贊關注收藏，下次見~