[TOC]
我們一起來回顧一下上次的分享：
- 通道是什麼，通道的種類
- 無緩衝，有緩衝，單向通道具體對應什麼
- 對於通道的具體實踐
- 分享了關於通道的異常情況整理
- 簡單分享了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 的編碼案例分享
技術是開放的，我們的心態，更應是開放的。擁抱變化，向陽而生，努力向前行。
我是小魔童哪吒，歡迎點贊關注收藏，下次見~
本作品採用《CC 協議》，轉載必須註明作者和本文連結