四：對微服務所需的服務發現的理解
阿新 • • 發佈：2019-02-13
微服務專欄地址
目錄
1. 簡介
從問題的角度去思考、理解服務發現，後續demo程式碼編寫或者探究原理時反過來驗證對服務發現的理解。問題主要包括：
- 什麼是服務發現？
- 為什麼需要服務發現？
- 服務發現具備哪些關鍵特性？
- 服務發現的經典機制有哪些？
- 有什麼解決方案？
- 實際生產中如何選擇？
2. 什麼是服務發現？
服務發現提供了一種協調機制，方便服務的釋出和查詢，是支撐大規模SOA的核心服務。在一定規模的應用系統中，服務的數量可能是幾十個，上百個，服務中有消費者，生產者，那麼消費者如何發現消費者？這個時候需要提供一種機制來解決這個問題。
3. 為什麼需要服務發現？
當實現一個或者一組服務時，服務呼叫方需要知道服務例項的訪問資訊，如IP、埠、地址等。如果都是人工去為每個服務例項配置訪問資訊，效率、可靠性、穩定性都是不能保證的，特別是在基於雲的微服務體系中，服務例項被動態地分配訪問資訊，並且這些資訊也可能會隨著資源的調整有變化。
所以需要一套完善的服務發現機制來幫助我們去實現服務的註冊、發現自動化，實現不使用硬編碼的方式，只需要服務名就可以使用服務。並且可以動態的實現服務的註冊、銷燬以及查詢。
4. 服務發現具備哪些關鍵特性？
- 高可用：服務發現是SOA或者微服務體系中的核心功能，服務發現不可用往往意味著應用不可用，這是無法接受的
- 提供服務註冊、銷燬：保證服務的有效性以及可用性
- 提供服務查詢：服務例項是為客戶端或者呼叫者提供服務的，必須能讓客戶端通過一定規則查詢到其需要訪問的服務
5. 服務發現的經典機制有哪些？
經典機制：傳統LB模式、程序內LB模式、獨立主機LB模式
5.1 傳統LB模式
5.1.1 工作機制是什麼樣的
- 服務上線，為其配置域名
- 運維將服務資訊配置到LB中
- 消費者訪問LB，LB呼叫服務並返回結果給消費者
5.1.2 有什麼優缺點
優點：
- 實現方式簡單
- 業界普遍在使用
缺點：
- 運維難度大：新增或者撤銷服務時，需要運維介入更改LB配置資訊
- 存在單點故障：一臺F5或者nginx作為核心，若掛了則整體都不能正常工作
- 需要硬體配合，成本高：若使用F5做LB，就是外購硬體
- 效能有損耗：客戶端呼叫服務端是需要穿透LB的
5.2 程序內LB模式
5.2.1 工作機制是什麼樣的
- 服務例項自動註冊到服務註冊中心
- 定期傳送心跳，反映服務可用
- 服務消費者客戶端帶有服務發現和負載功能
- LB定期同步服務登錄檔中服務
- 服務消費者通過LB呼叫服務例項
5.2.2 有什麼優缺點
優點：
- 高可用性：每個客戶端一個LB，不存在單點故障問題
- 服務發現無需運維介入：通過程式碼的形式實現服務的註冊、發現，不需要運維額外配置資訊
- 高效能：客戶端直接通過LB獲取服務例項訪問地址資訊，進而直接呼叫服務例項提供的服務介面，無中間過程損耗效能
缺點：
- 多語言支援成本高：客戶端程式碼與LB強耦合，需要為每種接入語言實現客戶端程式碼與LB程式碼
- 升級成本高：客戶端程式碼與LB強耦合，升級任何一個都必須要兩者同時考慮
5.3 獨立主機LB模式
5.3.1 工作機制是什麼樣的
- 前面兩種方式的折中
- 每個主機上部署一個LB
- 服務例項自動註冊到服務註冊中心
- 定期傳送心跳，反映服務可用
- LB定期同步服務登錄檔中服務資訊
- 消費端呼叫本機LB，LB實現負載均衡和遠端呼叫
5.3.2 有什麼優缺點
優點：
- 可支援多種語言
- 無單點故障
- 效能高
缺點：
- 運維成本高：每個客戶端都需要安裝獨立的LB，客戶端與LB狀態兩者都要兼顧，且客戶端與LB是一對一的
6. 有什麼解決方案？
現在以理解核心思想為主，暫時只列出核心技術名稱，後續會深入理解和對比，有興趣的可自行查詢資料。
6.1 各種方案
- Zookeeper：CP模式
- Consul：CP模式
- Eureka：程序內LB模式，AP模式
- Service Mesh：獨立主機LB模式
- Etcd
6.2 方案特性對比
| Feature | Consul | zookeeper | etcd | euerka |
|---|---|---|---|---|
| 服務健康檢查 | 服務狀態，記憶體，硬碟等 | (弱)長連線，keepalive | 連線心跳 | 可配支援 |
| 多資料中心 | 支援 | — | — | — |
| kv儲存服務 | 支援 | 支援 | 支援 | — |
| 一致性 | raft | paxos | ||
| cap | cp | cp | cp | ap |
| 使用介面(多語言能力) | 支援http和dns | 客戶端 | http/grpc | http（sidecar） |
| watch支援 | 全量/支援long polling | 支援 | ||
| 自身監控 | metrics | — | metrics | metrics |
| 安全 | acl | /https | acl | https支援（弱） |
| spring cloud整合 | 已支援 | 已支援 | 已支援 | 已支援 |
7. 實際生產中如何選擇？
暫時未在實際過程中需要抉擇，只能說說自己的思考
- 首先系統現狀很重要，個人覺得一切都應該以實際情況出發
- 選取的微服務開發框架與各種解決方案整合的難度如何
- 各個方案的特點，如優缺點，複雜度，上手難易程度都是考量因素，當然若某一方案的一個缺點無法忍受，則一票否決也不是不可能
- 技術的熱度、社群的活躍、資料的豐富層度也是一個維度，畢竟生產效率與學習成本也是必須要考慮的
- 是否有現有元件可直接來使用，如zookeeper，早已不僅僅是用來做服務發現，因其特性早已應用在多種技術、框架中，如hadoop，分散式鎖等等。