第二版：SpringCloud 70 道 面試題

最近我一直在面試高級工程師，無論初級，高級，程序員，我想面試前，你們刷題必定是是少不了吧。

我也同樣，我在網上找了不少面試題來看，最近又遇上跳槽的高峯期，好多粉絲，都問我要有沒有最新面試題，索性，我就把我看過的和我面試中的真題，及答案都整理好，整理了《第2版：互聯網大廠面試題》並分類92份 PDF，累計 3625頁 我會持續更新中，立刻就出第三版，涵蓋大廠算法會更多！

其餘都已經在公衆號更新

關注公衆號：搜雲庫技術團隊，回覆：面試題，便可獲取所有

第2版：題庫很是全面

包括 Java 集合、JVM、多線程、併發編程、設計模式、Spring全家桶、Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、MongoDB、Redis、MySQL、RabbitMQ、Kafka、Linux、Netty、Tomcat、Python、HTML、CSS、Vue、React、JavaScript、Android 大數據、阿里巴巴等大廠面試題等、等技術棧！

• 什麼是微服務架構

  • 爲何須要學習Spring Cloud
  • Spring Cloud 是什麼
  • SpringCloud的優缺點
  • SpringBoot和SpringCloud的區別？
  • Spring Cloud和SpringBoot版本對應關係
  • SpringCloud由什麼組成
  • 使用 Spring Boot 開發分佈式微服務時，咱們面臨什麼問題
  • Spring Cloud 和dubbo區別?

• Eureka

  • 服務註冊和發現是什麼意思？Spring Cloud 如何實現？
  • 什麼是Eureka
  • Eureka怎麼實現高可用
  • 什麼是Eureka的自我保護模式，
  • DiscoveryClient的做用
  • Eureka和ZooKeeper均可以提供服務註冊與發現的功能,請說說兩個的區別

• Zuul

  • 什麼是網關?
  • 網關的做用是什麼
  • 什麼是Spring Cloud Zuul（服務網關）
  • 網關與過濾器有什麼區別
  • 經常使用網關框架有那些？
  • Zuul與Nginx有什麼區別？
  • 既然Nginx能夠實現網關？爲何還須要使用Zuul框架
  • 如何設計一套API接口
  • ZuulFilter經常使用有那些方法
  • 如何實現動態Zuul網關路由轉發
  • Zuul網關如何搭建集羣

• Ribbon

  • 負載平衡的意義什麼？
  • Ribbon是什麼？
  • Nginx與Ribbon的區別
  • Ribbon底層實現原理
  • @LoadBalanced註解的做用

• Hystrix

  • 什麼是斷路器
  • 什麼是 Hystrix？
  • 談談服務雪崩效應
  • 在微服務中，如何保護服務?
  • 服務雪崩效應產生的緣由
  • 談談服務降級、熔斷、服務隔離
  • 服務降級底層是如何實現的？

• Feign

  • 什麼是Feign？
  • SpringCloud有幾種調用接口方式
  • Ribbon和Feign調用服務的區別

• Bus

  • 什麼是 Spring Cloud Bus？

• Config

  • 什麼是Spring Cloud Config?
  • 分佈式配置中心有那些框架？
  • 分佈式配置中心的做用？
  • SpringCloud Config 能夠實現實時刷新嗎？

• Gateway

  • 什麼是Spring Cloud Gateway?

• SpringCloud主要項目

  • Spring Cloud Config
  • Spring Cloud Netflix(重點，這些組件用的最多))
  • Spring Cloud Bus
  • Spring Cloud Consul
  • Spring Cloud Security
  • Spring Cloud Sleuth
  • Spring Cloud Stream
  • Spring Cloud Task
  • Spring Cloud Zookeeper
  • Spring Cloud Gateway
  • Spring Cloud OpenFeign

  • Spring Cloud的版本關係

    • Spring Cloud和SpringBoot版本對應關係
    • Spring Cloud和各子項目版本對應關係

什麼是微服務架構

