SpringCloud知識點複習（第一次）

這個階段的技術的名詞優點多，我們一定要理清楚每一種的技術的名字以及對應的注解名字。如果記不住可以參考我說的以微服務要解決的四個問題為切入點進行記憶。還有就是這部分的學習和SpringBoot後半部分的學習一樣，多看文檔資料，多了解思想内涵

文章目錄

• • 1、微服務概述
  • 2、基于Rest學習的環境搭建
  • 3、Eureka
  • • 3.1、概念
    • 3.2、原理部分
    • 3.3、環境搭建
    • 3.4、添加服務發現Discovery機制
    • 3.5、配置計算機叢集
  • 4、Ribbon
  • • 4.1、負載均衡的概念
    • 4.2、Ribbon概念
    • 4.3、負載均衡環境搭建
    • 4.4、修改、自定義負載均衡算法
  • 5、Feign
  • 6、Hystrix
  • • 6.1、服務熔斷
    • 6.2、服務降級
    • 6.3、服務熔斷與服務降級的比較
    • 6.4、Dashboard流量監控
  • 7、Zuul
  • 8、SpringCloud Config分布式配置
  • • 8.1、基本概念
    • 8.2、配置服務端
    • 8.3、配置用戶端
  • 9、思維導圖

1、微服務概述

其實在SpringBoot階段，我們就已經開始了對微服務的講解，隻不過那時候我們講的是Dubbo+ZooKeeper+SpringBoot這一套方案。而這個階段我們主要學習的是SpringCloud Netflix這一套方案。

對于微服務開發，我們學習的SpringBoot已經夠用了，而SpringCloud部分也隻是對微服務開發的一種生化，畢竟架構不同，相應的管理方式，處理方式也就不一樣了。在Spring階段我們說過一句話，SpringBoot建構一切，SpringCloud協調一切，SpringCloud Date Flow連接配接一切。對于SpringCloud前期的概念學習，還是那句話，一定要多去看文檔資料，這個階段的學習已經不能僅僅局限于技術的學習了。

SpringCloud抛棄了Dubbo的RPC通信，采用的是基于HTTP的REST方式

Dubbo	Spring
服務注冊中心	ZooKeeper	Spring Cloud Netfilx Eureka
服務調用方式	RPC	REST API
服務監控	Dubbo-monitor	Spring Boot Admin
熔斷器	不完善	Spring Cloud Netfilx Hystrix
服務網關	無	Spring Cloud Netfilx Zuul
分布式配置	無	Spring Cloud Config
服務跟蹤	無	Spring Cloud Sleuth
消息總線	無	Spring Cloud Bus
資料流	無	Spring Cloud Stream
批量任務	無	Spring Cloud Task

分布式架構會遇到的四個核心問題?

1. 服務衆多，用戶端該如何去通路?
2. 服務衆多，服務之間如何進行通信?
3. 服務衆多，如何治理呢?
4. 服務衆多，服務出了故障怎麼處理？

這四個問題一定要牢牢地了解并記住，這會貫穿我們整個SpringCloud階段的學習。記住這幾個問題後，對于我們後期出現的技術才不會亂。

2、基于Rest學習的環境搭建

大緻步驟與SpringBoot階段的學習相同，搭建步驟為：

搭建父項目：

1. 配置對應的maven依賴

搭建實體類項目springcloud-api：

1. 建立一個maven項目，并引入對應的依賴
2. 建立資料庫，并使用IDEA進行連接配接
3. 編寫對應的實體類

搭建提供者項目springcloud-provider-dept-8001：

1. 建立一個maven項目，并引入對應的依賴
2. 編寫對應的核心配置檔案資訊
3. 配置mybatis的配置檔案
4. 編寫測試mybatis那一套代碼（接口類、接口類的mapper檔案、service層代碼、controller層代碼）
5. 編寫該項目的SpringBoot啟動類
6. 測試代碼

搭建消費者項目springcloud-consumer-dept-80：

1. 建立一個maven項目，并引入對應的依賴
2. 修改核心配置檔案，特别是修改端口，用來表示這是不同的程式
3. 編寫RestTemplate模闆的配置類
4. 根據提供者對應的路徑，編寫我們的消費者控制器層代碼
5. 測試代碼

我們有消費者、有提供者，并且資料都來自不同的項目，我們依然能夠完成項目的基本搭建。最終的項目也就是在這個上面完成，隻不過項目更多更複雜，但是模闆就是這樣的。

3、Eureka

3.1、概念

前面的環境搭建可以對标Dubbo，Eureka我們可以對标ZooKeeper。

