阿里面試官問我SpringCloud，附答案

每日一句： To always face my adversity head on.

下面整理了一些面試的過程當中被問到的Spring相關的題目，只因簡歷上寫了熟練使用SpringBoot，SpringCloud。但願爲即將準備面試的胖友提供一些幫助，平時仍是要多關注一些細節的地方！

SpringBoot的優點是什麼? 自動配置/依賴的原理是什麼?

SpringBoot能夠快速一鍵搭建一個基於Spring的生產就緒的應用框架，簡化Spring應用的初始搭建以及開發過程：

• 最大的優點在於簡化配置和簡化編碼方面，簡化了以前開發Spring應用繁瑣的配置，它內部集成了經常使用的第三方庫配置，SpringBoot中這些第三方庫幾乎能夠零配置的開箱即用，大部分SpringBoot應用都只須要很是少許的配置代碼和極簡的maven pom 文件的配置，使得開發者能夠更專一於業務邏輯的開發。
• 簡化部署，SpringBoot內置了Tomcat, 咱們只須要把項目打成jar包就能夠一鍵啓動
• 簡化監控，咱們能夠直接使用spring-boot-start-actuator對服務進行運行期性能和健康的監控

自動配置原理

SpringBoot自動配置自帶了不少了配置類，自動配置創建在spring條件化配置基礎之上的：

1. 首先SpringBoot的主配置類上的@SpringBootApplication 開啓了自動配置功能@EnableAutoConfiguration

2. @EnableAutoConfiguration 利用AutoConfigurationImportSelector將META-INF/spring.factories裏面配置的全部xxxAutoConfiguration的配置類都加入容器中，用他們來作自動配置。spring-boot-autoconfiguration的jar 文件裏面包含了不少的配置類，好比jpa， mvc，redis,neo4j。用戶能夠本身選擇是否在程序裏面使用他們，這些配置類構成了Springboot的自動配置。

   儘管這些配置存在與應用程序的ClassPath中，可是在知足某些條件以前應用會忽略這個配置，好比：

   Spring啓動的時候會作幾百次這樣的檢查，好比檢查Jdbctemplate是否是在Classpath裏面，若是是就會配置一個對應的jdbcTemplate的配置Bean。 全部的這些配置都是儘可能的不讓開發者本身去寫配置。

SpringCloud裏你還對哪些組件比較熟悉?

服務註冊中心Eureka

服務提供者向服務註冊中心進行服務的註冊，並週期性的發送心跳來更新服務信息，服務消費者拉取服務註冊中心的服務列表並維護在本地，並從服務列表中拉取一個服務進行消費。

Eureka自己支持高可用，能夠經過集羣的方式部署，Eureka Server之間也能夠相互註冊，相互同步服務信息。

• 失效服務的剔除： 好比超過30s沒有心跳的服務，就會被Eureka標記爲不可用

• 自我保護機制：

  ​ 當Eureka 與其它服務之間的心跳大面積失敗的時候，它會認爲多是本身的問題，好比本身網絡很差，就會把註冊的信息保護起來。這時若是有消費者來訪問，可能就會拿到真正過時的服務的狀況。

Ribbon負載均衡器

• Ribbon 是一個基於HTTP的客戶端負載均衡器，能夠在客戶端負載均衡訪問服務提供者列表提供的服務
• Ribbon 提供了一系列完善的配置項如鏈接超時，重試等，Ribbon會自動的某種算法去鏈接機器

Fegin

• 微服務之間聲明式的調用，整合了Ribbon和Eureka，關鍵機制是使用了動態代理，讓用戶不用本身去寫HTTP請求，讓客戶端以爲調用本地接口就像調用其它服務同樣。
  • 首先，對於某個接口定義了@FeginClient 註解，Fegin就會針對這個接口建立一個動態代理
  • 接着，調用接口的時候，本質上是調用Fegin建立的動態代理
  • Fegin 會根據接口上的@RequestMapping等註解，來動態構造要請求的服務的地址
  • 針對這個地址，發起請求，解析響應

Zuul

Zuul的原理： 經過一個統一的Servlet入口ZuulServlet攔截全部的請求，而後經過ZuulFilter鏈對請求作攔截和過濾處理。Zuul大部分功能都是經過過濾器來實現的，Zuul中定義了4種標準的過濾器，這些過濾器對應於請求的典型生命週期：

