SpringCloud 簡單理解

本文轉載自查看原文 2018-09-06 10:55 3086 SpringCloud

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

微服務

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

服務注冊與發現 Eureka

1.@EnableEurekaServer 注解啟動一個服務注冊中心提供給其他應用進行對話。這個注解放在啟動類上方。

2. Eureka分為服務注冊中心，服務提供者，服務消費者。服務提供者、服務消費者都必須指定注冊中心。服務提供者提供服務，而服務消費者可以調用提供者的服務。

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

@EanbleDiscoveryClient 注解，加在啟動類main的上方，可以將應用注冊為Eureka 客戶端應用，以獲取服務發現的能力。

4.Spring Cloud Consul項目：可以將基於Spring Boot的微服務應用注冊到Consul上，並通過此實現微服務架構中的服務治理。Consul的作用類似於Eureka。

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

服務提供者

服務注冊：啟動的時候會通過發送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。

示例圖：