微服務系統中的服務發現機制

本文來自Nginx官方博客，這是微服務架構序系列的第四篇文章。做者總共發佈了七篇關於微服務的系列文章，在第一文章中介紹了傳統的單體式應用的不足，以及微服務架構的優點與挑戰。在第二和第三騙文章中描述了微服務內部通訊方面的內容。在這篇文章中，主要探討微服務系統的服務發現的相關問題。

爲何要使用服務發現？

咱們能夠想象一下，當咱們須要遠程的訪問REST API或者Thrift API時，咱們必須得知道服務的網絡地址（IP Address和port）。傳統的應用程序都是運行在固定的物理機器上，IP Address和端口號都是相對固定的。能夠經過配置文件方式來實現不按期更新的Ip Address和端口號。可是，在基於雲的微服務應用中，這是一個很是難以解決的問題。以下圖所示：

在基於雲的微服務應用中，服務實例的網絡地址（IP Address和Port）是動態分配的，而且因爲系統的auto-scaling, failures 和 upgrades等因數，一些服務運行的實例數量也是動態變化的。所以，客戶端代碼須要使用一個很是精細和準確的服務發現機制。

有兩種主要的服務發現方式：客戶端發現（client-side discovery）和服務器端發現（server-side discovery）。

客戶端發現方式

在使用客戶端發現方式時，客戶端經過查詢服務註冊中心，獲取可用的服務的實際網絡地址（IP Adress 和 端口號）。而後經過負載均衡算法來選擇一個可用的服務實例，並將請求發送至該服務。下圖顯示了客戶端發現方式的結構圖：

在服務啓動的時候，向服務註冊中心註冊服務；在服務中止的時候，向服務註冊中心註銷服務。服務註冊的一個典型的實現方式就是經過heartbeat機制定時刷新。Netflix OSS 就是使用客戶端發現方式的一個很好的例子。 Netflix Eureka是一個服務註冊中心。它提供了一個管理和查詢可用服務的 REST API。 負載均衡功能是經過Netflix Ribbon（是一個IPC客戶端）和Eureka一塊兒共同實現的。在文章的後面將深刻的介紹Eureka。

客戶端發現方式的優缺點。因爲客戶端知道全部可用的服務的實際網絡地址，因此能夠很是方便的實現負載均衡功能（好比：一致性哈希）。可是這種方式有一個很是明顯的缺點就是具備很是強的耦合性。針對不一樣的語言，每一個服務的客戶端都得實現一套服務發現的功能。

服務端發現方式

另一種服務發現的方式就是Server-Side Discovery Pattern，下圖展現了這種方式的架構示例圖:

客戶端向load balancer 發送請求。load balancer 查詢服務註冊中心找到可用的服務，而後轉發請求到該服務上。和客戶端發現同樣，服務都要到註冊中心進行服務註冊和註銷。AWS的彈性負載均衡（Elastic Load Balancer–ELB）就是服務端發現的一個例子。ELB一般是用於爲外網服務提供負載平衡的。固然你也可使用ELB爲內部虛擬私有云（VPC）提供負載均衡服務。客戶端經過使用DNS名稱，發送HTTP或TCP請求到ELB。ELB爲EC2或ECS集羣提供負載均衡服務。AWS並無提供單獨的服務註冊中心。而是經過ELB實現EC2實例和ECS容器的註冊的。

NGINX不只能夠做爲HTTP反向代理服務器和負載均衡器，也能夠用來做爲一個服務發現的負載均衡器。例如，這篇博客（Scalable Architecture DR CoN: Docker, Registrator, Consul, Consul Template and Nginx）介紹如何使用Consul Template 動態的配置NGINX功能。

Kubernetes 和 Marathon 是在經過集羣中每一個節點都運行一個代理來實現服務發現的功能的，代理的角色就是server-side discovery,客戶端經過使用主機的IP Address和Port向Proxy發送請求，Proxy再將請求轉發到集羣中任何一個可用的服務上。

服務器端發現方式的優勢是，服務的發現邏輯對客戶端是透明的。客戶只需簡單的向load balancer發送請求就能夠了。這就避免了爲每種不一樣語言的客戶端實現一套發現的邏輯。此外，許多軟件都內置實現了這種功能。這種方式的一個最大的缺點是，你必須得關心該組件的高可用性。

服務註冊中心

服務註冊中心是服務發現的核心。它保存了各個可用服務實例的網絡地址（IP Address和Port）。服務註冊中心必需要有高可用性和實時更新功能。

上面提到的 Netflix Eureka 就是一個服務註冊中心。它提供了服務註冊和查詢服務信息的REST API。服務經過使用POST請求註冊本身的IP Address和Port。每30秒發送一個PUT請求刷新註冊信息。經過DELETE請求註銷服務。客戶端經過GET請求獲取可用的服務實例信息。

