作者：不止思考/王奎 （本文來自作者投稿）
微服務(wù)架構(gòu)是一個龐大復(fù)雜的工程，為什么說它龐大復(fù)雜呢？因為想要做好微服務(wù)，就必須先要建設(shè)好微服務(wù)所需的一系列基礎(chǔ)設(shè)施和組件。我在前面的文章《架構(gòu)設(shè)計之「 微服務(wù)入門 」》中已經(jīng)初步介紹過了這些組件，包括：服務(wù)注冊、服務(wù)網(wǎng)關(guān)、配置中心、服務(wù)框架、服務(wù)監(jiān)控、服務(wù)追蹤、服務(wù)治理等。
只有將這些基礎(chǔ)設(shè)施搭建完善了，微服務(wù)實踐的道路才能走的穩(wěn)、走的遠。后面的文章中會依次把每一個基礎(chǔ)組件都詳細分析一下。今天我們就先挑選「 服務(wù)注冊 」聊一聊。
我們先來舉一個生活中的例子：在以前互聯(lián)網(wǎng)還不夠發(fā)達的時候，“114號碼百事通”大家應(yīng)該很熟悉，有啥需求就會去打個電話查詢一下。比如想知道附近電影院電話是多少，就會先去打114問一下。那114為啥知道這么多信息呢，還不是因為各類服務(wù)者（商店、機構(gòu)等）都已經(jīng)在114上登記了嘛。所以這里的“114百事通”就相當于一個服務(wù)注冊中心了，這里的各類商店機構(gòu)就相當于可以提供不同服務(wù)的服務(wù)者了，而打電話的我們就是去尋找這些服務(wù)的消費者了。
我們再來回到微服務(wù)架構(gòu)中，一般集群都會部署很多個微服務(wù)節(jié)點。這些節(jié)點一般也具備這2種角色，稱為：“服務(wù)的提供者” 和 “服務(wù)的消費者”。
“服務(wù)消費者”需要調(diào)用“服務(wù)提供者”的API來獲得服務(wù)。當“服務(wù)提供者”的節(jié)點有增加或減少的時候，也得讓調(diào)用者（“服務(wù)消費者”）及時的知曉。而在大規(guī)模集群中，一般節(jié)點數(shù)目都很多，節(jié)點變化頻繁，通過手動去維護這些節(jié)點的狀態(tài)是不現(xiàn)實的，因此需要一個叫做“服務(wù)注冊中心”的組件來實現(xiàn)。
“服務(wù)提供者”將自己的服務(wù)地址等信息登記到“服務(wù)注冊中心”中，調(diào)用者（“服務(wù)消費者”）需要的時候，每次都先去“服務(wù)注冊中心”查詢即可。既解決了人工維護微服務(wù)節(jié)點狀態(tài)的問題，也能解決多節(jié)點間負載均衡的問題。
在分析其原理之前，我們先來看一下這里包含的一些角色，有三類：“服務(wù)提供者”、“服務(wù)消費者”、“服務(wù)注冊中心”。
其中“服務(wù)提供者”需要將自己的服務(wù)信息注冊到“服務(wù)注冊中心”里面。而“服務(wù)消費者”需要到“服務(wù)注冊中心”里面去查詢有哪些服務(wù)可以調(diào)用。因此，我們可以分為兩個視角去分析原理：
從“服務(wù)提供者”的視角， “服務(wù)提供者”向“服務(wù)注冊中心”進行注冊：
登記注冊具體的也有為兩種方式，一種是 自己注冊，另一種是 第三方注冊。
自己注冊：
如圖，自己注冊就是指微服務(wù)節(jié)點在啟動的時候，自己去服務(wù)注冊中心登記注冊了，把自己的信息和狀態(tài)傳過去。這種方式整體結(jié)構(gòu)比較簡單，對于注冊中心而言也比較省事，但是對于微服務(wù)節(jié)點而言，每個微服務(wù)都得包含這么一段注冊的邏輯代碼，架構(gòu)上看起來不是很優(yōu)美。
再拿114百事通的例子解釋一遍，自己注冊就表示這是商家開店之后自己跑去告訴114電話臺，說自己商店開業(yè)了，目前在經(jīng)營著哪些服務(wù)，請求114登記下來。
第三方注冊：
如圖，第三方注冊就是指有一個“服務(wù)管理器”（圖中的Service Manager），這個“服務(wù)管理器”會去管理所有的微服務(wù)和進程，以輪詢或其它方式去檢查有哪些微服務(wù)實例正在運行，會將這些微服務(wù)實例自動更新到服務(wù)注冊中心。這是目前比較常用的方式，例如Eureka就是采用這個模式。
如果再拿114百事通的例子來講，就相當于114中心安排了一個管理員，這個管理員會定期的到街上去看一看有哪些新開的商店就把它登記下來，有哪些關(guān)閉了的商店就從注冊中心刪除掉。
從“服務(wù)消費者”的視角，“服務(wù)消費者”向“服務(wù)注冊中心”查詢和調(diào)用服務(wù)：
對于服務(wù)的查詢和調(diào)用，也分為兩種模式：客戶端模式 和 代理模式。
客戶端模式
在客戶端模式下，“服務(wù)消費者”（圖中的Client）在向“服務(wù)注冊中心”查詢到自己需要調(diào)用的“服務(wù)提供者”的地址之后，“服務(wù)消費者”（客戶端）就會自己根據(jù)地址去訪問微服務(wù)（圖中的第3步 API Gateway是可選項，有API Gateway的情況下，API Gateway起到負載均衡作用，沒有第3步的話，那就是Client直接調(diào)用Microservice，需要Client自己寫負載均衡邏輯）。
客戶端模式在實現(xiàn)上比較簡單。
代理模式
在代理模式下，“服務(wù)消費者”（圖中的Client）與 微服務(wù)、“服務(wù)注冊中心”中間有一個 API Gateway組件相隔著?！胺?wù)消費者”只管去找API Gateway訪問即可。至于去注冊中心查詢服務(wù)地址，以及訪問服務(wù)地址的動作都由API Gateway效勞了，最后API Gateway在把結(jié)果返回給“服務(wù)消費者”即可。
這種模式，看起來“服務(wù)消費者”省事了，但是API Gateway模塊卻復(fù)雜了，因為API Gateway就是整個系統(tǒng)的一個非常核心關(guān)鍵節(jié)點了，不僅需要保障自己的穩(wěn)定性和性能，而且還需要處理一些負載均衡的邏輯。在大型架構(gòu)中，這種模式用的還比較多。
講完了服務(wù)注冊中心的必要性和原理，我們再來看一下在實際應(yīng)用中應(yīng)該如何去應(yīng)用。雖然我們可以根據(jù)原理自己去開發(fā)一套服務(wù)注冊中心，但是如果沒有特殊需求，還是不建議重復(fù)造輪子了，市面上有很多成熟的方案可以直接使用。
Eureka
Eureka是由Netflix開源，其架構(gòu)如下圖：
從圖中可以看到，我們的服務(wù)（圖中Application Clinet與Application Service）要使用Eureka就需要集成它的SDK（圖中Eureka Client）。圖中的Eureka部署在了三個異地機房，也就是說Eureka是支持多中心部署的。
服務(wù)提供者（Application Service）通過Eureka Client實現(xiàn)服務(wù)的注冊、更新和注銷等。服務(wù)消費者（Application Clinet）通過Eureka Client實現(xiàn)服務(wù)的查詢和調(diào)用。
Eureka支持了與Spring Cloud的集成，所以使用起來也非常方便，目前屬于比較流行的方案。
Consul
Consul是另外一個非常流行的開源組件，如下圖:
Consul是在服務(wù)外進行完成一系列動作的，也就是說并不需要服務(wù)節(jié)點去依賴它的SDK，沒有侵入性，所以跨語言的解決能力更強一些。它一般是在服務(wù)節(jié)點外通過一些探針的方法去檢查應(yīng)用是否存活，是否需要注冊或注銷。
Consul也支持Spring Cloud集成，所以使用起來也很方便，也屬于比較流行的方案。
Etcd、Zookeeper
這兩個也有一些公司基于它們來實現(xiàn)服務(wù)注冊，也集成了Spring Cloud，不過不算非常廣泛。
以上，就是對微服務(wù)架構(gòu)中「 服務(wù)注冊 」的一些思考。
【本文作者】
王奎：不止思考的技術(shù)人，一名駐扎在武漢互聯(lián)網(wǎng)的程序員老兵。