1. PRE: 請求路由到某個服務以前調用，能夠實現身份驗證等

2. ROUTING: 用於構建發送給微服務的請求，並經過HttpClient 或 Ribbon 請求微服務

3. POST: 在請求路由到微服務之後執行，能夠爲響應結果添加Http Header, 將結果發送給客戶端

4. ERROR: 在其它階段發生錯誤的時候執行該過濾器

• 客戶端只須要請求Zuul網關就能夠了，無須要調用特定微服務,由Zuul網關負責轉發請求，這樣開發就能夠獲得簡化，易於作監控，易於安全認證（好比不須要再每個微服務上都進行認證）負載均衡等。

Config

微服務數量比較多的時候，配置管理就比較複雜了，SpringCloud Config經過分佈式配置中心來統一管理配置文件並能夠實時更新。Config Server用於配置屬性的存儲，Config Client用於服務屬性的讀取。

Bus

當配置文件須要動態更新的時候，能夠經過Bus在不關閉服務的狀況下更新咱們的配置。

Hystrix 熔斷限流降級

• 防止因服務提供者的不可用致使服務調用者的不可用，並將不可用逐漸放大雪崩的過程。

Hystrix熔斷過程講一下? Hystrix實現原理講一下? 線程池和信號量熔斷區別?

• 熔斷過程：當用戶請求量大或者緩存擊穿，會照成後端服務提供者的瞬間超負荷容許，引發服務不可用，當Hystrix檢查到超時或者出現異常的時候，就會執行fallback方法而不是讓client一直等待或重試。
• 服務降級過程： 當服務壓力劇增時，能夠根據流量狀況對一些服務的頁面作降級，好比返回一個默認值或者返回一個提示，讓用戶稍後重試之類。若是目標服務狀況好轉則恢復正常調用。

Hystrix的實現能夠基於線程池或信號量的方式：

• 基於線程池： 在服務和請求之間增長了一個線程池，用戶的請求將再也不直接訪問服務，而是先通過熔斷器，而後經過線程池中空閒線程來訪問服務，若是這個時候熔斷器是打開的，說明已經熔斷了，直接進行降級處理。 當線程池飽和而且請求隊列阻塞的時候，能夠提早拒絕服務。
• 基於信號量：當請求進入熔斷器時，會有一個計數的信號量，每來一個請求數，計數器加1，結果大於最大請求的時候，就返回false，發生信號量拒絕事件，執行降級邏輯。當請求離開熔斷器時，執行release()，計數器減1。信號量模式下，接收請求和執行下游依賴在同一個線程內完成，不存在線程上下文切換帶來的性能開銷。

線程池和信號量熔斷區別?

• 資源消耗方面，信號量只是個計數器，資源消耗小，若是有數百個服務實例，線程池作隔離的開銷過大，會有上下文的切換開銷
• 信號量的調用時同步的，每次調用都會阻塞調用方的線程直到結果返回，不支持異步，不支持超時，線程池支持超時返回
• 信號量是達到最大請求量閾值時熔斷，線程池時達到最大線程數熔斷

Hystrix/Feign/Ribbon之間如何配合的, 代碼上架構是怎樣的?

Fegin 經過代理模式自動將全部的方法用Hystrix進行了包裝，目的是在調用方實施針對被調用微服務的熔斷邏輯，針對被調用服務設置超時時間，一旦超時就會進入熔斷邏輯，而這個故障指標信息也會返回給Hystrix組件，hystrix根據故障信息打開斷路器，以後全部針對該微服務的請求都會直接進入熔斷邏輯，直到故障恢復關閉斷路器爲止。

• 首先Ribbon從Eureka Client 裏面獲取對應的服務註冊表，好比服務的ip 和 端口
• 而後Ribbon使用默認的的Round Robin算法，從中選擇一臺機器
• Fegin就會針對這臺機器，構造代理併發起http請求

總結

SpringCloud SpringBoot 這套技術棧，你們平時本身使用的過程，可能以爲比較簡單，不過了解其底層實現細節，對咱們寫出高性能的服務架構確定大有裨益。好比在瞭解原理後，咱們知道Hystrix在有大量的請求時，若是默認使用線程池可能會頻繁的線程切換，更加劇系統性能，這時候能夠考慮切換了。

最後歡迎你們關注「開發運維技術圈」公衆號，羣裏有阿里雲，螞蟻，口碑，字節的同窗，也有各類崗位內推哦！