【強烈推薦，建議收藏】一萬字手把手教你學習Spring Cloud，帶你快速入門

接下來我會你們學習很是重要的一個內容，那就是 SpringCloud，接下來的內容會以 最快的速度帶你們學習 SpringCloud，由於當你學完以後，你就真的能夠算是跨過了 Java 的入門學習，也就是你已經有了 Java 的底子，有了 Java 整個大的知識框架，接 下來就是不斷的去填補細節內容了，至於工做，你已經徹底能夠出去找實習了！

文末提供PDF和Markdown下載！

OK，接下來咱們正式開始 SpringCloud 的學習！

快速上手 SpringCloud

SpringCloud 是一套完整的微服務處理框架，基本在微服務領域無人能敵，首先你們 須要明白一個知識點：

SpringCloud依賴於SringBoot，也就是說二者的版本必須符合，某一個版本的SpringCloud必須使用特定的 SpringBoot 版本」

查看版本對應

那該如何查看版本之間的對應關係呢？這裏有個官方地址能夠看下：

https://start.spring.io/actuator/info

打開以後返回的是 json 內容：

咱們能夠安裝一個瀏覽器插件 https://www.baidufe.com/fehelper/index/index.html

安裝以後咱們在瀏覽器查看的 json 就會被自動美化：

打開「bom-ranges」：

就能夠找到 SpringCloud 對應的 SpringBoot 版本，接下來你們須要知道這個網站：

https://mvnrepository.com/

就是查找各類 maven 依賴的，打開搜索 spring-cloud-dependencies：

好比咱們使用了這個版本的：

點擊版本號：

這裏就會出現 maven 依賴，咱們能夠將其複製到咱們的 pom 文件中：

或者咱們能夠打開 SpringCloud 的官網：https://spring.io/projects/spring-cloud

點擊這個選項，而後往下能夠找到這個：

也能夠看到版本對應，而後下面也有相關 maven 依賴：

好比咱們上面選擇了 SpringCloud 的這個版本：

根據對應關係：

那個人 SpringBoot 選擇和這個版本就是沒問題的：

以上就是關於 SpringCloud 和 SpringBoot 的一個版本對應關係，這個須要先了解！

體驗 SpringCloud

搭建註冊中心

接下來咱們就快速搭建一個 SpringCloud 的項目，帶你們體現 SpringCloud，首先我 們新建 SpringBoot 項目（SpringCloud 依賴於 SpringBoot）

這裏的建立應該沒什麼問題，咱們 next 下一步：

這裏注意 SpringBoot 的版本，而後咱們先加入基本的 web 依賴，而後完成！

接着咱們加入 SpringCloud 的依賴：

這裏必定要注意位置！

那到這裏就完事了嗎？其實尚未，看下這裏的項目名稱：

我這裏爲何叫作 springcloud-server 呢？那是由於對於 SpringCloud 來講，咱們前 期就能夠簡單理解是一個服務的註冊與發現，也就是經過 SpringCloud 咱們能夠啓動 一些服務（提供者），而後把這些服務集中弄到一個地方（註冊中心），而後其中的 一些服務（消費者）能夠去這個註冊中心找到所須要的服務從而去調用它來實現一些 功能，畫個圖就是這樣的：

因此你知道我這裏爲何叫作 springcloud-server 了吧，另外要實現這個功能就須要 使用到 SpringCloud 的服務註冊與發現組件，你確定據說過，就是 eureka，對於 eureka 它提供 server 和 client，那咱們這個 springcloud-server 是要做爲服務的註冊 中心，因此須要引入 eureka 的 server 插件！

而後去 mvnrepository 搜索「eureka-server」

而後在咱們的 pom 文件中引入：

如此一來咱們的這個項目就具有了註冊中心的功能，接下來須要一些配置，首先在啓 動類上加上註解：

而後 women 就能夠啓動項目了：

啓動成功，默認端口 8080，咱們訪問看下：

看到這個頁面就表明成功了，通常來講，做爲註冊中心的同時也是能夠做爲客戶端 的，因此會使得註冊中心把本身也給當成客戶端註冊了，咱們能夠禁止這種行爲，還 有默認的註冊中心服務地址，咱們均可以經過配置文件進行修改：

而後咱們從新啓動下看下：


Ok，以上咱們完成了註冊中心，可是如今註冊中心仍是空的，因此接下來咱們建立一 個服務提供者，也就是一個真正的客戶端，而後將其註冊到註冊中心去！

