Spring Cloud七大組件：1、Eureka組件，描述了服務如何進行注冊，注冊到哪里；2、Ribbon組件；3、Feign組件，一個聲明web服務客戶端；4、Hystrix組件；5、Config組件；6、Zuul組件；7、Bus組件。

本教程操作環(huán)境：windows7系統(tǒng)、java8版、DELL G3電腦。

Spring Cloud全家桶組件

在介紹Spring Cloud 全家桶之前，首先要介紹一下Netflix ，Netflix 是一個很偉大的公司，在Spring Cloud項目中占著重要的作用，Netflix 公司提供了包括Eureka、Hystrix、Zuul、Archaius等在內的很多組件，在微服務架構中至關重要，Spring在Netflix 的基礎上，封裝了一系列的組件，命名為：Spring Cloud Eureka、Spring Cloud Hystrix、Spring Cloud Zuul等，下邊對各個組件進行分別得介紹：

（1）Spring Cloud Eureka

我們使用微服務，微服務的本質還是各種API接口的調用，那么我們怎么產生這些接口、產生了這些接口之后如何進行調用那？如何進行管理哪？

答案就是Spring Cloud Eureka，我們可以將自己定義的API 接口注冊到Spring Cloud Eureka上，Eureka負責服務的注冊于發(fā)現(xiàn)，如果學習過Zookeeper的話，就可以很好的理解，Eureka的角色和 Zookeeper的角色差不多，都是服務的注冊和發(fā)現(xiàn)，構成Eureka體系的包括：服務注冊中心、服務提供者、服務消費者。

上圖中描述了（圖片來源于網(wǎng)絡）：

1、兩臺Eureka服務注冊中心構成的服務注冊中心的主從復制集群；
2、然后服務提供者向注冊中心進行注冊、續(xù)約、下線服務等；
3、服務消費者向Eureka注冊中心拉去服務列表并維護在本地（這也是客戶端發(fā)現(xiàn)模式的機制體現(xiàn)！）；
4、然后服務消費者根據(jù)從Eureka服務注冊中心獲取的服務列表選取一個服務提供者進行消費服務。

（2）Spring Cloud Ribbon

在上Spring Cloud Eureka描述了服務如何進行注冊，注冊到哪里，服務消費者如何獲取服務生產者的服務信息，但是Eureka只是維護了服務生產者、注冊中心、服務消費者三者之間的關系，真正的服務消費者調用服務生產者提供的數(shù)據(jù)是通過Spring Cloud Ribbon來實現(xiàn)的。

在（1）中提到了服務消費者是將服務從注冊中心獲取服務生產者的服務列表并維護在本地的，這種客戶端發(fā)現(xiàn)模式的方式是服務消費者選擇合適的節(jié)點進行訪問服務生產者提供的數(shù)據(jù)，這種選擇合適節(jié)點的過程就是Spring Cloud Ribbon完成的。

Spring Cloud Ribbon客戶端負載均衡器由此而來。

（3）Spring Cloud Feign

上述（1）、（2）中我們已經(jīng)使用最簡單的方式實現(xiàn)了服務的注冊發(fā)現(xiàn)和服務的調用操作，如果具體的使用Ribbon調用服務的話，你就可以感受到使用Ribbon的方式還是有一些復雜，因此Spring Cloud Feign應運而生。

Spring Cloud Feign 是一個聲明web服務客戶端，這使得編寫Web服務客戶端更容易，使用Feign 創(chuàng)建一個接口并對它進行注解，它具有可插拔的注解支持包括Feign注解與JAX-RS注解，F(xiàn)eign還支持可插拔的編碼器與解碼器，Spring Cloud 增加了對 Spring MVC的注解，Spring Web 默認使用了HttpMessageConverters, Spring Cloud 集成 Ribbon 和 Eureka 提供的負載均衡的HTTP客戶端 Feign。

簡單的可以理解為：Spring Cloud Feign 的出現(xiàn)使得Eureka和Ribbon的使用更為簡單。

（4）Spring Cloud Hystrix

我們在（1）、（2）、（3）中知道了使用Eureka進行服務的注冊和發(fā)現(xiàn)，使用Ribbon實現(xiàn)服務的負載均衡調用，還知道了使用Feign可以簡化我們的編碼。但是，這些還不足以實現(xiàn)一個高可用的微服務架構。

例如：當有一個服務出現(xiàn)了故障，而服務的調用方不知道服務出現(xiàn)故障，若此時調用放的請求不斷的增加，最后就會等待出現(xiàn)故障的依賴方 相應形成任務的積壓，最終導致自身服務的癱瘓。

