開篇介紹

大家好，我是Java最全面試題庫的提褲姐，今天這篇是JavaEE面試題系列的第十篇，主要總結了springCloud相關的面試題；在后續(xù)，會沿著第一篇開篇的知識線路一直總結下去，做到日更！如果我能做到百日百更，希望你也可以跟著百日百刷，一百天養(yǎng)成一個好習慣。

什么是微服務？

微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程序劃分為一組小的服務，每個服務運行在其獨立的自己的進程中，服務之間相互協(xié)調、互相配合，為用戶提供最終價值。服務之間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTful API），每個服務都圍繞著具體的業(yè)務進行構建，并且能夠被獨立的構建在生產環(huán)境、類生產環(huán)境等。另外，應避免統(tǒng)一的、集中式的服務管理機制，對具體的一個服務而言，應根據業(yè)務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協(xié)調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。

Spring Cloud由哪些組件組成？

• Eureka：服務注冊與發(fā)現(xiàn)
• Zuul：服務網關
• Ribbon：客戶端負載均衡
• Feign：聲明性的Web服務客戶端
• Hystrix：斷路器
• Config：分布式統(tǒng)一配置管理
• 等20幾個框架，開源一直在更新

0e9c7b73ca58fcbd7ee8f5b7c3fe450.png

Spring Cloud和 dubbo區(qū)別?

服務調用方式：

• dubbo是 RPC
• springcloud 是Rest Api

注冊中心：

• dubbo是 zookeeper；
• springcloud是 eureka，也可以是 zookeeper

服務網關：

• dubbo本身沒有實現(xiàn)，只能通過其他第三方技術整合；
• springcloud有Zuul路由網關，作為路由服務器，進行消費者的請求分發(fā)；springcloud支持斷路器，與git完美集成配置文件支持版本控制，事物總線實現(xiàn)配置文件的更新與服務自動裝配等等一系列的微服務架構要素。

Eureka的工作原理？

Eureka：服務注冊中心（可以是一個集群），對外暴露自己的地址
提供者：啟動后向Eureka注冊自己信息（地址，提供什么服務）
消費者：向Eureka訂閱服務，Eureka會將對應服務的所有提供者地址列表發(fā)送給消費者，并且定期更新
心跳(續(xù)約)：提供者定期通過http方式向Eureka刷新自己的狀態(tài)（每30s定時向EurekaServer發(fā)起請求）

說說Eureka的自我保護機制？

當一個服務未按時進行心跳續(xù)約時，在生產環(huán)境下，因為網絡延遲等原因，此時就把服務剔除列表并不妥當，因為服務可能沒有宕機。 Eureka就會把當前實例的注冊信息保護起來，不予剔除。生產環(huán)境下這很有效，保證了大多數服務依然可用。但是有可能會造成一些掛掉的服務被剔除有延遲。

Eureka和ZooKeeper的區(qū)別？

1、ZooKeeper中的節(jié)點服務掛了就要選舉，在選舉期間注冊服務癱瘓，雖然服務最終會恢復，但是選舉期間不可用的， 選舉就是改微服務做了集群，必須有一臺主其他的都是從。
2、Eureka各個節(jié)點是平等關系，服務器掛了沒關系，只要有一臺Eureka就可以保證服務可用，數據都是最新的。 如果查詢到的數據并不是最新的，就是因為Eureka的自我保護模式導致的。
3、Eureka本質上是一個工程，而ZooKeeper只是一個進程。
4、Eureka可以很好的應對因網絡故障導致部分節(jié)點失去聯(lián)系的情況，而不會像ZooKeeper 一樣使得整個注冊系統(tǒng)癱瘓。
5、ZooKeeper保證的是CP，Eureka保證的是AP

CAP解釋：
C：一致性Consistency （取舍:強一致性、單調一致性、會話一致性、最終一致性、弱一致性）
A：可用性 Availability
P：分區(qū)容錯性Partition tolerance

什么是zuul?