我們現在讨論的技術都是建立在微服務的基礎之上，微服務又有一個CAP理論，即我們的分布式系統是無法同時滿足C（一緻性）A（可用性）P（分區容忍性）。我們的ZooKeeper選擇了CP，而我們的Eureka選擇了AP。

3.2、原理部分

其實對比着ZooKeeper，我們就能夠很好的了解了。

Eureka包含兩個元件：Eureka Server和Eureka Client，各個節點啟動後，會在Eureka Server中注冊，這樣我們就能夠在界面中值觀的看到服務節點的資訊。Eureka Client是一個java的用戶端，應用啟動後，會向Eureka Server發送心跳，如果長時間沒有接受到心跳，那麼我們就會在服務系統資料庫中把這個服務節點進行移除。

Eureka的三大角色：

• Eureka Server：提供服務注冊與發現
• Server Provider：将自身服務注冊到Eureka中，進而使得消費方能夠找到
• Server Consumer：服務消費方從Eureka中擷取注冊服務清單，進而找到消費服務

這三大角色應該不難想到，一個放資源的，一個拿資源的，一個管理資源的。

3.3、環境搭建

搭建注冊中心項目springcloud-eureka-7001：

1. 建立一個maven項目，并引入對應的依賴
2. 配置對應的核心配置檔案（端口配置、eureka配置）
3. 編寫對應的啟動類
4. 通路對應的端口号，檢視背景

将8001項目服務注冊進Eureka的步驟：

1. 修改之前springcloud-provider-dept-8001項目，添加對應的eureka依賴
2. 在核心配置檔案中，添加對應的eureka配置
3. 在啟動類中添加Eureka支援的注解

   @EnableEurekaClient

4. 啟動項目，再次測試項目，觀察服務是否被注冊進注冊中心

3.4、添加服務發現Discovery機制

我們在真實的業務開發中，為了知曉開發者到底是誰，就會進行相應的配置，使得我們在開發的時能顯示對應的開發者資訊。

配置步驟：

1. 在控制器類中添加對應的映射，以及編寫對應的開發者資訊
2. 在啟動類中添加對應的Discovery注解

   @EnableDiscoveryClient

3. 通路控制器中新添的映射方法，就可能檢視對應的開發者資訊

3.5、配置計算機叢集

前面我們說了Eureka就是一個注冊中心，類似于ZooKeeper。當我們的系統通路壓力過大時，Eureka會進行對應的調整，以此讓我們的項目更加穩定的運作。

我們這裡的配置叢集，就相當于配置這個注冊中心，讓這個注冊中心在三台伺服器上共同合作，避免因為其中一個注冊中心當機，整個項目崩盤。（這裡就展現出了Eureka的A屬性，高可用，一部分節點發生故障，整個叢集整體還能夠相應用戶端）

配置叢集項目

springcloud-eureka-7002

與

springcloud-eureka-7003

的步驟：

1. 建立兩個maven項目，并引入對應的依賴
2. 在對應的核心配置檔案中進行相應的配置（我們應該将三個注冊中心服務聯合起來，我們我們在監控頁面應該添加三個項目的端口）
3. 同時開啟三個服務，就可以測試效果了

4、Ribbon

4.1、負載均衡的概念

就是将使用者的請求平坦的配置設定到多個服務上，進而達到系統的HA（高可用）

負載均衡簡單分類：

• 集中式LB：在服務的消費方和提供方之間使用獨立的LB設施，如Nginx（反向代理伺服器），由該設施負責把通路請求通過某種政策轉發至服務的提供方
• 程序LB：1）将LB邏輯內建到消費方，消費方從服務注冊中心獲得哪些位址是可用的，然後自己再從這些位址中選擇一個合适的伺服器。 2）Ribbon屬于程序LB，它隻是一個類庫，內建于消費方程序，消費方通過它來擷取到服務提供方的位址

4.2、Ribbon概念

Spring Cloud Ribbon是一個基于Netflix Ribbon實作的一套用戶端的負載均衡的工具。

前面我們說了，當我們的系統通路壓力過大時，Eureka會進行對應的調整，以此讓我們的項目更加穩定的運作。這裡的調整就可以是負載均衡，而用到的技術就是Ribbon。

4.3、負載均衡環境搭建

修改我們的springcloud-consumer-dept-80項目步驟：

1. 在依賴中添加Ribbon、Eureka的依賴
2. 添加一個負載均衡的配置類（使用SpringBoot預設的就行）
3. 通路測試（由于此時隻有一個背景伺服器，我們無法看到具體的效果，但還是建議測試環境是否OK）