• 微服務架構就是將單體的應用程序分紅多個應用程序，這多個應用程序就成爲微服務，每一個微服務運行在本身的進程中，並使用輕量級的機制通訊。這些服務圍繞業務能力來劃分，並經過自動化部署機制來獨立部署。這些服務可使用不一樣的編程語言，不一樣數據庫，以保證最低限度的集中式管理。

爲何須要學習Spring Cloud

• 首先springcloud基於spingboot的優雅簡潔，可還記得咱們被無數xml支配的恐懼？可還記得springmvc，mybatis錯綜複雜的配置，有了spingboot，這些東西都不須要了，spingboot好處再也不贅訴，springcloud就基於SpringBoot把市場上優秀的服務框架組合起來，經過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理
• 什麼叫作開箱即用？即便是當年的黃金搭檔dubbo+zookeeper下載配置起來也是頗費心神的！而springcloud完成這些只須要一個jar的依賴就能夠了！
• springcloud大多數子模塊都是直擊痛點，像zuul解決的跨域，fegin解決的負載均衡，hystrix的熔斷機制等等等等

Spring Cloud 是什麼

• Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、智能路由、消息總線、負載均衡、斷路器、數據監控等，均可以用Spring Boot的開發風格作到一鍵啓動和部署。
• Spring Cloud並無重複製造輪子，它只是將各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，經過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。

SpringCloud的優缺點

優勢：

1.耦合度比較低。不會影響其餘模塊的開發。

  2.減輕團隊的成本，能夠並行開發，不用關注其餘人怎麼開發，先關注本身的開發。

  3.配置比較簡單，基本用註解就能實現，不用使用過多的配置文件。

  4.微服務跨平臺的，能夠用任何一種語言開發。

  5.每一個微服務能夠有本身的獨立的數據庫也有用公共的數據庫。

  6.直接寫後端的代碼，不用關注前端怎麼開發，直接寫本身的後端代碼便可，而後暴露接口，經過組件進行服務通訊。

缺點：

1.部署比較麻煩，給運維工程師帶來必定的麻煩。

 2.針對數據的管理比麻煩，由於微服務能夠每一個微服務使用一個數據庫。

 3.系統集成測試比較麻煩

 4.性能的監控比較麻煩。【最好開發一個大屏監控系統】

• 總的來講優勢大過於缺點，目前看來Spring Cloud是一套很是完善的分佈式框架，目前不少企業開始用微服務、Spring Cloud的優點是顯而易見的。所以對於想研究微服務架構的同窗來講，學習Spring Cloud是一個不錯的選擇。

SpringBoot和SpringCloud的區別？

• SpringBoot專一於快速方便的開發單個個體微服務。
• SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，
• 爲各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務
• SpringBoot能夠離開SpringCloud獨立使用開發項目， 可是SpringCloud離不開SpringBoot ，屬於依賴的關係
• SpringBoot專一於快速、方便的開發單個微服務個體，SpringCloud關注全局的服務治理框架。

Spring Cloud和SpringBoot版本對應關係

Spring Cloud Version	SpringBoot Version
Hoxton	2.2.x
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

SpringCloud由什麼組成

• 這就有不少了，我講幾個開發中最重要的

  *  Spring Cloud Eureka：服務註冊與發現
  *  Spring Cloud Zuul：服務網關
  *  Spring Cloud Ribbon：客戶端負載均衡
  *  Spring Cloud Feign：聲明性的Web服務客戶端
  *  Spring Cloud Hystrix：斷路器
  *  Spring Cloud Config：分佈式統一配置管理
  *  等20幾個框架，開源一直在更新

使用 Spring Boot 開發分佈式微服務時，咱們面臨什麼問題

• （1）與分佈式系統相關的複雜性-這種開銷包括網絡問題，延遲開銷，帶寬問題，安全問題。
• （2）服務發現-服務發現工具管理羣集中的流程和服務如何查找和互相交談。它涉及一個服務目錄，在該目錄中註冊服務，而後可以查找並鏈接到該目錄中的服務。
• （3）冗餘-分佈式系統中的冗餘問題。
• （4）負載平衡 --負載平衡改善跨多個計算資源的工做負荷，諸如計算機，計算機集羣，網絡鏈路，中央處理單元，或磁盤驅動器的分佈。
• （5）性能-問題 因爲各類運營開銷致使的性能問題。