建立 eureka 服務提供者

建立的方式和以前建立 springcloud-server 同樣，只不過名字我改爲了這個：

而後就是須要添加相應的客戶端依賴，server 端咱們添加的是這個：

這裏是服務提供者，是一個 client 端，須要添加這個：

OK，一樣的咱們須要去添加相應的註解：

注意與註冊中心的區別！

接下來咱們還須要一些配置：

接下來啓動項目：

正常啓動，端口 8088，而後咱們再去以前的註冊中心頁面看看（記得刷新下）：

建立 eureka 服務消費者

那麼到了這裏咱們搞定了一個註冊中心，並且還弄了一個服務註冊進去了，那接下來 還缺乏一個服務消費者，用來消費服務提供者，其實服務提供者和服務消費者都是 client 端，只不過抽象成一個提供者和一個消費者，接下來咱們就在建立一個服務消 費者：

而後下一步：

添加基本的 web 依賴便可，而後完成！ 而後須要加上 SpringCloud 的依賴以及 eureka 的 client 依賴：

對了，通常咱們加入新的依賴會出現這個按鈕，點擊一下：

會加載相關的依賴，等待完成便可！

接下來須要進行一些相關配置：

而後是在啓動類上添加註解：

若是此時咱們啓動項目，那這個服務消費者會被註冊到註冊中心，咱們看下：

互相調用

不過咱們既然是服務消費者，其實說白了，就是要調用以前服務提供者提供的一些信 息，首先咱們在服務提供者裏面寫上這麼一個 controller：

注意這是在服務提供者中的 controller，而後咱們在服務消費者中去調用這個，那該怎 麼調用嘞？

這就使用到 RestTemplate，也就是實現兩個服務之間互相調用，首先咱們須要 在啓 動類中添加這個：

當咱們寫上上面的代碼以後，咱們的服務消費者就具有了調用註冊中心相關服務的功 能了，具體是這麼操做的：

而後咱們啓動項目訪問試一下：

如此一來，就實現了服務消費者調取服務提供者中的方法，從而得到相應信息的結 果！這也就實現了二者服務之間的互相調用！

以上，咱們就快速體驗了一遍 SpringCloud，包括基本的服務註冊與發現，以及互相 調用等，其實還包含本地的負載均衡等，咱們接下來在單獨來看！

以上操做你們必定要實際本身動手操做一遍！

SpringCloud Ribbon 負載均衡

接下來來講說這個負載均衡，首先啊，須要先直白的理解下什麼是負載均衡，說白 來，負載均衡就是爲了分攤壓力的，好比你們常見的超市收銀員，若是人多的話，一 個收銀員確定是不行的，忙不過來啊，怎麼辦，因此通常會有好幾個收銀員，經過這

種增長收銀員的策略來解決結帳壓力其實就是負載均衡的體現！

而後你們去排隊結帳的時候會主動去排隊，然而你們會優先去那些人少的地方排隊， 這就是一種均衡策略，放到負載均衡上來講，就是經過某種算法，讓服務消費者優先 選擇調取壓力比較小的服務提供者，以避免全部的消費請求全面積壓到一個服務提供者 身上！

而後你們還會聽過一種輪詢算法，說白來，這個就是一替一下，好比兩個服務，第一 個請求你處理，那第二個就我來處理，依次循環往復，這就是輪詢，一替一個來！ 那 SpringCloud 種是如何使用 ribbon 來實現負載均衡的呢？其實咱們上面的 SpringCloud 體驗案例種就使用到來 Ribbon，只不過它沒有引入相應的依賴，只由於 它是默認集成也就是在內部直接引用來了！

咱們在這裏經過 restTemplate 去調取服務提供者的服務，因此關鍵就是這個 restTemplate，這裏咱們訪問的提供者的服務地址是：

String url = 「http://eureka-client/getOrder」;

這裏要注意，咱們使用到的是服務提供者註冊到註冊中心的名稱，也就是這個：

也就是說咱們的調取是經過註冊中心來完成的，那既然是負載均衡，那確定不止一個 服務提供者，好比咱們在增長一個服務提供者也叫作「eureka-client」只不過端口不 同樣，名稱是同樣的，而後咱們這裏要是再次這樣調用：

