前段時間因特殊原因，導致我們的面試連環炮斷更了，剛好上週一位老鐵去面試被問到了Spring Cloud，然後結合他的回饋，今天我們繼續走起SpringCloud面試連環砲。
歡迎大家追蹤我：
#下面是一張Spring Cloud核心元件關係圖：
從這張圖中，其實我們是可以獲取很多資訊的，希望大家細細品嚐。
以下是Spring Cloud Netflix和Spring Cloud Alibaba核心元件的總結：
活不多說，我們直接開始 Spring Cloud 連環砲。
Spring cloud 流應用程式啟動器是基於 Spring Boot 的 Spring 整合應用程序，提供與外部系統的整合。 Spring cloud Task，一個生命週期短暫的微服務框架，用於快速建立執行有限資料處理的應用程式。
微服務架構是一種架構模式或說是一種架構風格，它提倡將單一應用程式劃分為一組小的服務，每個服務運行在其獨立的在自己的進程中，服務之間相互協調、相互配合，為使用者提供最終價值。服務之間採用輕量級的通訊機制互相溝通（通常是基於HTTP的RESTful API）,每個服務都圍繞著具體的業務進行構建，並且能夠被獨立的構建在生產環境、類生產環境等。另外，應避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的資料儲存。
通俗的來講：
微服務就是一個獨立的職責單一的服務應用程式。在 intellij idea 工具裡面就是用maven開發的一個個獨立的module，具體就是使用springboot 開發的一個小的模組，處理單一專業的業務邏輯，一個模組只做一個事情。
微服務強調的是服務大小，關注的是某一點，具體解決某一個問題/落地對應的一個服務應用，可以看做是idea 裡面一個 module。
#使用 Spring Boot 開發分散式微服務時，我們面臨以下問題
同步通訊：dobbo透過RPC 遠端過程調用、springcloud透過REST 介面json呼叫等。
非同步：訊息佇列，如：RabbitMq、ActiveM、Kafka等訊息佇列。
熔斷機制是應對雪崩效應的一種微服務連結保護機制。當某個微服務不可用或回應時間太長時，會進行服務降級，進而熔斷該節點微服務的調用，快速返回「錯誤」的回應訊息。當偵測到該節點微服務呼叫響應正常後恢復呼叫鏈路。在Spring Cloud框架裡熔斷機制透過Hystrix實現，Hystrix會監控微服務間呼叫的狀況，當失敗的呼叫到一定閾值，缺省是5秒內呼叫20次，如果失敗，就會啟動熔斷機制。
服務降級，一般是從整體負載考慮。就是當某個服務熔斷之後，伺服器將不再被調用，此時客戶端可以自己準備一個本地的fallback回調，返回一個預設值。這樣做，雖然水平下降，但好歹可用，比直接掛掉強。
Hystrix相關註解@EnableHystrix：開啟熔斷@HystrixCommand(fallbackMethod=”XXX”)，宣告一個失敗回滾處理函數XXX ，當被註解的方法執行逾時（預設是1000毫秒），就會執行fallback函數，傳回錯誤提示。
Zookeeper保證了CP，Eureka保證了AP。
A：高可用
C：一致性
P：分割區容錯性
1.當向註冊中心查詢服務清單時，我們可以容忍註冊中心返回的是幾分鐘以前的信息，但不能容忍直接down掉不可用。也就是說，服務註冊功能對高可用性要求比較高，但zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯繫時，剩餘節點會重新選leader。問題在於，選取leader時間過長，30 ~ 120s，且選取期間zk叢集都不可用，這樣就會導致選取期間註冊服務癱瘓。在雲端部署的環境下，因網路問題使得zk叢集失去master節點是較大機率會發生的事，雖然服務能夠恢復，但是漫長的選取時間導致的註冊長期不可用是不能容忍的。
2.Eureka保證了可用性，Eureka各個節點是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點仍然可以提供註冊和查詢服務。而Eureka的客戶端向某個Eureka註冊或發現時發生連線失敗，則會自動切換到其他節點，只要有一台Eureka還在，就能保證註冊服務可用，只是查到的資訊可能不是最新的。除此之外，Eureka還有自我保護機制，如果在15分鐘內超過85%的節點沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心發生了網路故障，此時會出現以下幾種情況：
①、Eureka不在從註冊清單中移除因為長時間沒有收到心跳而應該過期的服務。
②、Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其他節點上（即保證當前節點仍然可用）
③、當網路穩定時，目前實例新的註冊資訊會被同步到其他節點。
因此，Eureka可以很好的應對因網路故障導致部分節點失去聯繫的情況，而不會像Zookeeper那樣使整個微服務癱瘓
SpringBoot專注於快速方便的開發單一個體微服務。
SpringCloud是專注於全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，
為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全域鎖、決策競選、分散式會話等等集成服務
SpringBoot可以離開SpringCloud獨立使用開發項目， 但是SpringCloud離不開SpringBoot ，屬於依賴的關係.
SpringBoot專注於快速、方便的開發單一微服務個體，SpringCloud關注全局的服務治理框架。
在計算中，負載平衡可以改善跨計算機，計算機集群，網絡鏈接，中央處理單元或磁碟機等多種計算資源的工作負載分佈。負載平衡旨在優化資源使用，最大化吞吐量，最小化回應時間並避免任何單一資源 的過載。使用多個組件進行負載平衡而不是單一組件可能會透過冗餘來提高可靠性和可用性。負載平衡通常涉及專用軟體或硬體，例如多層交換器或網域名稱系統伺服器進程。
Hystrix是一個延遲和容錯庫，旨在隔離遠端系統，服務和第三方程式庫的存取點，當出現故障是不可避免的故障時，停止級聯故障並在複雜的分散式系統中實現彈性。
通常是使用微服務架構開發的系統，涉及許多微服務。這些微服務彼此協作。
思考以下微服務
#假設如果上圖的微服務9失敗了，那麼使用傳統方法我們將傳播一個異常。但這仍然會導致整個系統崩潰。
隨著微服務數量的增加，這個問題變得更加複雜。微服務的數量可以高達1000.這是hystrix出現的地方 我們將使用Hystrix在這種情況下的Fallback方法功能。我們有兩個服務employee-consumer使用由employee-consumer公開的服務。
簡化圖如下
#現在假設由於某種原因，employee-producer公開的服務會拋出異常。我們在這種情況下使用Hystrix定義了一個回退方法。這種後備方法應該具有與公開服務相同的回傳類型。如果暴露服務中出現異常，則回退方法將傳回一些值。
由於某些原因，employee-consumer公開服務會引發例外狀況。在這種情況下使用Hystrix我們定義了一個回退方法。如果在公開服務中發生異常，則回退方法會傳回一些預設值。
如果firstPage method() 中的例外狀況繼續發生，則Hystrix電路將中斷，並且員工使用者將一起跳過firtsPage方法，並直接呼叫回退方法。斷路器的目的是給第一頁方法或第一頁方法可能呼叫的其他方法留出時間，並導致異常恢復。可能發生的情況是，在負載較小的情況下，導致異常的問題有更好的恢復機會 。
首先需要有處理網路連線通訊的模組，負責連接建立、管理和訊息的傳輸。其次需要有編 解碼的模組，因為網路通訊都是傳輸的字節碼，需要將我們使用的物件序列化和反序列 化。剩下的就是客戶端和伺服器端的部分，伺服器端暴露要開放的服務接口，客戶調用服 務接口的一個代理實現，這個代理實現負責收集數據、編碼並傳輸給伺服器然後等待結果 返回。
#當Eureka Server 節點在短時間內遺失了過多實例的連線時（例如網路故障或頻繁啟動關閉客戶端）節點會進入自我保護模式，保護註冊訊息，不再刪除註冊數據，故障恢復時，自動退出自我保護模式。
ribbon是一個負載平衡客戶端，可以很好的控制htt和tcp的一些行為。 feign預設整合了ribbon。
Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 啟發的 java 用戶端聯編程式。
Feign 的第一個目標是將約束分母的複雜性統一到 http apis，而不考慮其穩定性。
特點：
指定呼叫哪個服務Spring Boot是Spring推出用於解決傳統框架設定檔冗餘,組裝組件繁雜的基於Maven的解決方案,旨在快速建立單一微服務 而Spring Cloud專注於解決各個微服務之間的協調與配置,服務之間的通訊,熔斷,負載平衡等 技術維度並相同,並且Spring Cloud是依賴於Spring Boot的,而Spring Boot並不是依賴與Spring Cloud,甚至還可以和Dubbo進行優秀的整合開發
總結
也就是我們常說的服務的註冊與發現，直接透過遠端過程呼叫來存取別的service。
優點：簡單，常見,因為沒有中間件代理，系統更簡單
缺點：只支援請求/回應的模式，不支援別的，例如通知、請求/非同步回應、發布/訂閱、發布/非同步回應，降低了可用性，因為客戶端和服務端在請求過程中必須都是可用的。
使用非同步訊息來做服務間通訊。服務間透過訊息管道來交換訊息，從而通訊。
優點：把客戶端和服務端解耦，更鬆耦合，提高可用性，因為訊息中間件快取了訊息，直到消費者可以消費， 支援很多通訊機制例如通知、請求/非同步回應、發布/訂閱、發布/非同步回應。
缺點：訊息中間件有額外的複雜。
#服務發佈時，指定對應的服務名，將服務註冊到註冊中心(Eureka 、Zookeeper)。
註冊中心加上@EnableEurekaServer，服務用@EnableDiscoveryClient，然後用ribbon或feign進行服務直接的呼叫發現。
此題偏向向實戰，就看你是不是背面試題的，沒有實戰的人是不知道的。
在複雜的分散式系統中,微服務之間的相互調用,有可能出現各種各樣的原因導致服務的阻塞,在高並發場景下,服務的阻塞意味著執行緒的阻塞,導致目前執行緒不可用,伺服器的執行緒全部阻塞,導致伺服器崩潰,由於服務之間的呼叫關係是同步的,會對整個微服務系統造成服務雪崩
為了解決某個微服務的呼叫回應時間過長或不可用進而佔用越來越多的系統資源引起雪崩效應就需要進行服務熔斷和服務降級處理。
所謂的服務熔斷指的是某個服務故障或異常一起類似顯示世界中的「保險絲"當某個異常條件被觸發就直接熔斷整個服務，而不是一直等到此服務超時。
服務熔斷就是相當於我們電閘的保險絲,一旦發生服務雪崩的,就會熔斷整個服務,通過維護一個自己的線程池,當線程達到閾值的時候就啟動服務降級,如果其他請求繼續訪問就直接回傳fallback的預設值
當Eureka Server 節點在短時間內遺失了過多實例的連線時（例如網路故障或頻繁啟動關閉客戶端）節點會進入自我保護模式，保護註冊訊息，不再刪除註冊數據，故障恢復時，自動退出自我保護模式。
#spring cloud bus 將分散式的節點用輕量級的訊息代理連接起來，它可以用於廣播設定檔的變更或服務直接的通訊，也可用於監控。如果修改了設定文件，發送一次請求，所有的客戶端就會重新讀取設定檔。
#當一個服務呼叫另一個服務因為網路原因或自身原因出現問題，呼叫者就會等待被呼叫者的回應，當更多的服務請求到這些資源導致更多的請求等待，發生連鎖效應（雪崩效應）。一段時間內 達到一定的次數無法呼叫 並且多次監控沒有恢復的跡象，這時候斷路器完全打開 那麼下次請求就不會請求到該服務。
半開：短時間內 有恢復跡象 斷路器會將部分請求發給該服務，正常呼叫時 斷路器關閉。關閉：當服務一直處於正常狀態 能正常呼叫。
#在分散式系統中，由於服務數量巨多，為了方便服務設定檔統一管理，即時更新，所以需要分散式配置中心元件。在Spring Cloud中，有分散式配置中心元件Spring Cloud Config，它支援配置服務放在配置服務的記憶體中（即本地），也支援放在遠端Git倉庫中。
在Spring Cloud Config 元件中，分成兩個角色，一是config server，二是config client。
使用方式：
Spring Cloud Gateway是Spring Cloud官方推出的第二代網關框架，取代Zuul網關。網關作為流量的，在微服務系統中有著非常作用，網關常見的功能有路由轉送、權限校驗、限流控制等作用。
使用了一個RouteLocatorBuilder的bean去創建路由，除了創建路由RouteLocatorBuilder可以讓你添加各種predicates和filters，predicates斷言的意思，顧名思義就是根據具體的請求的規則，由具體的route去處理，filters是各種過濾器，用來對請求做各種判斷和修改。
參考；http://1pgqu.cn/M0NZo
Spring Cloud目前相當的火熱，也差不多是java開發者必備技能之一了。面試的時候被問到，那也是正常不過了，很多人可能用來很久，但是沒有去了解原理，面試照樣掛掉。背面試題，在很大層面上還是很有用的。但從長遠角度來說，希望大家更深層去學習、去實踐。只有自己真的掌握，那才叫NB。
以上是面試回饋 Spring Cloud 的25連環砲的詳細內容。更多資訊請關注PHP中文網其他相關文章！
