SpringCloud簡介

SpringCloud是Spring旗下的專案之一，官網地址：http://projects.spring.io/spring-cloud/

Spring最擅長的就是整合，把世界上最好的框架拿過來，整合到自己的專案中。

SpringCloud也是一樣，它將現在非常流行的一些技術整合到一起，實現了諸如：配置管理，服務發現，智慧路由，負載均衡，熔斷器，控制匯流排，叢集狀態等等功能。其主要涉及的元件包括：

• Eureka：服務治理元件，包含服務註冊中心，服務註冊與發現機制的實現。（服務治理，服務註冊/發現）
• Zuul：閘道器元件，提供智慧路由，訪問過濾功能
• Ribbon：客戶端負載均衡的服務呼叫元件（客戶端負載）
• Feign：服務呼叫，給予Ribbon和Hystrix的宣告式服務呼叫元件 （宣告式服務呼叫）
• Hystrix：容錯管理元件，實現斷路器模式，幫助服務依賴中出現的延遲和為故障提供強大的容錯能力。(熔斷、斷路器，容錯)

微服務

• itcast-service-provider：一個提供根據id查詢使用者的微服務。
• itcast-service-consumer：一個服務呼叫者，通過RestTemplate遠端呼叫itcast-service-provider。

專案中存在什麼問題？

• 在consumer中，我們把url地址硬編碼到了程式碼中，不方便後期維護
• consumer需要記憶provider的地址，如果出現變更，可能得不到通知，地址將失效
• consumer不清楚provider的狀態，服務當機也不知道
• provider只有1臺服務，不具備高可用性
• 即便provider形成叢集，consumer還需自己實現負載均衡

其實上面說的問題，概括一下就是分散式服務必然要面臨的問題：

• 服務管理
  • 如何自動註冊和發現
  • 如何實現狀態監管
  • 如何實現動態路由
• 服務如何實現負載均衡
• 服務如何解決容災問題
• 服務如何實現統一配置

以上的問題，我們都將在SpringCloud中得到答案。
1.引入元件的啟動器
2.覆蓋預設配置
3.在引導類上新增註解，開啟相關元件

下面對以上技術以及一個發展進行一個詳細說明：

微服務發展路程及相關技術的優缺點

瞭解微服務之前，先來了解一下垂直拆分和水平拆分的概念

垂直拆分：功能拆分【也就是微服務專案的拆分方式】

水平拆分：分層web ，service ，mapper【也就是傳統專案的拆分方式】

---

傳統專案（非微服務）

缺點：

1.單點故障問題

2.併發能力弱，併發數低

3.程式碼的耦合度高

優點：

維護簡單

---

分散式架構

優點：

1.方便水平擴充套件

2.方便單獨優化

3.解耦合

4.提高併發

缺點：

1.增加維護成本

2.程式碼冗餘，重複開發

3.呼叫關係錯綜複雜

4.維護困難

---

1.架構的演變

傳統架構–》水平拆分–》垂直拆分（最早的分散式架構）–》SOA（面向服務）–》微服務（SpringCloud）

2.遠端呼叫技術,rpc,http

rpc協議：自定義資料格式，限定技術，傳輸速度快、效率高 （傳輸層） 【dubbo】

http協議：統一的資料格式，不限定技術rest介面 tcp() 【SpringCloud】

3.什麼是springCloud

微服務架構的一種解決方案，是很多元件的集合。

eureka：註冊中心，服務的註冊與發現

zuul：閘道器元件，路由、過濾請求（ribbon hystrix）

ribbon：負載均衡元件

hystrix：熔斷元件

feign：遠端呼叫元件（整合ribbon hystrix）

4.eureka

Eureka是Netflix開發的服務發現框架，本身是一個基於REST的服務，主要用於定位執行在AWS域中的中間層服務，以達到負載均衡和中間層服務故障轉移的目的。SpringCloud將它整合在其子專案spring-cloud-netflix中，以實現SpringCloud的服務發現功能

Eureka元件

Eureka包含兩個元件：Eureka Server和Eureka Client。

Eureka Server

Eureka Server提供服務註冊服務，各個節點啟動後，會在Eureka Server中進行註冊，這樣Eureka Server中的服務登錄檔中將會儲存所有可用服務節點的資訊，服務節點的資訊可以在介面中直觀的看到。