那這個時候就要考慮那個服務提供者來接受咱們的調用請求了，由於你們都叫作 「eureka-client」並且提供一樣的服務，只不過端口不一樣，那該選用哪一個呢？這個就 須要負載均衡來決定，也就是咱們的 Ribbon 了，而完成這個只須要這一行註解：

當咱們添加上這個註解以後，那咱們的客戶端就用了負載均衡，當咱們這樣發起調 用：

Ribbon 就會幫咱們選擇合適的服務提供者，而其採用的正式輪詢算法！

OK，那關於負載均衡 SpringCloud Ribbon 咱們就暫且瞭解到這裏！

聲明式服務調用 SpringCloud Feign

接下來咱們來介紹聲明式調用，也就是 SpringCloud Feign！

咱們經過一個例子來看！ 首先，咱們加入 feign 的依賴，對了由於咱們仍是調用，因此是在服務消費者裏面加 上這個依賴：

再說一遍，相關 maven 依賴均可以去找個網站找：https://mvnrepository.com/

而後咱們須要在啓動類上加上 feign 的註解以將其開啓：

接着咱們寫一個接口：

這什麼意思呢？還記得以前咱們使用 RestTemplate 調用的狀況嗎？我這裏作個對比 你們就清楚了：

看清楚這之間的對應關係了吧，而後在看使用的對比：

而後咱們啓動調用試下：

徹底沒問題，這就是聲明式調用 SpringCloud Feign 了！ 不知道有人會不會想到以前說的 Ribbon 負載均衡，其實 Feign 是已經整合了 Ribbon 和 Hystrix 的，那什麼又是 Hystrix 呢？

服務容錯保護 SpringCloud Hystrix

接下來咱們來看看這個 Hystrix 是什麼？

那啥是 Hystrix 呢？簡單來講，它就是一套保護機制，在咱們的微服務中，其實當業務 量起來的時候，仍是比較複雜的，尤爲服務之間的互相調用，咱們很難保證這些服務 之間調用一切正常，總會出現問題的，好比出現網絡問題什麼，致使服務出現問題， 從而影響系統穩定！

其實面對這些問題，SpringCloud 就提供了一套保護機制，那就是 Hystrix，它能夠帶 來一些相關的問題解決方案，像什麼服務熔斷，服務隔離，降級等等！

服務降級

服務降級是一個比較重要的概念，那什麼是服務降級呢？簡單的來講，就是在某些情 況下，咱們爲了保證核心業務不受影響，能夠繼續使用，可是在資源有限的前提下就 必須犧牲掉一些不重要，非核心的業務，讓它們暫時不可用以節省資源來維持核心業 務的運行！

這就是服務降級啦！

下面咱們經過一個案例來近距離看下什麼是服務降級！

咱們還繼續使用咱們以前建立的註冊中心，以及服務提供者和消費者，接下來咱們在 服務消費者的 pom 文件中添加如下依賴：

接着在啓動類上添加相應註解：

雖然顯示被棄用，可是使用依然有效！這個註解就是用來開啓斷路器功能！ 而後咱們開始對服務降級：

而後咱們啓動服務訪問看下：

咱們發現正常訪問，沒什麼問題，接下來咱們停掉服務提供者，也就是模擬服務提供 者不可用的時候：

咱們發現這裏激活裏咱們設置的降級函數，接着咱們使用以前 feign 的調取：

看到沒，使用服務降級會是的提示更加友好，這個其實是增長用戶體驗的東西！ 這就是服務降級了！並且當服務自身出現問題了，也是會觸發降級的，好比這裏：

咱們知道這裏會出現問題，那麼依然會觸發降級！

關於超時

咱們來看一個例子，首先在咱們的服務提供者中將服務休眠 2 秒：

而後啓動服務！而後讓服務消費者調用：

咱們看到，此時觸發了服務降級，緣由就是服務提供者的休眠致使服務請求超時！ 另外須要知道對於 Hystrix 來講，它默認的超時時間是 1 秒，因此你設置了 2 秒，天然 就超時了！

那怎麼作呢？咱們能夠設置超時時間，不讓它使用默認的 1 秒，也過短了，咱們能夠 這樣設置：

咱們將超時時間設置成 3 秒，而後咱們再次訪問：

爲何仍是這樣呢？不知道你們發現問題沒有，看這裏：

爲了顯示自身服務出問題也會觸發降級的這行代碼忘記刪除了，因此即便咱們設置了 超時時間爲 3 秒仍是會觸發降級，這也驗證了自身服務出問題也會觸發降級，咱們刪 了這行代碼再試試：