Spring Cloud 和dubbo區別?

• （1）服務調用方式：dubbo是RPC springcloud Rest Api
• （2）註冊中心：dubbo 是zookeeper springcloud是eureka，也能夠是zookeeper
• （3）服務網關，dubbo自己沒有實現，只能經過其餘第三方技術整合，springcloud有Zuul路由網關，做爲路由服務器，進行消費者的請求分發,springcloud支持斷路器，與git完美集成配置文件支持版本控制，事物總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素。

Eureka

服務註冊和發現是什麼意思？Spring Cloud 如何實現？

• 當咱們開始一個項目時，咱們一般在屬性文件中進行全部的配置。隨着愈來愈多的服務開發和部署，添加和修改這些屬性變得更加複雜。有些服務可能會降低，而某些位置可能會發生變化。手動更改屬性可能會產生問題。 Eureka 服務註冊和發現能夠在這種狀況下提供幫助。因爲全部服務都在 Eureka 服務器上註冊並經過調用 Eureka 服務器完成查找，所以無需處理服務地點的任何更改和處理。

什麼是Eureka

• Eureka做爲SpringCloud的服務註冊功能服務器，他是服務註冊中心，系統中的其餘服務使用Eureka的客戶端將其鏈接到Eureka Service中，而且保持心跳，這樣工做人員能夠經過Eureka Service來監控各個微服務是否運行正常。

Eureka怎麼實現高可用

• 集羣吧，註冊多臺Eureka，而後把SpringCloud服務互相註冊，客戶端從Eureka獲取信息時，按照Eureka的順序來訪問。

什麼是Eureka的自我保護模式，

• 默認狀況下，若是Eureka Service在必定時間內沒有接收到某個微服務的心跳，Eureka Service會進入自我保護模式，在該模式下Eureka Service會保護服務註冊表中的信息，不在刪除註冊表中的數據，當網絡故障恢復後，Eureka Servic 節點會自動退出自我保護模式

DiscoveryClient的做用

• 能夠從註冊中心中根據服務別名獲取註冊的服務器信息。

Eureka和ZooKeeper均可以提供服務註冊與發現的功能,請說說兩個的區別

一、 ZooKeeper中的節點服務掛了就要選舉 在選舉期間註冊服務癱瘓,雖然服務最終會恢復,可是選舉期間不可用的， 選舉就是改微服務作了集羣，必須有一臺主其餘的都是從
二、 Eureka各個節點是平等關係,服務器掛了不要緊，只要有一臺Eureka就能夠保證服務可用，數據都是最新的。 若是查詢到的數據並非最新的，就是由於Eureka的自我保護模式致使的
三、 Eureka本質上是一個工程,而ZooKeeper只是一個進程
四、 Eureka能夠很好的應對因網絡故障致使部分節點失去聯繫的狀況,而不會像ZooKeeper 同樣使得整個註冊系統癱瘓
五、 ZooKeeper保證的是CP，Eureka保證的是AP

CAP： C：一致性>Consistency; 取捨：(強一致性、單調一致性、會話一致性、最終一致性、弱一致性) A：可用性>Availability; P：分區容錯性>Partition tolerance;

Zuul

什麼是網關?

• 網關至關於一個網絡服務架構的入口，全部網絡請求必須經過網關轉發到具體的服務。

網關的做用是什麼

• 統一管理微服務請求，權限控制、負載均衡、路由轉發、監控、安全控制黑名單和白名單等

什麼是Spring Cloud Zuul（服務網關）

• Zuul是對SpringCloud提供的成熟對的路由方案，他會根據請求的路徑不一樣，網關會定位到指定的微服務，並代理請求到不一樣的微服務接口，他對外隱蔽了微服務的真正接口地址。 三個重要概念：動態路由表，路由定位，反向代理：

  *  動態路由表：Zuul支持Eureka路由，手動配置路由，這倆種都支持自動更新
  *  路由定位：根據請求路徑，Zuul有本身的一套定位服務規則以及路由表達式匹配
  *  反向代理：客戶端請求到路由網關，網關受理以後，在對目標發送請求，拿到響應以後在 給客戶端

