接下來我會大家學習非常重要的一個內容，那就是 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 後置過濾，用戶統計生成日志等！這裏就不再演示了！

然後還有限流，限流就是一種保護機制，比如可以防止網絡攻擊等！關於限流也不做 過多贅述沒，感興趣的可自行了解！

微信搜“慶哥Java”，關注後回複“SpringCloud”獲取PDF和markdown文件