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

作者：三友 2023-04-10 23:05:54

開發(fā) 前端

Nacos、OpenFeign、Ribbon源碼剖析的文章，可以從公眾號后臺菜單欄中的文章分類中查看。

大家好，我是三友~~

前幾天有個大兄弟問了我一個問題，注冊中心要集成SpringCloud，想實現(xiàn)SpringCloud的負載均衡，需要實現(xiàn)哪些接口和規(guī)范。

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

接下來本文就來探究一下Nacos、OpenFeign、Ribbon、loadbalancer等組件協(xié)調工作的原理，知道這些原理之后，就知道應該需要是實現(xiàn)哪些接口了。

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

Nacos

先從Nacos講起。

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

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

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

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

當需要向Nacos服務端注冊或者獲取服務實例數(shù)據(jù)的時候，只需要通過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);

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

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

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

如何進行服務自動注冊？

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

服務自動注冊三板斧

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

服務實例數(shù)據(jù)封裝--Registration

Registration是SpringCloud提供的一個接口，繼承了ServiceInstance接口

Registration

ServiceInstance

從ServiceInstance的接口定義可以看出，這是一個服務實例數(shù)據(jù)的封裝，比如這個服務的ip是多少，端口號是多少。

所以Registration就是當前服務實例數(shù)據(jù)封裝，封裝了當前服務的所在的機器ip和端口號等信息。

Nacos既然要整合SpringCloud，自然而然也實現(xiàn)了這個接口

NacosRegistration

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

服務注冊--ServiceRegistry

ServiceRegistry也是個接口，泛型就是上面提到的服務實例數(shù)據(jù)封裝的接口

ServiceRegistry

這個接口的作用就是把上面封裝的當前服務的數(shù)據(jù)Registration注冊通過register方法注冊到注冊中心中。

Nacos也實現(xiàn)了這個接口。

NacosServiceRegistry

并且核心的注冊方法的實現(xiàn)代碼跟前面的demo幾乎一樣

服務自動注冊--AutoServiceRegistration

AutoServiceRegistration

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

AutoServiceRegistration有個抽象實現(xiàn)AbstractAutoServiceRegistration

AbstractAutoServiceRegistration是個抽象類

AbstractAutoServiceRegistration實現(xiàn)了ApplicationListener，監(jiān)聽了WebServerInitializedEvent事件。

WebServerInitializedEvent這個事件是SpringBoot在項目啟動時，當諸如tomcat這類Web服務啟動之后就會發(fā)布，注意，只有在Web環(huán)境才會發(fā)布這個事件。

ServletWebServerInitializedEvent繼承自WebServerInitializedEvent。

所以一旦當SpringBoot項目啟動，tomcat等web服務器啟動成功之后，就會觸發(fā)AbstractAutoServiceRegistration監(jiān)聽器的執(zhí)行。

最終就會調用ServiceRegistry注冊Registration，實現(xiàn)服務自動注冊

Nacos自然而然也繼承了AbstractAutoServiceRegistration

NacosAutoServiceRegistration

對于Nacos而言，就將當前的服務注冊的ip和端口等信息，就注冊到了Nacos服務注冊中心。

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

當然，不僅僅是Nacos是這么實現(xiàn)的，常見的比如Eureka、Zookeeper等注冊中心在整合SpringCloud都是實現(xiàn)上面的三板斧。

Ribbon

講完了SpringCloud環(huán)境底下是如何自動注冊服務到注冊中心的，下面來講一講Ribbon。

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

但是有個疑問，服務實例的數(shù)據(jù)都在注冊中心，Ribbon是怎么知道的呢？？？

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

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

ServerList

接口中提供了兩個方法，這兩個方法在眾多的實現(xiàn)中實際是一樣的，并沒有區(qū)別。

當Ribbon通過ServerList獲取到服務實例數(shù)據(jù)之后，會基于這些數(shù)據(jù)來做負載均衡的。