• 它能夠和Eureka,Ribbon,Hystrix等組件配合使用，

• Zuul的應用場景：

  *  對外暴露，權限校驗，服務聚合，日誌審計等

網關與過濾器有什麼區別

• 網關是對全部服務的請求進行分析過濾，過濾器是對單個服務而言。

經常使用網關框架有那些？

• Nginx、Zuul、Gateway

Zuul與Nginx有什麼區別？

• Zuul是java語言實現的，主要爲java服務提供網關服務，尤爲在微服務架構中能夠更加靈活的對網關進行操做。Nginx是使用C語言實現，性能高於Zuul，可是實現自定義操做須要熟悉lua語言，對程序員要求較高，可使用Nginx作Zuul集羣。

既然Nginx能夠實現網關？爲何還須要使用Zuul框架

• Zuul是SpringCloud集成的網關，使用Java語言編寫，能夠對SpringCloud架構提供更靈活的服務。

如何設計一套API接口

• 考慮到API接口的分類能夠將API接口分爲開發API接口和內網API接口，內網API接口用於局域網，爲內部服務器提供服務。開放API接口用於對外部合做單位提供接口調用，須要遵循Oauth2.0權限認證協議。同時還須要考慮安全性、冪等性等問題。

ZuulFilter經常使用有那些方法

• Run()：過濾器的具體業務邏輯
• shouldFilter()：判斷過濾器是否有效
• filterOrder()：過濾器執行順序
• filterType()：過濾器攔截位置

如何實現動態Zuul網關路由轉發

• 經過path配置攔截請求，經過ServiceId到配置中心獲取轉發的服務列表，Zuul內部使用Ribbon實現本地負載均衡和轉發。

Zuul網關如何搭建集羣

• 使用Nginx的upstream設置Zuul服務集羣，經過location攔截請求並轉發到upstream，默認使用輪詢機制對Zuul集羣發送請求。

Ribbon

負載平衡的意義什麼？

• 簡單來講： 先將集羣，集羣就是把一個的事情交給多我的去作，假如要作1000個產品給一我的作要10天，我叫10我的作就是一天，這就是集羣，負載均衡的話就是用來控制集羣，他把作的最多的人讓他慢慢作休息會，把作的最少的人讓他加量讓他作多點。
• 在計算中，負載平衡能夠改善跨計算機，計算機集羣，網絡連接，中央處理單元或磁盤驅動器等多種計算資源的工做負載分佈。負載平衡旨在優化資源使用，最大化吞吐量，最小化響應時間並避免任何單一資源的過載。使用多個組件進行負載平衡而不是單個組件可能會經過冗餘來提升可靠性和可用性。負載平衡一般涉及專用軟件或硬件，例如多層交換機或域名系統服務器進程。

Ribbon是什麼？

• Ribbon是Netflix發佈的開源項目，主要功能是提供客戶端的軟件負載均衡算法
• Ribbon客戶端組件提供一系列完善的配置項，如鏈接超時，重試等。簡單的說，就是在配置文件中列出後面全部的機器，Ribbon會自動的幫助你基於某種規則（如簡單輪詢，隨即鏈接等）去鏈接這些機器。咱們也很容易使用Ribbon實現自定義的負載均衡算法。（有點相似Nginx）

Nginx與Ribbon的區別

• Nginx是反向代理同時能夠實現負載均衡，nginx攔截客戶端請求採用負載均衡策略根據upstream配置進行轉發，至關於請求經過nginx服務器進行轉發。Ribbon是客戶端負載均衡，從註冊中心讀取目標服務器信息，而後客戶端採用輪詢策略對服務直接訪問，全程在客戶端操做。

Ribbon底層實現原理

• Ribbon使用discoveryClient從註冊中心讀取目標服務信息，對同一接口請求進行計數，使用%取餘算法獲取目標服務集羣索引，返回獲取到的目標服務信息。

