SpringCloud 簡單理解

時間 2019-11-18

標籤 springcloud 簡單理解简体版

原文原文鏈接

0.SpringCloud，微服務架構。包括服務發現（Eureka），斷路器（Hystrix），服務網關（Zuul），客戶端負載均衡（Ribbon）、服務跟蹤(Sleuth)、消息總線(Bus)、消息驅動(Stream)、批量任務(Task)等。html

微服務

1.微服務的核心思想即是服務拆分與解耦,下降複雜性。微服務強調將功能合理拆解,儘量保證每一個服務的功能單一，按照單一責任原則（Single Responsibility Principle）明確角色。將各個服務作輕，從而作到靈活、可複用，亦可根據各個服務自身資源需求，單獨佈署，單獨做橫向擴展。

服務註冊與發現 Eureka

1.@EnableEurekaServer 註解啓動一個服務註冊中心提供給其餘應用進行對話。這個註解放在啓動類上方。前端

2. Eureka分爲服務註冊中心，服務提供者，服務消費者。服務提供者、服務消費者都必須指定註冊中心。服務提供者提供服務，而服務消費者能夠調用提供者的服務。android

3.服務發現的接口DiscoveryClient類是Spring Cloud對服務治理作的一層抽象。ios

@EanbleDiscoveryClient 註解，加在啓動類main的上方，能夠將應用註冊爲Eureka 客戶端應用，以獲取服務發現的能力。git

4.Spring Cloud Consul項目：能夠將基於Spring Boot的微服務應用註冊到Consul上，並經過此實現微服務架構中的服務治理。Consul的做用相似於Eureka。
github

5.下面是Eureka的治理機制：spring

服務提供者bootstrap

服務註冊：啓動的時候會經過發送REST請求的方式將本身註冊到Eureka Server上，同時帶上了自身服務的一些元數據信息。
服務續約：在註冊完服務以後，服務提供者會維護一個心跳機制用來持續告訴Eureka Server: "我還活着」、
服務下線：當服務實例進行正常的關閉操做時，它會觸發一個服務下線的REST請求給Eureka Server, 告訴服務註冊中心：「我要下線了」。

服務消費者小程序

獲取服務：當咱們啓動服務消費者的時候，它會發送一個REST請求給服務註冊中心，來獲取上面註冊的服務清單
服務調用：服務消費者在獲取服務清單後，經過服務名能夠得到具體提供服務的實例名和該實例的元數據信息。在進行服務調用的時候，優先訪問同處一個Zone中的服務提供方。

Eureka Server(服務註冊中心)：後端

失效剔除：默認每隔一段時間（默認爲60秒）將當前清單中超時（默認爲90秒）沒有續約的服務剔除出去。
自我保護：EurekaServer 在運行期間，會統計心跳失敗的比例在15分鐘以內是否低於85%(一般因爲網絡不穩定致使)。 Eureka Server會將當前的實例註冊信息保護起來，讓這些實例不會過時，儘量保護這些註冊信息。

PS:總感受這個「失效剔除」和「自我保護」，有些矛盾。。

6.一樣做爲註冊中心，Eureka和Zookeeper的區別是什麼？

分佈式事務的CAP理論。C是一致性，A是可用性，P是分區容錯性(必備)。

Eureka是AP，注重可用性。

而Zookeeper是CP，注重一致性。

服務消費者

服務消費者 Ribbon

1.LoadBalancerClient接口，是一個負載均衡客戶端的接口。

Ribbon註解：@LoadBalanced。

2.RestTemplate對象，經過getForObject()等方法實現對服務提供者接口的調用。

注入方式以下：

    @Autowired
    private RestTemplate restTemplate;

可用方法以下：

getForObject(URI url, Class<T> responseType)

3.將eureka-server(服務註冊中心)、eureka-client(服務提供者)、eureka-consumer(服務消費者)都啓動起來，而後訪問 eureka-consumer的Controller層方法對應的請求，能夠觀察eureka-consumer服務是如何消費eureka-client服務的Controller層方法接口的。

4.使用Spring Cloud Ribbon能夠做爲服務消費者，實現服務的調用以及客戶端負載均衡。

5.在Ribbon中能夠採用服務名的方式進行請求，由於Ribbon有一個攔截器，它可以在這裏進行實際調用的時候，自動的去選取服務實例，並將實際要請求的IP地址和端口替換這裏的服務名，從而完成服務接口的調用。

服務名是application文件中的spring.application.name 屬性。

6.Ribbon底層原理：負載均衡。輪詢。

7.Ribbon：重試機制。

Eureka因爲在可用性和一致性的取捨上，選擇了可用性。因此服務調用遇到實例故障時，可使用重試機制。Ribbon的重試機制能夠經過簡單的配置實現。

spring.cloud.loadbalancer.retry.enabled=true

服務消費者 Feign