為了我們能夠看到具體實作負載均衡的效果，我們需要使用三個不同的背景提供者服務，這樣我們就能夠準确的觀測到實作負載均衡算法以後的項目通路變化

操作步驟：

1. 将springcloud-provider-dept-8001項目複制兩份
2. 再建立兩個不同的資料庫（包含資料庫名字字段的，這樣我們就能更加值觀的觀測到變化）
3. 修改對應的配置檔案
4. 運作項目（三個注冊中心叢集、三個背景伺服器、一個消費者）

4.4、修改、自定義負載均衡算法

在我們的實際測試效果中，我們發現系統預設使用的是輪詢算法。

但實際上，它還有很多的其他的算法，甚至是自定義算法

是以現在我們需要修改springcloud-consumer-dept-80項目中的Ribbon配置類

• 修改預設算法：我們可以将之前使用的預設的模闆替換成随機查詢算法
• 自定義算法：我們也可以繼承

  AbstractLoadBalancerRule

  類，重寫裡面的choose方法

5、Feign

我們可以将Feign與Ribbon放在一起了解。

Feign 和 Ribbon 是 Spring Cloud的 Netflix 中提供的兩個實作軟負載均衡的元件，Ribbon 和 Feign 都是用于調用其他服務的，隻是方式不同。Feign則是在Ribbon的基礎上進行了一次改進，采用接口的方式，将需要調用的其他服務的方法定義成抽象方法即可，不需要自己建構 http 請求。Feign就是一個Ribbon的改良版。

可以對比使用Mybatis時，我們是使用注解還是xml檔案。

配置步驟：

1. 在springcloud-api項目中添加feign對應的依賴
2. 在該項目中建立一個service層，并編寫對應的接口類
3. 建立一個springcloud-consumer-dept-feign項目，用于測試feign（大體内容與springcloud-consumer-dept-80類似）
4. 修改我們的新的消費者項目的控制器層代碼（擷取到api項目中的接口類）
5. 在啟動類中添加對應的注解@EnableFeignClients(basePackages = {“xx”})
6. 通路測試即可

6、Hystrix

用于處理分布式系統的延遲和容錯的開源庫，在分布式系統中，許多依賴不可避免地會調用失敗，比如逾時，異常等，Hystrix能夠保證在一個依賴出問題地情況下，不會導緻整體服務失敗，避免級聯過賬，以提高分布式系統地彈性

作用：

• 服務熔斷
• 服務降級
• 服務限流
• 接近實時的監控

6.1、服務熔斷

在我們通路相應的資源時，如果突然出現資源無法擷取的現象，那麼一段時間以後，服務就會啟動相應的熔斷機制。使用者能夠看到到擷取資源失敗的現象

配置步驟：

1. 明确服務熔斷機制，是使用在提供者一方的
2. 在提供者項目中添加相應的hystrix依賴
3. 在控制器類中，為每一個方法編寫一個熔斷方法，即如果方法出錯，那就調用熔斷方法
4. 在啟動類中添加對應的注解支援@EnableCircuitBreaker
5. 測試即可

6.2、服務降級

與熔斷不同，在我們通路相應的資源時，如果資源突然無法擷取，我們就會跳轉到之前編寫的服務降級方法中。這個過程中使用者不會感受到程式的出錯。

修改方式類似于Ribbon和Feign，兩種不同的方式修改的地方不一樣。

同樣我們的服務熔斷是修改提供者項目的代碼，我們的服務降級則是修改api項目的代碼

配置步驟：

1. 在api項目中引入對應的依賴
2. 在service層編寫一個服務降級類，用來處理對應的SQL語句的降級方法（你可可以了解成mybatis中的SQL接口類，和接口類對應的mapper.xml檔案）
3. 在對應的接口類中添加對應的注解@FeignClient(value = “服務名字”,fallbackFactory = 服務降級類.class)
4. 在消費者項目的核心配置檔案中，開啟服務降級

6.3、服務熔斷與服務降級的比較

服務熔斷：

• 當我們通路的服務對應的伺服器因為逾時或異常時，相應的節點就會進行服務熔斷，并且傳回相應的熔斷資訊。當我們的背景檢測到異常恢複以後，再重新啟用對應節點的服務。
• 由于某些原因，導緻了我們的服務出現了過載現象，為了防止整個系統故障，進而采用了一種保護機制，即服務熔斷
• 一般是某個服務（下遊服務）故障引起

服務降級：