Spring Cloud Hystrix正是為了解決這種情況的，防止對某一故障服務持續(xù)進行訪問。Hystrix的含義是：斷路器，斷路器本身是一種開關裝置，用于我們家庭的電路保護，防止電流的過載，當線路中有電器發(fā)生短路的時候，斷路器能夠及時切換故障的電器，防止發(fā)生過載、發(fā)熱甚至起火等嚴重后果。

（5）Spring Cloud Config

對于微服務還不是很多的時候，各種服務的配置管理起來還相對簡單，但是當成百上千的微服務節(jié)點起來的時候，服務配置的管理變得會復雜起來。

分布式系統(tǒng)中，由于服務數(shù)量巨多，為了方便服務配置文件統(tǒng)一管理，實時更新，所以需要分布式配置中心組件。在Spring Cloud中，有分布式配置中心組件Spring Cloud Config ，它支持配置服務放在配置服務的內存中（即本地），也支持放在遠程Git倉庫中。在Cpring Cloud Config 組件中，分兩個角色，一是Config Server，二是Config Client。

Config Server用于配置屬性的存儲，存儲的位置可以為Git倉庫、SVN倉庫、本地文件等，Config Client用于服務屬性的讀取。

（6）Spring Cloud Zuul

我們使用Spring Cloud Netflix中的Eureka實現(xiàn)了服務注冊中心以及服務注冊與發(fā)現(xiàn)；而服務間通過Ribbon或Feign實現(xiàn)服務的消費以及均衡負載；通過Spring Cloud Config實現(xiàn)了應用多環(huán)境的外部化配置以及版本管理。為了使得服務集群更為健壯，使用Hystrix的融斷機制來避免在微服務架構中個別服務出現(xiàn)異常時引起的故障蔓延。

先來說說這樣架構需要做的一些事兒以及存在的不足：

1、首先，破壞了服務無狀態(tài)特點。為了保證對外服務的安全性，我們需要實現(xiàn)對服務訪問的權限控制，而開放服務的權限控制機制將會貫穿并污染整個開放服務的業(yè)務邏輯，這會帶來的最直接問題是，破壞了服務集群中REST API無狀態(tài)的特點。從具體開發(fā)和測試的角度來說，在工作中除了要考慮實際的業(yè)務邏輯之外，還需要額外可續(xù)對接口訪問的控制處理。

2、其次，無法直接復用既有接口。當我們需要對一個即有的集群內訪問接口，實現(xiàn)外部服務訪問時，我們不得不通過在原有接口上增加校驗邏輯，或增加一個代理調用來實現(xiàn)權限控制，無法直接復用原有的接口。
面對類似上面的問題，我們要如何解決呢？下面進入本文的正題：服務網(wǎng)關！

為了解決上面這些問題，我們需要將權限控制這樣的東西從我們的服務單元中抽離出去，而最適合這些邏輯的地方就是處于對外訪問最前端的地方，我們需要一個更強大一些的均衡負載器，它就是本文將來介紹的：服務網(wǎng)關。

服務網(wǎng)關是微服務架構中一個不可或缺的部分。通過服務網(wǎng)關統(tǒng)一向外系統(tǒng)提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了權限控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，為微服務架構提供了前門保護的作用，同時將權限控制這些較重的非業(yè)務邏輯內容遷移到服務路由層面，使得服務集群主體能夠具備更高的可復用性和可測試性。

（7）Spring Cloud Bus

在（5）Spring Cloud Config中，我們知道的配置文件可以通過Config Server存儲到Git等地方，通過Config Client進行讀取，但是我們的配置文件不可能是一直不變的，當我們的配置文件放生變化的時候如何進行更新哪？

一種最簡單的方式重新一下Config Client進行重新獲取，但Spring Cloud絕對不會讓你這樣做的，Spring Cloud Bus正是提供一種操作使得我們在不關閉服務的情況下更新我們的配置。

Spring Cloud Bus官方意義：消息總線。

當然動態(tài)更新服務配置只是消息總線的一個用處，還有很多其他用處。

總結

Spring Cloud 的組件還不止這些，通過上邊的口水話的介紹，應該可以大致有一定的了解，但是每一個組件的功能遠不止上述介紹的那些，每一個組件還有很多其他的功能點，這里的介紹希望能夠帶大家入個門，不要對微服務這個這么大的概念有所畏懼。

更多編程相關知識，請訪問：編程視頻??！

以上是Spring Cloud七大組件是什么的詳細內容。更多信息請關注PHP中文網(wǎng)其他相關文章！