這下就行了！

能夠看到咱們服務請求用了 2.03 秒，因此不會降級！

服務熔斷

這個服務熔斷其實也是保護服務的一種，好比咱們在一些高併發的狀況下，達到某些 設定的界限的時候就直接拒絕服務被訪問，以此來保護咱們的服務，通常熔斷都是和 降級一塊兒使用的，接下來仍是經過一個示例來看比較直觀！

其實仍是加註解的問題，一塊兒來看下:

這裏刪除了以前的超時設置，添加了幾個熔斷相關的註解，另外咱們對請求也添加了 參數設置，而後還須要注意的是，當你的方法增長了參數後，你的降級函數也要增 加，以下：

接着咱們來分析上述代碼，因爲沒有設置超時，那麼咱們直接訪問的時候確定是失敗 的：

不過這樣就能夠成功：

這主要就是這些註解的做用：

這些註解都是一些界限設置，當達到某個界限就會致使服務可用與不可用！

具體的每一個註解是什麼意思，你們能夠網上搜索 Hystrix Command 屬性便可，這裏不 再贅述！

SpringCloud Config 配置中心

這是一個能夠幫助咱們統一管理配置文件的項目，想一下咱們以前的操做，若是咱們 修改了配置文件，是否是還要重啓項目配置纔會生效，可是有了 SpringCloud Config 以後咱們能夠統一的管理配置，並且當配置發生變化能夠實時讀取最新的變化。

對於 SpringCloud 來講，它通常分爲兩個部分，一是服務端，咱們稱之爲配置中心， 二是咱們的客戶端，實際上這個客戶端也就是咱們的微服務應用，也就是說 Config 其 實是一個單獨的微服務模塊，氛圍服務端和客戶端，而後爲了方便集中管理配置，這 些配置是統一放在 git 上的，這點須要特別注意！

而後關於 Config 有這樣的一個流程框架圖：

接下來咱們經過具體的例子來看一下這個配置中心究竟是什麼以及如何使用！

搭建配置中心

首先建立一個 SpringBoot 項目：

接着下一步：

選擇以上兩個依賴，接着完成！ 而後咱們看下加入的相關依賴：

以前也說了，這裏的配置文件是放在 git 上的，那遠程 git 倉庫咱們選擇使用碼雲來搭 建，首先進入碼雲：

新建倉庫：

接着按照以下操做：

接着往下：

咱們這裏存放以前服務消費者的配置信息，直接將以前的配置複製過來便可！而後點 擊底部的提交便可！

而後咱們回到以前建立的 springcloud-config-server 上，在啓動類上添加相應註解：

接着去修改配置文件：

接着咱們啓動項目，訪問以下地址：

記得是「consumer-a.yml」不是「consumer.yml」接着咱們能夠在倉庫中再新建一個 文件：

這時候咱們再看：

接着咱們訪問連接：

接着咱們在 master 的基礎上新建一個分之爲 release：

而後在 release 分支上再建立一個文件：

接着訪問：

注意訪問的連接地址！ 另外咱們看這個圖：

也就是遠程 git 上的配置文件會被讀取到本地的 git 中，那本地的在哪裏呢？咱們在啓 動配置中心的時候，能夠在控制檯找到信息：

根據這個能夠找到本地 git 的保存位置！ 固然，這個本地 git 位置是能夠改變的沒，經過以下配置：

而後咱們重啓項目：

發現修改的指定位置生成了 git 目錄！ 至此，咱們已經搭建好了一個配置中心！

配置客戶端及使用

接下來咱們來看看如何配置客戶端 client！這裏咱們就使用以前的服務消費者 eurekaclient-consumer 來搭建！

首先添加依賴：

而後是修改配置文件：

注意了，改動仍是比較大的，首先名稱從「application」改爲了「bootstrap」，這個 是啓動項的意思，按照上述進行修改便可！

接下來須要寫一個控制類：

而後咱們啓動項目：

這個時候會遇到上述錯誤，這個主要是咱們把「application」改爲了「bootstrap」的 緣故，這個時候咱們須要添加一個依賴來解決這個問題：

而後咱們繼續啓動項目，這個時候你還會遇到如下問題：

這裏就要引出咱們以前操做的一個錯誤的地方，首先去看你的配置中心的配置：

這裏的名字要和你的客戶端 client 的配置中心的這個同樣：