zuul是對SpringCloud提供的成熟對的路由方案，他會根據請求的路徑不同，網關會定位到指定的微服務，并代理請求到不同的微服務接口，他對外隱蔽了微服務的真正接口地址。
三個重要概念：

• 動態(tài)路由表：Zuul支持Eureka路由，手動配置路由，這倆種都支持自動更新
• 路由定位：根據請求路徑，Zuul有自己的一套定位服務規(guī)則以及路由表達式匹配
• 反向代理：客戶端請求到路由網關，網關受理之后，在對目標發(fā)送請求，拿到響應之后在 給客戶端

Zuul的應用場景： 對外暴露，權限校驗，服務聚合，日志審計等

zuul的工作流程?

在Spring Cloud Netflix中，Zuul巧妙的整合了Eureka來實現(xiàn)面向服務的路由。
實際上，API網關將自己注冊到Eureka服務注冊中心上，也會從注冊中心獲取所有服務以及它們的實例清單。在Eureka的幫助下，API網關已經維護了系統(tǒng)中所有serviceId與實例地址的映射關系。當有外部請求到達API網關的時候，根據請求的URL找到最匹配的path，API網關就可以知道要將該請求"路由"到哪個具體的serviceId上去。 最終通過Ribbon的負載均衡策略實現(xiàn)請求的路由。

什么是feign?

1.feign采用的是基于接口的注解
2.feign整合了ribbon，具有負載均衡的能力
3.整合了Hystrix，具有熔斷的能力

feign的工作流程？

1、通過動態(tài)代理生成實現(xiàn)類
2、根據接口類的注解生命規(guī)則，解析出底層的methodhandler
3、攔截器負責對請求和返回進行包裝和處理
4、通過均衡負載http去訪問遠程服務

什么是Hystrix？

在分布式系統(tǒng)，我們一定會依賴各種服務，那么這些個服務一定會出現(xiàn)失敗的情況，就會導致雪崩，Hystrix就是這樣的一個工具，防雪崩利器，它具有服務降級，服務熔斷，服務隔離，監(jiān)控等一些防止雪崩的技術。
Hystrix有四種防雪崩方式：

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

Hystrix流程?

1、構造一個 HystrixCommand或HystrixObservableCommand對象，用于封裝請求，并在構造方法配置請求被執(zhí)行需要的參數；
2、執(zhí)行命令，Hystrix提供了4種執(zhí)行命令的方法；
3、判斷是否使用緩存響應請求，若啟用了緩存，且緩存可用，直接使用緩存響應請求。Hystrix支持請求緩存，但需要用戶自定義啟動；
4、判斷熔斷器是否打開，如果打開，跳到第8步；
5、判斷線程池/隊列/信號量是否已滿，已滿則跳到第8步；
6、執(zhí)行HystrixObservableCommand.construct()或HystrixCommand.run()，如果執(zhí)行失敗或者超時，跳到第8步；否則，跳到第9步；
7、統(tǒng)計熔斷器監(jiān)控指標；
8、走Fallback備用邏輯
9、返回請求響應

什么是服務熔斷？什么是服務降級？

服務熔斷：
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。
當某個微服務不可用或者響應時間太長時，會進行服務降級，進而熔斷該節(jié)點微服務的調用，快速返回“錯誤”的響應信息。當檢測到該節(jié)點微服務調用響應正常后恢復調用鏈路。
在SpringCloud框架里熔斷機制通過Hystrix實現(xiàn)，Hystrix會監(jiān)控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內調用20次，如果失敗，就會啟動熔斷機制。
服務降級：
服務降級，一般是從整體負荷考慮。就是當某個服務熔斷之后，服務器將不再被調用，此時客戶端可以自己準備一個本地的fallback回調，返回一個缺省值。

什么是服務雪崩效應?

雪崩效應是在大型互聯(lián)網項目中，當某個服務發(fā)生宕機時，調用這個服務的其他服務也會發(fā)生宕機，大型項目的微服務之間的調用是互通的，這樣就會將服務的不可用逐步擴大到各個其他服務中，從而使整個項目的服務宕機崩潰。

Eureka怎么實現(xiàn)高可用？

