工作中使用了微服務架構,接下來的一段時間裏,我會寫一系列的文章來介紹微服務架構,同時我也會在github上寫一個microservices的應用框架(地址會在後續文章給出)。
這篇文章主要講述了微服務架構中的服務發現與服務註冊。
翻譯和整理自:
- http://microservices.io/patterns/client-side-discovery.html
- http://microservices.io/patterns/server-side-discovery.html
- http://microservices.io/patterns/service-registry.html
- http://microservices.io/patterns/self-registration.html
- http://microservices.io/patterns/3rd-party-registration.html
一、客戶端服務發現與服務端服務發現
1.上下文
因此, 你必須實現一種機制,使得service的客戶端可以發送請求到動態變化的service實例上。
2.問題
service的客戶端- API Gateway或者別的service怎麼去發現service實例的地址?
3.強制條件
- 每個service實例在具體的地址上(host,port)暴露出一個像HTTP/REST那樣的遠端API
- service的數目和地址動態改變
- 虛擬機和容器經常被賦予動態IP
4.解決方案
1)客戶端服務發現
客戶端發送請求到service時,通過查詢一個Service Registry(它知道所有service實例的地址)的方式來獲取service實例的地址,如下所示:
優點:
- 與服務端服務發現相比有更少的網絡跳數
缺點:
- 把客戶端與Service Registry綁定了
- 你需要爲你用的每個編程語言/框架實現客戶端服務發現的邏輯。
2)服務端服務發現
發送到可用的service實例。
示例
AWS Elastic Load Balancer (ELB)就是一個服務端發現router的例子。客戶端發送HTTP(s) 到ELB,ELB把流量負載均衡到一系列EC2機器上。除了作爲負載均衡器,ELB同時也是一個Service Registry。 EC2實例在ELB上註冊。
一些集羣解決方案比如Kubernetes 和 Marathon在每個主機上運行一個proxy,這個proxy的作用就是一個服務端發現router。爲了訪問一個service,客戶端連接到這個本地的proxy,通過那個service的port來訪問到service。 proxy把請求發送到運行在這個集羣上某個地方的service實例。
優點:
- 與客戶端服務發現相比, 客戶端的代碼更簡單。
- 一些雲環境提供這個功能,比如ELB
缺點:
- 除非是雲環境,否則router必須是一個系統的組件,需要安裝和配置。爲了可用性和性能,也需要做replicate
- 比客戶端服務發現有更多的網絡跳數
二、服務註冊處(Service Registry)
服務註冊處是一個保存了services, 實例,以及他們的地址的數據庫。service實例在啓動時被註冊,在停止時刪去註冊。service的客戶端或者router查詢服務註冊處來找到可用的service實例。服務註冊處可以通過調用服務實例的健康檢查API來驗證它是否可以處理請求。
你需要決定service實例如何被註冊到服務註冊處。有兩種選擇:
- Self registration pattern - service實例自己註冊他們
- 3rd party registration pattern - 第三方註冊service實例