扒一扒Nacos、OpenFeign、Ribbon、loadbalancer組件協調工作的原理

大家好，我是三友~~ 前幾天有個大兄弟問了我一個問題，註冊中心要集成SpringCloud，想實現SpringCloud的負載均衡，需要實現哪些介面和規範。既然這個兄弟問到我了，而我又剛好知道，這不得好好寫一篇文章來回答這個問題，雖然在後面的聊天中我已經回答過了。接下來本文就以探究一下Nacos ...

大家好，我是三友~~

前幾天有個大兄弟問了我一個問題，註冊中心要集成SpringCloud，想實現SpringCloud的負載均衡，需要實現哪些介面和規範。

既然這個兄弟問到我了，而我又剛好知道，這不得好好寫一篇文章來回答這個問題，雖然在後面的聊天中我已經回答過了。

接下來本文就以探究一下Nacos、OpenFeign、Ribbon、loadbalancer等組件協調工作的原理的方式，來講一講應該需要是實現哪些介面了。

再多說一句，本文並沒有詳細地深入剖析各個組件的源碼，如果有感興趣的兄弟可以從微信公眾號三友的java日記後臺菜單欄中的文章分類中查看我之前寫的關於Nacos、OpenFeign、Ribbon源碼剖析的文章。

Nacos

先從Nacos講起。

Nacos是什麼，官網中有這麼一段話

這一段話說的直白點就是Nacos是一個註冊中心和配置中心！

在Nacos中有客戶端和服務端的這個概念

服務端需要單獨部署，用來保存服務實例數據的
客戶端就是用來跟服務端通信的SDK，支持不同語言

當需要向Nacos服務端註冊或者獲取服務實例數據的時候，只需要通過Nacos提供的客戶端SDK就可以了，就像下麵這樣：

引入依賴

<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-client</artifactId>
    <version>1.4.4</version>
</dependency>

示例代碼

Properties properties = new Properties();
properties.setProperty("serverAddr", "localhost");
properties.setProperty("namespace", "8848");

NamingService naming = NamingFactory.createNamingService(properties);

//服務註冊，註冊一個order服務，order服務的ip是192.168.2.100，埠8080
naming.registerInstance("order", "192.168.2.100", 8080);

//服務發現，獲取所有的order服務實例
List<Instance> instanceList = naming.selectInstances("order", true);

當服務註冊到Nacos服務端的時候，在服務端內部會有一個集合去存儲服務的信息

這個集合在註冊中心界中有個響亮的名字，服務註冊表。

如何進行服務自動註冊？

用過SpringCloud的小伙伴肯定知道，在項目啟動的時候服務能夠自動註冊到服務註冊中心，並不需要手動寫上面那段代碼，那麼服務自動註冊是如何實現的呢？

服務自動註冊三板斧

SpringCloud本身提供了一套服務自動註冊的機制，或者說是約束，其實就是三個介面，只要註冊中心實現這些介面，就能夠在服務啟動時自動註冊到註冊中心，而這三個介面我稱為服務自動註冊三板斧。

服務實例數據封裝--Registration

Registration是SpringCloud提供的一個介面，繼承了ServiceInstance介面

從ServiceInstance的介面定義可以看出，這是一個服務實例數據的封裝，比如這個服務的ip是多少，埠號是多少。

所以Registration就是當前服務實例數據封裝，封裝了當前服務的所在的機器ip和埠號等信息。

Nacos既然要整合SpringCloud，自然而然也實現了這個介面

這樣當前服務需要被註冊到註冊中心的信息就封裝好了。

服務註冊--ServiceRegistry

ServiceRegistry也是個介面，泛型就是上面提到的服務實例數據封裝的介面

這個介面的作用就是把上面封裝的當前服務的數據Registration註冊通過register方法註冊到註冊中心中。

Nacos也實現了這個介面。

並且核心的註冊方法的實現代碼跟前面的demo幾乎一樣

服務自動註冊--AutoServiceRegistration

AutoServiceRegistration是一個標記介面，所以本身沒有實際的意義，僅僅代表了自動註冊的意思。

AutoServiceRegistration有個抽象實現AbstractAutoServiceRegistration

AbstractAutoServiceRegistration實現了ApplicationListener，監聽了WebServerInitializedEvent事件。

WebServerInitializedEvent這個事件是SpringBoot在項目啟動時，當諸如tomcat這類Web服務啟動之後就會發佈，註意，只有在Web環境才會發佈這個事件。

ServletWebServerInitializedEvent繼承自WebServerInitializedEvent。

所以一旦當SpringBoot項目啟動，tomcat等web伺服器啟動成功之後，就會觸發AbstractAutoServiceRegistration監聽器的執行。

最終就會調用ServiceRegistry註冊Registration，實現服務自動註冊

Nacos自然而然也繼承了AbstractAutoServiceRegistration

對於Nacos而言，就將當前的服務註冊的ip和埠等信息，就註冊到了Nacos服務註冊中心。

所以整個註冊流程就可以用這麼一張圖概括

當然，不僅僅是Nacos是這麼實現的，常見的比如Eureka，Zookeeper等註冊中心在整合SpringCloud都是實現上面的三板斧。

Ribbon

講完了SpringCloud環境底下是如何自動註冊服務到註冊中心的，下麵來講一講Ribbon。

我們都知道，Ribbon是負載均衡組件，他的作用就是從眾多的服務實例中根據一定的演算法選擇一個服務實例。

但是有個疑問，服務實例的數據都在註冊中心，Ribbon是怎麼知道的呢？？？

答案其實很簡單，那就是需要註冊中心去主動適配Ribbon，只要註冊中心去適配了Ribbon，那麼Ribbon自然而然就知道服務實例的數據了。

Ribbon提供了一個獲取服務實例的介面，叫ServerList

介面中提供了兩個方法，這兩個方法在眾多的實現中實際是一樣的，並沒有區別。

當Ribbon通過ServerList獲取到服務實例數據之後，會基於這些數據來做負載均衡的。

Nacos自然而然也實現了ServerList介面，為Ribbon提供Nacos註冊中心中的服務數據。

這樣，Ribbon就能獲取到了Nacos服務註冊中心的數據。

同樣地，除了Nacos之外，Eureka、Zookeeper等註冊中心也都實現了這個介面。

到這，其實就明白了Ribbon是如何知道註冊中心的數據了，需要註冊中心來適配。

在這裡插個個人的看法，其實我覺得Ribbon在適配SpringCloud時對獲取服務實例這塊支持封裝的不太好。

因為SpringCloud本身就是一套約束、規範，只要遵守這套規範，那麼就可以實現各個組件的替換，這就是為什麼換個註冊中心只需要換個依賴，改個配置文件就行。

而Ribbon本身是一個具體的負載均衡組件，註冊中心要想整合SpringCloud，還得需要單獨去適配Ribbon，有點違背了SpringCloud約束的意義。

就類似mybatis一樣，mybatis依靠jdbc，但是mybatis根本不關心哪個資料庫實現的jdbc。

真正好的做法是Ribbon去適配SpringCloud時，用SpringCloud提供的api去獲取服務實例，這樣不同的註冊中心只需要適配這個api，無需單獨適配Ribbon了。

而SpringCloud實際上是提供了這麼一個獲取服務實例的api，DiscoveryClient

通過DiscoveryClient就能夠獲取到服務實例，當然也是需要不同註冊中心的適配。

隨著Ribbon等組件停止維護之後，SpringCloud官方自己也搞了一個負載均衡組件loadbalancer，用來平替Ribbon。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-loadbalancer</artifactId>
    <version>2.2.5.RELEASE</version>
</dependency>