1. Feign是一套基於Netflix Feign實現的聲明式服務調用客戶端。Feign能夠作爲服務消費者。須要經過建立接口並用註解來配置它既可完成對Web服務接口的綁定。

2.@EnableFeignClients註解在Application類上方，能夠開啓掃描Spring Cloud Feign客戶端的功能

3.@FeignClient註解用在Feign接口上方，用來指定這個接口所要調用的服務名稱。

2.Feign底層原理：動態代理。

3.Feign接口支持SpringMvc的註解。包括@RequestBody，@RequestParam等

4.重試機制：Feign自帶Ribbon，默認實現了請求重試機制。當請求時間超過設置的超時時間時，Feign會發起重試。

5.使用Feign的時候，同時也會自動建立負載均衡的Ribbon，還會自動引入服務保護與容錯的Hystrix。

6.Feign最終發送request請求以及接收response響應，都是由Client組件完成的，其中Client的實現類，只要有Client.Default，該類由HttpURLConnnection實現網絡請求，另外還支持HttpClient、Okhttp。

斷路器 Hystrix

1.服務熔斷：在分佈式架構中，當某個服務單元發生故障（相似用電器發生短路）以後，經過斷路器的故障監控（相似熔斷保險絲），向調用方返回一個錯誤響應，而不是長時間的等待。這樣就不會使得線程因調用故障服務被長時間佔用不釋放，避免了故障在分佈式系統中的蔓延。

雪崩效應：是一種因服務提供者的不可用致使服務調用者的不可用,並將不可用逐漸放大的過程。

熔斷能夠避免服務雪崩。

2.Spring Cloud中使用了Hystrix 來實現斷路器的功能。Hystrix具有擁有回退機制和斷路器功能的線程和信號隔離，請求緩存和請求打包，以及監控和配置等功能。Hystrix具備融斷機制。

Hystrix能夠進行服務降級、服務隔離、服務熔斷。

3.在Ribbon中須要引入Hystrix依賴。不然服務不可用時，會返回404。

而Feign中已經依賴了Hystrix，不須要再引入，會直接返回內部錯誤(500) 。

4.@SpringCloudApplication註解，它整合了@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker。

5.當服務提供者不可用時，斷路器Hystrix會返回錯誤響應。

6.使用了@HystrixCommand來將某個函數包裝成了Hystrix命令，這裏除了定義服務降級以外，Hystrix框架就會自動的爲這個函數實現調用的隔離。因此，依賴隔離、服務降級在使用時候都是一體化實現的.

@HystrixCommond，顧名思義，使用了「命令模式」。

Hystrix通常都是和Feign一塊兒使用，使用@HystrixCommond的較少。

7.服務隔離： Hystrix使用"艙壁模式"實現線程池的隔離，它會爲每個Hystrix命令建立一個獨立的線程池，這樣就算某個在Hystrix命令包裝下的依賴服務出現延遲太高的狀況，也只是對該依賴服務的調用產生影響，而不會拖慢其餘的服務。
經過對依賴服務實現線程池隔離，應用更加健壯，不會由於個別依賴服務出現問題而引發非相關服務的異常。

8.服務降級：當服務器壓力劇增的狀況下，根據實際業務狀況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務器資源以保證核心交易正常運做或高效運做。

爲了保證重要或基本的服務能正常運行，咱們能夠將一些不重要或不緊急的服務或任務進行服務的延遲使用或暫停使用。

9.思考：服務降級和服務熔斷有什麼區別？

熔斷是直接返回一個錯誤響應，降級是延遲使用或暫停使用。

10.Hystix隔離機制：線程池隔離、信號量隔離。

11.能夠在熔斷的FallBack方法中，將Throwable異常做爲參數，並顯示熔斷的異常信息。

15.Hystrix-dashboard，能夠對服務進行監控，展現數據。

服務網關Zuul

1.服務網關：經過服務網關統一貫外系統提供REST API的過程當中，具有服務路由、均衡負載、權限控制等功能。Spring Cloud Netflix中的服務網關爲Zuul。

通常微服務架構中都必然會設計一個網關在裏面，像android、ios、pc前端、微信小程序、H5等等，不用去關心後端有幾百個服務，就知道有一個網關，全部請求都往網關走，網關會根據請求中的一些特徵，將請求轉發給後端的各個服務。並且有了網關以後，還有不少好處，好比能夠作統一的降級、限流、認證受權、安全，等等。

2.服務路由：經過服務路由的功能，在對外提供服務的時候，只須要經過暴露Zuul中配置的調用地址就可讓調用方統一的來訪問咱們的服務，而不須要了解具體提供服務的主機信息了。

3.服務過濾：在服務網關中定義過濾器只須要繼承ZuulFilter抽象類實現其定義的四個抽象函數就可對請求進行攔截與過濾。

4.網關Zuul自帶Ribbon和Hystrix。

示例圖：