spingcloud組件註解彙總

服務治理Eureka

Eureka註冊中心配置

@EnableEurekaServer：啓動服務註冊中心

application.properties裏面的配置，服務名 spring.application.name ,註冊中心註冊名eureka.instance.hostname, 服務端口server.port,是否要像註冊中內心註冊本身eureka.client.register-with-eureka, 是否要檢索服務eureka.client.fetch-registry

註冊中心的做用：

1.剔除過時服務

2.服務同步

3.傳播下線事件

Eureka Client

@EnableDiscoveryClient:激活Eureka中的DiscoveryClient的實現

因爲服務可部署多個實例，ribbon輪詢的時候先找到該服務，再找到該服務實例，因此服務地址存放在一個雙層map中，第一層key是服務名，第二層key是具體服務的實例名。

EurekaClient做用：

1.向註冊中心註冊

2.服務續約

3.服務下線

4.查詢服務列表

 

 

 

 Ribbon

負載均衡Ribbon基於TCP和HTTP的客戶端負載均衡器，經過ribbonServerList服務端列表去輪詢訪問以達到負載均衡的做用。

建立RestTemplate實例，並在上面加上註解@Bean和@LoadBalanced開啓客戶端負載均衡。

ribbon源碼分析，所謂負載均衡本質就是在客戶端發出請求前將其攔截，找到存在客戶端本地的服務端列表，經過某種負載均衡方式，默認是輪詢，挑選服務實例執行請求。

讓咱們本身靜下心想想，springcloud設計時須要提供負載均衡功能，ribbon只是一種經常使用的實現負載均衡的組件，不免往後會有其餘的替代品。故而在sprigcloud中留有一個接口專門讓客戶端負載均衡器來實現，這個接口叫LoadBalancerClient。

客戶端負載均衡器在本地存有一份雙層map的實例清單，第一層map的key值爲服務名，第二層存放具體的實例。實現負載均衡須要三步，

第一步，根據服務名選擇服務實例。

第二步，被挑選的實例執行請求內容。

第三步，從新構造URI，把URI中寫的服務名替換成實際的帶有ip，port的名字。

只在須要負載均衡的restTemplate中加上@LoadBalanced，便可實現負載均衡的話，那在這裏面必定是用到了springboot的自動配置原理。咱們要關注幾個有條件的註解，

@ConditionalOnClass和@ConditionalOnBean。在負載均衡自動配置類中，LoadBalancerAutoConfiguration的自動加載必須有RestTemplate類存在於當前環境工程中，spring的bean工程中必須有LoadBalancerClient實現Bean的存在。

在自動化配置類LoadBalancerAutoConfiguration中，主要實現了三件事。這三件事都是有關聯的

第一件，建立LoadBalancerInterceptor,  裏面有攔截的具體方法

第二件，建立RestTemplateCustomizer的bean，用於給RestTemplate增長攔截器

第三件，維護List<RestTemplate>，並初始化，遍歷該列表，給每個RestTemplate增長了LoadBalancerInterceptor

因爲每一個RestTemplate中都增長了攔截器，restTemplate執行請求時會被intercept方法攔截，根據服務名，調用execute函數來選擇實例併發起實際的請求。

 

 Hystrix

爲何須要熔斷器？

由於服務之間的互相調用，不免會出現失敗的狀況，A服務調用B，B出現故障，若是此時對A服務方法大量調用，造成任務積壓，則可能致使A服務失效。

熔斷器就是給方法設置一個超時時間，timeOutInMissiseconds，到了超時時間，方法還沒執行完，就執行設置的默認方法，或者直接熔斷。

讓咱們來想一想，若是咱們設置熔斷會如何，其實就是監視方法，計算調用時間，若是超時，則報錯或者執行降級服務。這個地方須要用到命令模式，將每一個請求都看作是一個命令，方法是一個執行者，二者中間須要一個協調者，決定是否要控制併發量接收該命令，決定如何撤回該命令。

咱們先了解下hystrix的執行流程

1.將請求封裝成hystrixCommand或者是hystrixObservableCommand

2.執行命令，同步或者異步兩種方式

3.判斷該請求是否在緩存中，若是在直接返回，否則進入下一步

4.判斷斷路器是否打開，若是已打開，直接返調用服務降級回調方法。若是沒打開，進入下一步

5.判斷是否有足夠的線程池中的線程或者信號量來執行方法，沒有則調用降級方法，並計算是否要打開斷路器。若是有，進入下一步

6.執行調用的方法，若是方法失敗或者超時，執行降級方法，並計算是否要開啓斷路器；若是執行成功，hystrix在記錄日誌並採集監控報告以後將結果返回。

服務降級方法須要實現通用的響應結果，通常是從緩存中獲取，或者是靜態邏輯獲取。若是須要經過網絡獲取，則該服務降級方法也要包裹成一個hystrixCommand，從而生成級聯的降級策略。

3.1

如何開啓hystrix緩存？

在@HystrixCommand註解上加上@CacheResult註解，標記緩存返回的結果，key值是全部請求參數。或者重寫getCacheKey方法，讓其返回非null的key。HystrixCommand類裏面getCacheKey方法返回的是null。

如何清除失效緩存？

在update方法上加上@CacheRemove註解，並用commandKey在裏面指定失效的是哪個請求命令。或者在HystrixCommand的實現類裏調用請求命令的緩存清除。

如何將某特定請求參數做爲緩存的key值？

能夠在參數前加上@CacheKey或者在@CacheResult裏面定義一個方法CacheKeyMethod指定專門生成key的方法。

斷路器中有三個方法，4.1.判斷斷路器是否打開(isOpen) 4.2.閉合斷路器  4.3.判斷請求是否被容許。

4.1.1 斷路器打開標誌是開，直接返回true。

4.1.2 斷路器打開標誌爲關，判斷請求量是否大於閾值，而且失敗率大於閾值，若是都大於則CAS將斷路器設置爲打開，並返回true。

4.3.1 若是設置了強制打開斷路器，則不容許請求；若是強制關閉斷路器，會運行請求，但也會執行isOpen，來執行計算斷路器是否打開的邏輯。

4.3.2 若是沒有設置強制打開或者強制關閉，若是斷路器關閉容許經過，或者allowSingleTest返回true也容許請求經過。

4.3.3 allowSingleTest即給斷路器設置了一個休眠時間，默認5S，若是斷路器距離上一次設置的時間超過5S,則嘗試請求經過，若是請求仍是失敗，則等待下一個休眠窗口過去再重試。這種方式稱爲半打開。

什麼狀況會形成斷路器打開？

請求總數（QPS）和失敗比例超過閾值。

什麼狀況會讓斷路器由打開改成關閉呢？

斷路器每隔一段時間，就會容許請求經過，稱爲半打開，若是請求執行成功，斷路器則關閉。

什麼狀況會放請求進來？

斷路器閉合或者休眠窗口剛過去。

半打開狀態會放多少請求進來？

休眠窗口過去的第一個請求，容許請求訪問，並用CAS設置最新的請求嘗試時間，在CAS設置成功以前的請求都會被放進來容許訪問。

何時會觸發服務降級？

斷路器熔斷，線程池或信號量資源不夠，方法執行錯誤，拋出除HystrixBadRequestException以外的錯誤，方法執行超時

有沒有辦法方法執行錯誤時，不會調用服務降級？

有的，設置@HystrixCommand裏的ignoreExceptions參數便可

5.1 Hystrix採用線程池隔離技術，每一個依賴服務建立一個獨立的線程池。

 

  Feign

前面