• 當我們需要通路的服務對應的伺服器出現壓力過大的時候，就會犧牲一部分的資源來保證我們核心功能的運作（比如春運的時候，會停止（不考慮減少）部分人流量少的線路，增加人流量大的線路）
• 由于某些原因，導緻我們的服務出現過載的現象，這個時候我們就停止一部分的服務，讓更多的資源去滿足我們需要的核心的那幾個服務
• 一般是從整體的負荷進行考慮

6.4、Dashboard流量監控

這個流量監控的界面是在消費者端進行配置

配置springcloud-consumer-hystrix-dashboard項目步驟：

1. 建立一個含有dashboard監控頁面的消費者maven項目
2. 帶入對應的依賴
3. 修改核心配置檔案（修改端口号，用于表示是不同的項目）
4. 在對應的啟動類中添加對應的流量監控注解@EnableHystrixDashboard
5. 通路對應的端口，進行測試（僅僅測試流量監控頁面是否配置成功）
6. 修改我們的提供者項目中含有熔斷的項目
7. 在項目中添加對應的hystrix依賴
8. 在該項目的啟動類中，添加對應監控資訊，即編寫一個servlet，然後以Bean的形式注入容器中
9. 啟動7001注冊中心項目、8001帶熔斷的提供者項目、9001帶監控的消費者項目三個項目進行測試

啟動成功後，通路對應的9001端口，我們就能夠觀測到我們服務的相應的資訊。dashboard界面更加的直覺，友善我們服務進行相應的後期操作。

7、Zuul

Zuul包含了對請求的路由和過濾兩個主要的功能，Zuul服務最終還是會注冊進Eureka

配置springcloud-zuul-9527項目步驟：

1. 建立一個maven項目，并且添加對應的依賴
2. 在對應的核心配置檔案中，添加相應的資訊（Eureka叢集資訊、端口号、開發者資訊）
3. 建立一個主啟動類，并且開啟對應的注解@EnableZuulProxy
4. 開啟需要的服務進行測試
5. 此時我們會發現注冊中心多了一個Zuul服務

我們會發現使用Zuul的路徑也可以進行通路，但是我們真實的業務開發中，一般都會使用Zuul過濾掉我們正常的開發業務時的通路路徑，繼而轉向Zuul過濾以後的新的通路路徑

具體的配置步驟：

1. 在zuul-9527項目的核心配置檔案中配置相應的過濾路徑
2. 用我們希望讓使用者使用的通路路徑替換掉我們背景開發時的路徑
3. 通路測試

8、SpringCloud Config分布式配置

8.1、基本概念

由于我們的項目采用的是分布式架構，是以項目就會十分的多，與此同時我們的配置檔案和配置資訊也就會越來越多。

那有沒有一種方法能夠集中對我們的項目運作環境進行一個集中的管理？

當然有，那就是我們的此處的知識。

由于Spring Cloud Config預設使用Git來存儲配置檔案（也有其他的方式，比如支援SVN和本地檔案），但更推薦使用Git，是以我們的項目也就需要上傳到GIt，這樣我們不僅可以集中進行環境的配置，還可以多人遠端協同開發。

8.2、配置服務端

我一般是使用碼雲。

配置步驟：

1. 碼雲上建立一個倉庫
2. 将倉庫克隆到本地（在項目中建立一個application.yaml核心配置檔案，包含多種環境）
3. 建立一個springcloud-config-server-3344項目，并導入相應的依賴
4. 編寫對應的核心配置檔案（綁定對應的服務、配置對應的gitee位址）
5. 在核心配置類中添加注解@EnableConfigServer
6. 通路3344端口，我們就能夠遠端檢視并切換項目的開發環境了

8.3、配置用戶端

配置步驟：

1. 在我們的本地倉庫中建立一個config-client.yml配置檔案（内含兩套不同得端口資訊和Eureka注冊中心資訊）
2. 将我們的檔案送出到遠端的碼雲倉庫
3. 建立一個springcloud-config-client-3355項目，并添加對應的依賴
4. 編寫我峨嵋你的核心配置檔案，此處使用的核心配置檔案是bootstrap.yml，配置用戶端的相關資訊，并且配置服務端的uri
5. 在該項目中新增加一個控制器類（controller層下建立）
6. 編寫3355項目對應的啟動器
7. 通路對應的端口

bootstrap.yml與application.yml都是能夠被識别的配置檔案，前者是屬于系統級别的配置，後者屬于使用者級别的配置

這個階段的核心大緻就是，使用在Git技術的加持下，我們能夠在遠端進行環境的切換以及集中配置，個人覺得這個隻多配置幾次就熟練了！！！

9、思維導圖