微服務化改造系列之二：服務註冊中心

前情概要：微服務化改造系列之一：總覽

服務註冊中心概述

這篇文章是微服務化改造系列的第二篇，主題是服務註冊中心。做爲微服務架構最基礎也是最重要的組件之一，服務註冊中心本質上是爲了解耦服務提供者和服務消費者。對於任何一個微服務，原則上都應存在或者支持多個提供者，這是由微服務的分佈式屬性決定的。更進一步，爲了支持彈性擴縮容特性，一個微服務的提供者的數量和分佈每每是動態變化的，也是沒法預先肯定的。所以，本來在單體應用階段經常使用的靜態LB機制就再也不適用了，須要引入額外的組件來管理微服務提供者的註冊與發現，而這個組件就是服務註冊中心。

設計或者選型一個服務註冊中心，首先要考慮的就是服務註冊與發現機制。縱觀當下各類主流的服務註冊中心解決方案，大體可歸爲三類：

• 應用內：直接集成到應用中，依賴於應用自身完成服務的註冊與發現，最典型的是Netflix提供的Eureka

• 應用外：把應用當成黑盒，經過應用外的某種機制將服務註冊到註冊中心，最小化對應用的侵入性，好比Airbnb的SmartStack，HashiCorp的Consul

• DNS：將服務註冊爲DNS的SRV記錄，嚴格來講，是一種特殊的應用外註冊方式，SkyDNS是其中的表明

注1：對於第一類註冊方式，除了Eureka這種一站式解決方案，還能夠基於ZooKeeper或者Etcd自行實現一套服務註冊機制，這在大公司比較常見，但對於小公司而言顯然性價比過低。

注2：因爲DNS固有的緩存缺陷，本文不對第三類註冊方式做深刻探討。

除了基本的服務註冊與發現機制，從開發和運維角度，至少還要考慮以下五個方面：

• 測活：服務註冊以後，如何對服務進行測活以保證服務的可用性？

• 負載均衡：當存在多個服務提供者時，如何均衡各個提供者的負載？

• 集成：在服務提供端或者調用端，如何集成註冊中心？

• 運行時依賴：引入註冊中心以後，對應用的運行時環境有何影響？

• 可用性：如何保證註冊中心自己的可用性，特別是消除單點故障？

如下就圍繞上述幾個方面，簡單分析一下Eureka，SmartStack，Consul的利弊。

Eureka

從設計角度來看，Eureka能夠說是無懈可擊，註冊中心、提供者、調用者邊界清晰，經過去中心化的集羣支持保證了註冊中心的總體可用性，但缺點是Eureka屬於應用內的註冊方式，對應用的侵入性太強，且只支持Java應用。

SmartStack

SmartStack能夠說是三種方案中最複雜的，涉及了ZooKeeper、HAProxy、Nerve和Synapse四種異構組件，對運維提出了很高的要求。它最大的好處是對應用零侵入，且適用於任意類型的應用。

Consul

Consul本質上屬於應用外的註冊方式，但能夠經過SDK簡化註冊流程。而服務發現剛好相反，默認依賴於SDK，但能夠經過Consul Template（下文會提到）去除SDK依賴。

方案

最終咱們選擇了Consul做爲服務註冊中心的實現方案，主要緣由有兩點：

1. 最小化對已有應用的侵入性，這也是貫穿咱們整個微服務化改造的原則之一

2. 下降運維的複雜度，Consul Agent既能夠運行在服務器模式，又能夠運行在客戶端模式

Consul Template

上文提到使用Consul，默認服務調用者須要依賴Consul SDK來發現服務，這就沒法保證對應用的零侵入性。所幸經過Consul Template，能夠定時從Consul集羣獲取最新的服務提供者列表並刷新LB配置（好比nginx的upstream），這樣對於服務調用者而言，只須要配置一個統一的服務調用地址便可。改造後的調用關係以下：

Spring Cloud Consul

因爲咱們選用了Spring Boot做爲統一的微服務實現框架，很天然的，能夠利用Spring Cloud提供的Consul組件進一步簡化服務註冊流程，省去額外的服務提供端的Consul配置。

參考

• CONSUL DOCUMENTATION

• consul-template

• Spring Cloud Consul

• Spring Cloud Netflix

• Dive into Eureka

• SmartStack: Service Discovery in the Cloud

• Open-Source Service Discovery