大家好，我是不才陳某~
前幾天有個大兄弟問了我一個問題，註冊中心要整合SpringCloud，想實現SpringCloud的負載均衡，需要實現哪些介面和規範。
Java指南：www.java-family.cn
既然這個兄弟問到我了，而我又剛好知道，這不得好好寫一篇文章來回答這個問題，雖然在後面的聊天中我已經回答過了。
接下來本文就來探究一下Nacos、OpenFeign、Ribbon、loadbalancer等元件協調工作的原理，知道這些原理之後，就知道應該需要是實現哪些介面了。
再多說一句，本文並沒有詳細地深入剖析各個元件的原始碼，如果有感興趣的兄弟可以從公眾號後臺選單欄中的文章分類中檢視我之前寫的關於Nacos、OpenFeign、Ribbon原始碼剖析的文章。
Nacos
Nacos是什麼，官網中有這麼一段話
這一段話說的直白點就是Nacos是一個註冊中心和配置中心！
在Nacos中有客戶端和服務端的這個概念
- 服務端需要單獨部署，用來儲存服務例項資料的
- 客戶端就是用來跟服務端通訊的SDK，支援不同語言
Java指南：www.java-family.cn
當需要向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>這個元件底層在獲取服務例項的時候，就是使用的DiscoveryClient。
所以對於loadbalancer這個負載均衡組價來說，註冊中心只需要實現DiscoveryClient之後就自然而然適配了loadbalancer。
OpenFeign
OpenFeign是一個rpc框架，當我們需要呼叫遠端服務的時候，只需要宣告個介面就可以遠端呼叫了，就像下面這樣
聽上去很神奇，其實本質上就是後面會為介面建立一個動態代理物件，解析類上，方法上的註解。
當呼叫方法的時候，會根據方法上面的引數拼接一個http請求地址，這個地址的格式是這樣的http://服務名/介面路徑。
比如，上面的例子，當呼叫saveOrder方法的時候，按照這種規律拼出的地址就是這樣的 http://order/order，第一個order是服務名，第二個order是PostMapping註解上面的。
但是由於只知道需要呼叫服務的服務名，不知道服務的ip和埠，還是無法呼叫遠端服務，這咋辦呢？
這時就輪到Ribbon登場了，因為Ribbon這個大兄弟知道服務例項的資料。
於是乎，OpenFeign就對Ribbon說，兄弟，你不是可以從註冊中心獲取到order服務所有服務例項資料麼，幫我從這些服務例項資料中找一個給我。
於是Ribbon就會從註冊中心獲取到的服務例項中根據負載均衡策略選擇一個服務例項返回給OpenFeign。
OpenFeign拿到了服務例項，此時就獲取到了服務所在的ip和埠，接下來就會重新構建請求路徑，將路徑中的服務名替換成ip和埠，程式碼如下
- Server就是服務例項資訊的封裝
- orignal就是原始的url，就是上面提到的，
http://order/order
假設獲取到的orde服務所在的ip和埠分別是192.168.2.100和8080，最終重構後的路徑就是http://192.168.2.100:8080/order，之後OpenFeign就可以傳送http請求了。
至於前面提到的loadbalancer，其實也是一樣的，他也會根據負載均衡演算法，從DiscoveryClient獲取到的服務例項中選擇一個服務例項給OpenFeign，後面也會根據服務例項重構url，再傳送http請求。
總結
到這，就把Nacos、OpenFeign、Ribbon、loadbalancer等元件協調工作的原理講完了，其實就是各個元件會預留一些擴充套件介面，這也是很多開源框架都會幹的事，當第三方框架去適配的，只要實現這些介面就可以了。
最後畫一張圖來總結一下上述組價的工作的原理。
最後再小小地說一句，Nacos、OpenFeign、Ribbon原始碼剖析的文章，可以從公眾號後臺選單欄中的文章分類中檢視。
最後說一句（別白嫖，求關注）
陳某每一篇文章都是精心輸出，如果這篇文章對你有所幫助，或者有所啟發的話，幫忙點贊、在看、轉發、收藏，你的支援就是我堅持下去的最大動力！
另外陳某的知識星球開通了，公眾號回覆關鍵詞：知識星球 獲取限量20元優惠券加入只需109元，星球回饋的價值巨大，目前更新了Spring全家桶實戰系列、億級資料分庫分表實戰、DDD微服務實戰專欄、我要進大廠、Spring，Mybatis等框架原始碼、架構實戰22講、精盡RocketMQ等....每增加一個專欄價格將上漲20元
關注公眾號：【碼猿技術專欄】，公眾號內有超讚的粉絲福利，回覆：加群，可以加入技術討論群，和大家一起討論技術，吹牛逼！