集群：
注冊多臺 Eureka，把 SpringCloud服務互相注冊，客戶端從 Eureka獲取信息時，按照 Eureka的順序來訪問。

ZuulFilter常用有哪些方法？

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

如何實現(xiàn)動態(tài)Zuul網關路由轉發(fā)？

通過path配置攔截請求，通過 Serviceld到配置中心獲取轉發(fā)的服務列表，zuul內部使用 Ribbon實現(xiàn)本地負載均衡和轉發(fā)。

Zuul網關如何搭建集群？

使用Nginx的 upstream設置Zuul服務集群，通過location攔截請求并轉發(fā)到 upstream，默認使用輪詢機制對Zuul集群發(fā)送請求。

負載平衡的意義什么?

通俗易懂的理解：
集群：是把一個的事情交給多個人去做，假如要做1000個產品給一個人做要10天，叫10個人做就是一天；
負載均衡：用來控制集群，他把做的最多的人讓他慢慢做休息會，把做的最少的人讓他加量讓他做多點。

在計算中：
負載平衡可以改善跨計算機計算機集群，網絡鏈接，中央處理單元或磁盤驅動器等多種計算資源的工作負載分布，負載平衡旨在優(yōu)化資源使用，最大化吞吐量，最小化響應時間并避免任何單一資源的過載，使用多個組件進行負載平衡，而不是單個組件，可能會通過冗余來提高可靠性和可用性，負載平衡通常及專用軟件或硬件，例如多層交換機或域名系統(tǒng)服務器進程。

服務降級底層是如何實現(xiàn)的?

Hystrix實現(xiàn)服務降級的功能是通過重寫 HystrixCommand中的 getFallback()方法,當 Hystrix的run方法或 construct執(zhí)行發(fā)生誤時轉而執(zhí)行 getFallback()方法。

什么是 Spring Cloud Bus?

• Spring Cloud Bus就像個分布式執(zhí)行器，用于擴展的 Spring Boot應用程序的配置文件，但也可以用作應用程序之間的通信通道。
• Spring Cloud Bus不能單獨完成通信，需要配合MQ支持
• Spring Cloud Bus一般是配合Spring Cloud Config做配置中心的
• Spring Cloud config實時刷新也必須采用 SpringCloud Bus消息總線

Spring Cloud Bus 原理？

發(fā)送端（endpoint）構造事件event，將其publish到context上下文中（spring cloud bus有一個父上下文，bootstrap），然后將事件發(fā)送到channel中（json串message），接收端從channel中獲取到message，將message轉為事件event，然后將event事件publish到context上下文中，最后接收端（Listener）收到event，調用服務進行處理。
整個流程中，只有發(fā)送/接收端從context上下文中取事件和發(fā)送事件是需要我們在代碼中明確寫出來的，其它部分都由框架封裝完成。

SpringCloud Config可以實現(xiàn)實時刷新嗎?

springcloud config實時刷新采用 SpringCloud Bus消息總線

什么是服務熔斷？什么是服務降級？

熔斷機制：
是應對雪崩效應的一種微服務鏈路保護機制。
當某個微服務不可用或者響應時間太長時，會進行服務降級，進而熔斷該節(jié)點微服務的調用，快速返回“錯誤”的響應信息。當檢測到該節(jié)點微服務調用響應正常后恢復調用鏈路。
在SpringCloud框架里熔斷機制通過Hystrix實現(xiàn)，Hystrix會監(jiān)控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內調用20次，如果失敗，就會啟動熔斷機制。

服務降級：
一般是從整體負荷考慮。就是當某個服務熔斷之后，服務器將不再被調用，此時客戶端可以自己準備一個本地的fallback回調，返回一個缺省值

什么是服務雪崩效應

雪崩效應是在大型互聯(lián)網項目中，當某個服務發(fā)生宕機時，調用這個服務的其他服務也會發(fā)生宕機，大型項目的微服務之間的調用是互通的，這樣就會將服務的不可用逐步擴大到各個其他服務中，從而使整個項目的服務宕機崩潰