Eureka Server本身也是一個服務，預設情況下會自動註冊到Eureka註冊中心。如果搭建單機版的Eureka Server註冊中心，則需要配置取消Eureka Server的自動註冊邏輯。畢竟當前服務註冊到當前服務代表的註冊中心中是一個說不通的邏輯。Eureka Server通過Register、Get、Renew等介面提供服務的註冊、發現和心跳檢測等服務。

Eureka Client

Eureka Client是一個java客戶端，用於簡化與Eureka Server的互動，客戶端同時也具備一個內建的、使用輪詢(round-robin)負載演算法的負載均衡器。在應用啟動後，將會向Eureka Server傳送心跳,預設週期為30秒，如果Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，Eureka Server將會從服務登錄檔中把這個服務節點移除(預設90秒)。

Eureka Client分為兩個角色，分別是：
1.Application Service(Service Provider)
2.Application Client(Service Consumer)
　　
Application Service

服務提供方，是註冊到Eureka Server中的服務。
　　
Application Client

服務消費方，通過Eureka Server發現服務，並消費。

在這裡，Application Service和Application Client不是絕對上的定義，因為Provider在提供服務的同時，也可以消費其他Provider提供的服務；Consumer在消費服務的同時，也可以提供對外服務

5.hystrix:容錯元件

Hystix解決雪崩問題的手段有兩個：

• 執行緒隔離
• 服務熔斷

區域性方法加熔斷

@HystrixCommand(fallbackMethod = "queryUserByIdFallback")

全域性方法加熔斷

@DefaultProperties(defaultFallback = "fallbackMethod")

Hystix降級：檢查每次請求，是否請求超時，或者連線池已滿

​ 1.引入hystrix啟動器

​ 2.熔斷時間，預設1s， 6s

​ 3.在引導類上新增一個註解，@EnablecircuitBreaker @SpringCloudApplication

​ 4.定義熔斷方法

​ 1）區域性：要和被熔斷的方法返回值和引數列表一致

​ 2) 全域性：返回值型別要和被熔斷的方法一致，引數列表必須為空

​ 5.@HystrixCommand（fallbackMethod=“區域性熔斷方法名”）:宣告被熔斷的方法

​ 6.@DefaultProperties(defaultFallback = “fallbackMethod”) //定義全域性的熔斷方法

Hystix熔斷：不再傳送請求

​ 1.close：閉合狀態，所有請求正常方法

​ 2.open：開啟狀態，所有請求都無法訪問。如果在一定時間內容，失敗的比例不小於50%或者次數不少於20次

​ 3.halfopen：半開狀態，開啟狀態預設5秒休眠期，在休眠期所有請求無法正常訪問，過了休眠期會進入半開狀態，放部分通過

6.feign

​ 1.引入openFeign啟動器

​ 2.feign.hystrix.enable=true, 開啟fegin的熔斷功能

​ 3.在引導類上 @EnableFeignClients

​ 4.建立一個介面，在介面新增@FeignClient（value=服務id“，fallback=實現類的.class）

​ 5.在介面中定義一些方法，這些方法的書寫方式跟之前controller類似

​ 6.建立一個熔斷類，實現feign介面，實現對應的方法，這些實現方法就是熔斷方法。

7.zuul

​ 1.引入zuul的啟動器

​ 2.配置

（1)

​ zuul.routes.<路由名稱>.path=/service-provider/**

​ zuul.routes.<路由名稱>.url=http://localhost:8082

（2)

​ zuul.routes.<路由名稱>.path=/service-provider/**

​ zuul.routes.<路由名稱>.serviceId=service-provider

（3)

​ zuul.routes.服務名=/service-provider/**

（4) 不用配置預設就是服務id開頭路徑

​ 3.@EnableZuulProxy

8.ribbon:負載均衡元件

​ 1.eureka已整合

​ 2.@LoaderBalanced開啟負載均衡

​ 3.this.restTemplate.getForObject(“http://service-provider/user/ +id ,User.class”)

過濾器：

​ 建立一個類整合ZuulFilter基類

重寫四個方法

​ filterType ：pre,route,post,error

​ filterOrder: 返回值越小優先順序越高

​ shouldFilter: 是否執行run方法。true執行

​ run：具體的攔截邏輯

---

持續更新中…