這是第一個對應，而後還有很重要的一點，你看這裏：

這是你客戶端 client 配置的名字，咱們知道這個名字就是註冊到註冊中心的服務名 稱，而咱們以前在碼雲上添加的配置文件也是這個客戶端的，因此這裏有個對應，這裏的名字也就是「eureka-client-consumer」要和你在碼雲上添加的文件名稱要對 應，也就是這樣：

固然，你後面能夠帶上相應的 dev 或者 test，可是前面的命名必須和配置中心的名稱 也就是註冊到註冊中心的服務名稱同樣！ 這點須要特別注意！ 而後咱們就能夠正常啓動項目，而後訪問：

能夠看到，咱們已經拿到配置文件中的 env 屬性值了，也就是經過這裏的配置：

咱們能夠很是方便的切換使用不一樣的配置文件！ 而後還有個知識點須要知道，就是關於分支配置文件的問題，咱們來看，首先看下我

們的主分支配置文件：

而後看一下 release 分支：

這個時候咱們去看下咱們的配置中心的配置：

咱們這個時候沒有加這個默認分支屬性，那它使用的就是 master 主分支，而後咱們去 訪問不一樣的配置文件：

能夠看到，咱們訪問的是 master 上的 test 配置文件，咱們接着再訪問：

發現問題沒，咱們的主分支上是沒有 dev 的，那此時訪問的就是這個：

也能夠稱這個爲默認配置，也就是說若是訪問分支沒有的配置就會自動去訪問默認配

置！

另外還有個重點就是，你在默認配置上配置的信息會默認同步到其餘配置上，而非默

認配置的其餘配置項則不會同步到默認配置上！

網關 SpringCloud Zuul

什麼是網管呢？老規矩，咱們經過一個案例來快速瞭解下！

搭建 Zuul

首先咱們須要再次建立一個項目，這個項目是主要做爲網關使用的：

而後下一步加入相關的依賴：

咱們在這一步選擇的時候發現這個 Zull 是沒法選擇的，這是爲啥？說的簡單點，Zuul 是屬於網關的一種，出現的比較早，剛開始 SpringCloud 是使用這個 Zuul 網關，不過 因爲它是一種阻塞的，性能上慢慢以爲不太行來，因而後來 SpringCloud 就本身搞了 一個屬於本身的網關就是這個 Gateway 了，ok，明白咋回事了吧，因此咱們使用 SpringBoot 2.5 這個版本的時候官方就讓你使用本身的 Gateway 了，不過咱們前期做 爲學習仍是先來看看這個 Zuul！

咱們能夠把 SpringBoot 的版本回退一下：

OK，咱們完成便可！ 而後咱們看加入的相關 maven 依賴：

接下來就是進行相關配置：

而後在啓動類上添加開啓網關功能的註解：

而後咱們啓動項目：

能夠看到咱們的網關成功註冊到註冊中心！

路由功能

接下來咱們看以前建立的服務消費者中的一個 controller 服務：

還記得這個聲明式調用嗎？不記得能夠再去看看，咱們調用看下：

以上是咱們直接經過服務消費者本身去調用的，下面咱們能夠經過網關的形式去調 用：

看到沒，看張圖就更清楚了：

應該很清楚了吧，另外若是訪問出錯的話，多是超時問題，加上如下配置試試：

自定義路由

這是啥？看一下就知道了，首先咱們在配置文件中加上以下配置：

而後咱們就能夠這樣訪問：

注意看連接，其就是替換掉咱們服務的註冊名稱，而後還有一個簡潔寫法：

看訪問：

Zuul 過濾

路由是網關的一個核心功能，除此以外，還有一個重要功能，那就是過濾！ 在這裏面會聽到兩個專有名詞，就是鑑權和限流，鑑權簡單來講就是必須知足某個條 件才能訪問，好比必須攜帶一個 token，仍是實際來看個例子吧！ 首先新建一個類用於過濾：

接下來咱們重啓而後從新訪問這個：

這個時候就沒法訪問了，咱們必須攜帶 token 才能夠：

以上這個過濾稱爲前置 pre 過濾，主要用於鑑權，參數校驗以及限流等，而後還有一 種叫作 post 後置過濾，用戶統計生成日誌等！這裏就再也不演示了！

而後還有限流，限流就是一種保護機制，好比能夠防止網絡***等！關於限流也不作 過多贅述沒，感興趣的可自行了解！