Netflix的高可用（Netflix achieves high availability ）是經過在Amazon EC2運行多個實例來實現的,每個Eureka服務都有一個彈性IP Address。當Eureka服務啓動時，有DNS服務器動態的分配。Eureka客戶端經過查詢 DNS來獲取Eureka的網絡地址（IP Address和Port）。通常狀況下，都是返回和客戶端在同一個可用區Eureka服務器地址。

其餘可以做爲服務註冊中心的有：

• etcd ----- 高可用，分佈式，強一致性的，key-value，Kubernetes和Cloud Foundry都是使用了- - etcd。

• consul -----一個用於discovering和 configuring的工具。它提供了容許客戶端註冊和發現服務的API。Consul能夠進行服務健康檢查，以肯定服務的可用性。

• zookeeper ------ 在分佈式應用中被普遍使用，高性能的協調服務。 Apache Zookeeper 最初爲Hadoop的一個子項目，但如今是一個頂級項目。

咱們已經瞭解了服務註冊中心的概念，接下來咱們看看服務是若是註冊到註冊中心的。有兩種不一樣的方式來處理服務的註冊和註銷。一種是服務本身主動註冊-本身註冊（self-registration）。另外一種是經過其餘組件來管理服務的註冊-第三方註冊（third-party registration）。

Self-Registration

使用Self-Registration的方式註冊，服務實例必須本身主動的到註冊中心註冊和註銷。好比可使用heartbeat機制了實現。下圖爲這種方式的示意圖：

Netflix OSS Eureka client就是使用這種方式進行服務註冊的。Eureka的客戶端處理了服務註冊和註銷的全部工做。

Self-Registration方式的優缺點：一個明顯的優勢就是，很是簡單，不須要任何其它輔助組件。而缺點也是比較明顯的，使得各個服務和註冊中心的耦合度比較高。服務的不一樣語言的客戶端都得實現註冊和註銷的邏輯。另外一種服務註冊方式，能夠達到解耦的功能，就是third-party registration方式。

Third-Party Registration

使用Third-Party方式進行服務註冊時，服務自己沒必要關心註冊和註銷功能。而是經過其餘組件（service registrarhandles）來實現服務註冊功能。能夠經過如事件訂閱等方式來監控服務的狀態，若是發現一個新的服務實例運行，就向註冊中心註冊該服務，若是監控到某一服務中止了，就向註冊中心註銷該服務。下圖顯示了這種方式的結構圖示意圖：

third-party Registration方式的優勢是使服務和註冊中心解耦，不用爲每種語言實現服務註冊的邏輯。這種方式的缺點就是必須得考慮該組件的高可用性。

總結

在微服務的應用系統中，服務實例的數量是動態變化。各服務實例動態分配網絡地址（IP Address 和Port）。所以，爲了爲客戶端可以訪問到服務，就必需要有一種服務的發現機制。

服務發現的核心是服務註冊中心。服務註冊中心保存了各個服務可用的實例的相關信息。服務註冊中心提供了管理API和查詢API。使用管理API進行服務註冊、註銷。系統的其餘組件能夠經過查詢API來得到當前可用的服務實例信息。

有兩種主要的服務發現方式：客戶端發現（client-side service discovery）和服務端發現（ server-side discovery）。在使用客戶端服務發現的方式中，客戶經過查詢服務註冊中心，選擇一個可用的服務實例。在使用服務器端發現系統中，客戶訪問Router/load balancer，經過Router/load balancer查詢服務註冊中心，並將請求轉發到一個可用服務實例上。

服務註冊和註銷的方式也有兩種。一種是服務本身主動的將本身註冊到服務註冊中心，稱爲self-registration。另外一種是經過其餘組件來處理服務的註冊和註銷，稱爲third-party registration。

在有些環境中，服務發現功能須要本身經過服務註冊中心（好比：Netflix Eureka, etcd, Apache Zookeeper）實現，而有些環境中，服務發現功能是內置的。例如，Kubernetes和Marathon。

Nginx能夠做爲HTTP反向代理和負載平衡器，也能夠用來做爲一個服務發現的負載均衡器。經過向nginx推送routing information來修改nginx的配置，好比使用：Consul Template動態修改NGINX的配置. NGINX Plus 也支持動態修改配置功能。

在從此的文章中，咱們將繼續深刻分析微服務的其餘方面的內容。

原文做者發佈的關於微服務系列文章的地址：（點擊譯文連接查看）

• Introduction to Microservices

• Building Microservices: Using an API Gateway

• Building Microservices: Inter-Process Communication in a Microservices Architecture

• Service Discovery in a Microservices Architecture

• Event-Driven Data Management for Microservices

• Choosing a Microservices Deployment Strategy

• Refactoring a Monolith into Microservices

【做者信息】
原文做者：Chris Richardson，他是早期基於Java的Amazonite EC2 PaaS 平臺 CloudFoundry 的創始人，如今他爲企業提供如何開發和部署應用的諮詢服務。
原文連接：https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
翻譯自MaxLeap團隊_雲服務研發成員：Lam Yu

【注】原文解釋連接過多，放置於譯文處，如需查考，請點擊譯文查看：譯文連接