@LoadBalanced註解的做用

開啓客戶端負載均衡。

Hystrix

什麼是斷路器

• 當一個服務調用另外一個服務因爲網絡緣由或自身緣由出現問題，調用者就會等待被調用者的響應 當更多的服務請求到這些資源致使更多的請求等待，發生連鎖效應（雪崩效應）

• 斷路器有三種狀態

  *  打開狀態：一段時間內 達到必定的次數沒法調用 而且屢次監測沒有恢復的跡象 斷路器徹底打開 那麼下次請求就不會請求到該服務
  *  半開狀態：短期內 有恢復跡象 斷路器會將部分請求發給該服務，正常調用時 斷路器關閉
  *  關閉狀態：當服務一直處於正常狀態 能正常調用

什麼是 Hystrix？

• 在分佈式系統，咱們必定會依賴各類服務，那麼這些個服務必定會出現失敗的狀況，就會致使雪崩，Hystrix就是這樣的一個工具，防雪崩利器，它具備服務降級，服務熔斷，服務隔離，監控等一些防止雪崩的技術。

• Hystrix有四種防雪崩方式:

  *  服務降級：接口調用失敗就調用本地的方法返回一個空
  *  服務熔斷：接口調用失敗就會進入調用接口提早定義好的一個熔斷的方法，返回錯誤信息
  *  服務隔離：隔離服務之間相互影響
  *  服務監控：在服務發生調用時,會將每秒請求數、成功請求數等運行指標記錄下來。

談談服務雪崩效應

• 雪崩效應是在大型互聯網項目中，當某個服務發生宕機時，調用這個服務的其餘服務也會發生宕機，大型項目的微服務之間的調用是互通的，這樣就會將服務的不可用逐步擴大到各個其餘服務中，從而使整個項目的服務宕機崩潰.發生雪崩效應的緣由有如下幾點
• 單個服務的代碼存在bug. 2請求訪問量激增致使服務發生崩潰(如大型商城的槍紅包，秒殺功能). 3.服務器的硬件故障也會致使部分服務不可用.

在微服務中，如何保護服務?

• 通常使用使用Hystrix框架，實現服務隔離來避免出現服務的雪崩效應，從而達到保護服務的效果。當微服務中，高併發的數據庫訪問量致使服務線程阻塞，使單個服務宕機，服務的不可用會蔓延到其餘服務，引發總體服務災難性後果，使用服務降級能有效爲不一樣的服務分配資源,一旦服務不可用則返回友好提示，不佔用其餘服務資源，從而避免單個服務崩潰引起總體服務的不可用.

服務雪崩效應產生的緣由

• 由於Tomcat默認狀況下只有一個線程池來維護客戶端發送的全部的請求，這時候某一接口在某一時刻被大量訪問就會佔據tomcat線程池中的全部線程，其餘請求處於等待狀態，沒法鏈接到服務接口。

談談服務降級、熔斷、服務隔離

• 服務降級：當客戶端請求服務器端的時候，防止客戶端一直等待，不會處理業務邏輯代碼，直接返回一個友好的提示給客戶端。
• 服務熔斷是在服務降級的基礎上更直接的一種保護方式，當在一個統計時間範圍內的請求失敗數量達到設定值（requestVolumeThreshold）或當前的請求錯誤率達到設定的錯誤率閾值（errorThresholdPercentage）時開啓斷路，以後的請求直接走fallback方法，在設定時間（sleepWindowInMilliseconds）後嘗試恢復。
• 服務隔離就是Hystrix爲隔離的服務開啓一個獨立的線程池，這樣在高併發的狀況下不會影響其餘服務。服務隔離有線程池和信號量兩種實現方式，通常使用線程池方式。

服務降級底層是如何實現的？

• Hystrix實現服務降級的功能是經過重寫HystrixCommand中的getFallback()方法，當Hystrix的run方法或construct執行發生錯誤時轉而執行getFallback()方法。

其餘答案已經在公衆號更新

關注公衆號：搜雲庫技術團隊，回覆：面試題，便可獲取所有