Nacos自然而然也實現(xiàn)了ServerList接口，為Ribbon提供Nacos注冊中心中的服務數(shù)據(jù)。

NacosServerList

這樣，Ribbon就能獲取到了Nacos服務注冊中心的數(shù)據(jù)。

同樣地，除了Nacos之外，Eureka、Zookeeper等注冊中心也都實現(xiàn)了這個接口。

到這，其實就明白了Ribbon是如何知道注冊中心的數(shù)據(jù)了，需要注冊中心來適配。

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

因為SpringCloud本身就是一套約束、規(guī)范，只要遵守這套規(guī)范，那么就可以實現(xiàn)各個組件的替換，這就是為什么換個注冊中心只需要換個依賴，改個配置文件就行。

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

就類似mybatis一樣，mybatis依靠jdbc，但是mybatis根本不關心哪個數(shù)據(jù)庫實現(xiàn)的jdbc。

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

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

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>

這個組件底層在獲取服務實例的時候，就是使用的DiscoveryClient。

所以對于loadbalancer?這個負載均衡組價來說，注冊中心只需要實現(xiàn)DiscoveryClient之后就自然而然適配了loadbalancer。

OpenFeign

OpenFeign是一個rpc框架，當我們需要調用遠程服務的時候，只需要聲明個接口就可以遠程調用了，就像下面這樣

聽上去很神奇，其實本質上就是后面會為接口創(chuàng)建一個動態(tài)代理對象，解析類上，方法上的注解。

當調用方法的時候，會根據(jù)方法上面的參數(shù)拼接一個http請求地址，這個地址的格式是這樣的http://服務名/接口路徑。

比如，上面的例子，當調用saveOrder?方法的時候，按照這種規(guī)律拼出的地址就是這樣的 http://order/order，第一個order是服務名，第二個order是PostMapping注解上面的。

但是由于只知道需要調用服務的服務名，不知道服務的ip和端口，還是無法調用遠程服務，這咋辦呢？

這時就輪到Ribbon登場了，因為Ribbon這個大兄弟知道服務實例的數(shù)據(jù)。

于是乎，OpenFeign就對Ribbon說，兄弟，你不是可以從注冊中心獲取到order服務所有服務實例數(shù)據(jù)么，幫我從這些服務實例數(shù)據(jù)中找一個給我。

于是Ribbon就會從注冊中心獲取到的服務實例中根據(jù)負載均衡策略選擇一個服務實例返回給OpenFeign。

OpenFeign拿到了服務實例，此時就獲取到了服務所在的ip和端口，接下來就會重新構建請求路徑，將路徑中的服務名替換成ip和端口，代碼如下：

reconstructURIWithServer

Server就是服務實例信息的封裝
orignal就是原始的url，就是上面提到的，http://order/order

假設獲取到的orde服務所在的ip和端口分別是192.168.2.100和8080?，最終重構后的路徑就是http://192.168.2.100:8080/order，之后OpenFeign就可以發(fā)送http請求了。

至于前面提到的loadbalancer，其實也是一樣的，他也會根據(jù)負載均衡算法，從DiscoveryClient獲取到的服務實例中選擇一個服務實例給OpenFeign，后面也會根據(jù)服務實例重構url，再發(fā)送http請求。

loadbalancer組件重構url代碼

總結

到這，就把Nacos、OpenFeign、Ribbon、loadbalancer等組件協(xié)調工作的原理講完了，其實就是各個組件會預留一些擴展接口，這也是很多開源框架都會干的事，當?shù)谌娇蚣苋ミm配的，只要實現(xiàn)這些接口就可以了。

最后畫一張圖來總結一下上述組價的工作的原理。

最后再小小地說一句，Nacos、OpenFeign、Ribbon源碼剖析的文章，可以從公眾號后臺菜單欄中的文章分類中查看。

責任編輯：武曉燕來源：三友的java日記