微服務專欄地址
目錄
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，分佈式鎖等等。