微服務架構是一個龐大複雜的工程，為什麼說它龐大複雜呢？因為想要做好微服務，就必須先要建設好微服務所需的一系列基礎設施和元件。我在前面的文章《架構設計之「 微服務入門 」》中已經初步介紹過了這些元件，包括：服務註冊、服務閘道器、配置中心、服務框架、服務監控、服務追蹤、服務治理等。

只有將這些基礎設施搭建完善了，微服務實踐的道路才能走的穩、走的遠。後面的文章中會依次把每一個基礎元件都詳細分析一下。今天我們就先挑選「 服務註冊 」聊一聊。

一、為什麼需要「 服務註冊 」？

我們先來舉一個生活中的例子：在以前網際網路還不夠發達的時候，“114號碼百事通”大家應該很熟悉，有啥需求就會去打個電話查詢一下。比如想知道附近電影院電話是多少，就會先去打114問一下。那114為啥知道這麼多資訊呢，還不是因為各類服務者（商店、機構等）都已經在114上登記了嘛。所以這裡的“114百事通”就相當於一個服務註冊中心了，這裡的各類商店機構就相當於可以提供不同服務的服務者了，而打電話的我們就是去尋找這些服務的消費者了。

我們再來回到微服務架構中，一般叢集都會部署很多個微服務節點。這些節點一般也具備這2種角色，稱為：“服務的提供者” 和 “服務的消費者”。

“服務消費者”需要呼叫“服務提供者”的API來獲得服務。當“服務提供者”的節點有增加或減少的時候，也得讓呼叫者（“服務消費者”）及時的知曉。而在大規模叢集中，一般節點數目都很多，節點變化頻繁，通過手動去維護這些節點的狀態是不現實的，因此需要一個叫做“服務註冊中心”的元件來實現。

“服務提供者”將自己的服務地址等資訊登記到“服務註冊中心”中，呼叫者（“服務消費者”）需要的時候，每次都先去“服務註冊中心”查詢即可。既解決了人工維護微服務節點狀態的問題，也能解決多節點間負載均衡的問題。

二、「 服務註冊 」的實現原理是什麼？

在分析其原理之前，我們先來看一下這裡包含的一些角色，有三類：“服務提供者”、“服務消費者”、“服務註冊中心”。

其中“服務提供者”需要將自己的服務資訊註冊到“服務註冊中心”裡面。而“服務消費者”需要到“服務註冊中心”裡面去查詢有哪些服務可以呼叫。因此，我們可以分為兩個視角去分析原理：

• 從“服務提供者”的視角， “服務提供者”向“服務註冊中心”進行註冊：
  登記註冊具體的也有為兩種方式，一種是自己註冊，另一種是第三方註冊。

1. 自己註冊：

如圖，自己註冊就是指微服務節點在啟動的時候，自己去服務註冊中心登記註冊了，把自己的資訊和狀態傳過去。這種方式整體結構比較簡單，對於註冊中心而言也比較省事，但是對於微服務節點而言，每個微服務都得包含這麼一段註冊的邏輯程式碼，架構上看起來不是很優美。
再拿114百事通的例子解釋一遍，自己註冊就表示這是商家開店之後自己跑去告訴114電話臺，說自己商店開業了，目前在經營著哪些服務，請求114登記下來。

1. 第三方註冊：

如圖，第三方註冊就是指有一個“服務管理器”（圖中的Service Manager），這個“服務管理器”會去管理所有的微服務和程序，以輪詢或其它方式去檢查有哪些微服務例項正在執行，會將這些微服務例項自動更新到服務註冊中心。這是目前比較常用的方式，例如Eureka就是採用這個模式。
如果再拿114百事通的例子來講，就相當於114中心安排了一個管理員，這個管理員會定期的到街上去看一看有哪些新開的商店就把它登記下來，有哪些關閉了的商店就從註冊中心刪除掉。

• 從“服務消費者”的視角，“服務消費者”向“服務註冊中心”查詢和呼叫服務：
  對於服務的查詢和呼叫，也分為兩種模式：客戶端模式和代理模式。

1. 客戶端模式

在客戶端模式下，“服務消費者”（圖中的Client）在向“服務註冊中心”查詢到自己需要呼叫的“服務提供者”的地址之後，“服務消費者”（客戶端）就會自己根據地址去訪問微服務（圖中的第3步 API Gateway是可選項，有API Gateway的情況下，API Gateway起到負載均衡作用，沒有第3步手機靚號買賣地圖的話，那就是Client直接呼叫Microservice，需要Client自己寫負載均衡邏輯）。
客戶端模式在實現上比較簡單。

1. 代理模式

在代理模式下，“服務消費者”（圖中的Client）與 微服務、“服務註冊中心”中間有一個 API Gateway元件相隔著。“服務消費者”只管去找API Gateway訪問即可。至於去註冊中心查詢服務地址，以及訪問服務地址的動作都由API Gateway效勞了，最後API Gateway在把結果返回給“服務消費者”即可。
這種模式，看起來“服務消費者”省事了，但是API Gateway模組卻複雜了，因為API Gateway就是整個系統的一個非常核心關鍵節點了，不僅需要保障自己的穩定性和效能，而且還需要處理一些負載均衡的邏輯。在大型架構中，這種模式用的還比較多。

三、「 服務註冊 」如何實踐？

講完了服務註冊中心的必要性和原理，我們再來看一下在實際應用中應該如何去應用。雖然我們可以根據原理自己去開發一套服務註冊中心，但是如果沒有特殊需求，還是不建議重複造輪子了，市面上有很多成熟的方案可以直接使用。

• Eureka
  Eureka是由Netflix開源，其架構如下圖：

從圖中可以看到，我們的服務（圖中Application Clinet與Application Service）要使用Eureka就需要整合它的SDK（圖中Eureka Client）。圖中的Eureka部署在了三個異地機房，也就是說Eureka是支援多中心部署的。
服務提供者（Application Service）通過Eureka Client實現服務的註冊、更新和登出等。服務消費者（Application Clinet）通過Eureka Client實現服務的查詢和呼叫。
Eureka支援了與Spring Cloud的整合，所以使用起來也非常方便，目前屬於比較流行的方案。

• Consul
  Consul是另外一個非常流行的開源元件，如下圖:

Consul是在服務外進行完成一系列動作的，也就是說並不需要服務節點去依賴它的SDK，沒有侵入性，所以跨語言的解決能力更強一些。它一般是在服務節點外通過一些探針的方法去檢查應用是否存活，是否需要註冊或登出。
Consul也支援Spring Cloud整合，所以使用起來也很方便，也屬於比較流行的方案。

• Etcd、Zookeeper
  這兩個也有一些公司基於它們來實現服務註冊，也集成了Spring Cloud，不過不算非常廣泛。

以上，就是對微服務架構中「 服務註冊 」的一些思考。