開篇介紹
大家好，我是Java最全面試題庫的提褲姐，今天這篇是JavaEE面試題系列的第十篇，主要總結(jié)了springCloud相關(guān)的面試題珊肃；在后續(xù)，會沿著第一篇開篇的知識線路一直總結(jié)下去馅笙，做到日更伦乔！如果我能做到百日百更，希望你也可以跟著百日百刷董习，一百天養(yǎng)成一個好習(xí)慣烈和。
什么是微服務(wù)？
微服務(wù)架構(gòu)是一種架構(gòu)模式或者說是一種架構(gòu)風(fēng)格阱飘，它提倡將單一應(yīng)用程序劃分為一組小的服務(wù)斥杜，每個服務(wù)運行在其獨立的自己的進程中，服務(wù)之間相互協(xié)調(diào)沥匈、互相配合蔗喂，為用戶提供最終價值。服務(wù)之間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTful API）高帖，每個服務(wù)都圍繞著具體的業(yè)務(wù)進行構(gòu)建缰儿，并且能夠被獨立的構(gòu)建在生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等散址。另外乖阵，應(yīng)避免統(tǒng)一的、集中式的服務(wù)管理機制预麸，對具體的一個服務(wù)而言瞪浸，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言吏祸、工具對其進行構(gòu)建对蒲，可以有一個非常輕量級的集中式管理來協(xié)調(diào)這些服務(wù)，可以使用不同的語言來編寫服務(wù)，也可以使用不同的數(shù)據(jù)存儲蹈矮。
Spring Cloud由哪些組件組成砰逻？
-
Eureka：服務(wù)注冊與發(fā)現(xiàn) -
Zuul：服務(wù)網(wǎng)關(guān) -
Ribbon：客戶端負載均衡 -
Feign：聲明性的Web服務(wù)客戶端 -
Hystrix：斷路器 -
Config：分布式統(tǒng)一配置管理 - 等20幾個框架，開源一直在更新
Spring Cloud和 dubbo區(qū)別?
服務(wù)調(diào)用方式：
- dubbo是 RPC
- springcloud 是Rest Api
注冊中心：
- dubbo是 zookeeper泛鸟；
- springcloud是 eureka蝠咆，也可以是 zookeeper
服務(wù)網(wǎng)關(guān)：
- dubbo本身沒有實現(xiàn)，只能通過其他第三方技術(shù)整合北滥；
- springcloud有Zuul路由網(wǎng)關(guān)刚操，作為路由服務(wù)器，進行消費者的請求分發(fā)碑韵；springcloud支持斷路器赡茸，與git完美集成配置文件支持版本控制缎脾，事物總線實現(xiàn)配置文件的更新與服務(wù)自動裝配等等一系列的微服務(wù)架構(gòu)要素祝闻。
Eureka的工作原理？
Eureka：服務(wù)注冊中心（可以是一個集群）遗菠，對外暴露自己的地址
提供者：啟動后向Eureka注冊自己信息（地址联喘，提供什么服務(wù)）
消費者：向Eureka訂閱服務(wù)，Eureka會將對應(yīng)服務(wù)的所有提供者地址列表發(fā)送給消費者辙纬，并且定期更新
心跳(續(xù)約)：提供者定期通過http方式向Eureka刷新自己的狀態(tài)（每30s定時向EurekaServer發(fā)起請求）
說說Eureka的自我保護機制豁遭？
當(dāng)一個服務(wù)未按時進行心跳續(xù)約時，在生產(chǎn)環(huán)境下贺拣，因為網(wǎng)絡(luò)延遲等原因蓖谢，此時就把服務(wù)剔除列表并不妥當(dāng)，因為服務(wù)可能沒有宕機譬涡。 Eureka就會把當(dāng)前實例的注冊信息保護起來闪幽，不予剔除。生產(chǎn)環(huán)境下這很有效涡匀，保證了大多數(shù)服務(wù)依然可用盯腌。但是有可能會造成一些掛掉的服務(wù)被剔除有延遲。
Eureka和ZooKeeper的區(qū)別陨瘩？
1腕够、ZooKeeper中的節(jié)點服務(wù)掛了就要選舉，在選舉期間注冊服務(wù)癱瘓舌劳，雖然服務(wù)最終會恢復(fù)帚湘，但是選舉期間不可用的， 選舉就是改微服務(wù)做了集群甚淡，必須有一臺主其他的都是從大诸。
2、Eureka各個節(jié)點是平等關(guān)系，服務(wù)器掛了沒關(guān)系底挫，只要有一臺Eureka就可以保證服務(wù)可用恒傻，數(shù)據(jù)都是最新的。 如果查詢到的數(shù)據(jù)并不是最新的建邓，就是因為Eureka的自我保護模式導(dǎo)致的盈厘。
3、Eureka本質(zhì)上是一個工程官边，而ZooKeeper只是一個進程沸手。
4、Eureka可以很好的應(yīng)對因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點失去聯(lián)系的情況注簿，而不會像ZooKeeper 一樣使得整個注冊系統(tǒng)癱瘓契吉。
5、ZooKeeper保證的是CP诡渴，Eureka保證的是AP
CAP解釋：
C：一致性Consistency （取舍:強一致性捐晶、單調(diào)一致性、會話一致性妄辩、最終一致性惑灵、弱一致性）
A：可用性 Availability
P：分區(qū)容錯性Partition tolerance
什么是zuul?
zuul是對SpringCloud提供的成熟對的路由方案，他會根據(jù)請求的路徑不同眼耀，網(wǎng)關(guān)會定位到指定的微服務(wù)英支，并代理請求到不同的微服務(wù)接口，他對外隱蔽了微服務(wù)的真正接口地址哮伟。
三個重要概念：
-
動態(tài)路由表：Zuul支持Eureka路由干花，手動配置路由，這倆種都支持自動更新 -
路由定位：根據(jù)請求路徑楞黄，Zuul有自己的一套定位服務(wù)規(guī)則以及路由表達式匹配 -
反向代理：客戶端請求到路由網(wǎng)關(guān)池凄，網(wǎng)關(guān)受理之后，在對目標(biāo)發(fā)送請求谅辣，拿到響應(yīng)之后在 給客戶端
Zuul的應(yīng)用場景： 對外暴露修赞，權(quán)限校驗，服務(wù)聚合桑阶，日志審計等
zuul的工作流程?
在Spring Cloud Netflix中柏副，Zuul巧妙的整合了Eureka來實現(xiàn)面向服務(wù)的路由。
實際上蚣录，API網(wǎng)關(guān)將自己注冊到Eureka服務(wù)注冊中心上割择，也會從注冊中心獲取所有服務(wù)以及它們的實例清單。在Eureka的幫助下萎河，API網(wǎng)關(guān)已經(jīng)維護了系統(tǒng)中所有serviceId與實例地址的映射關(guān)系荔泳。當(dāng)有外部請求到達API網(wǎng)關(guān)的時候蕉饼，根據(jù)請求的URL找到最匹配的path，API網(wǎng)關(guān)就可以知道要將該請求"路由"到哪個具體的serviceId上去玛歌。 最終通過Ribbon的負載均衡策略實現(xiàn)請求的路由昧港。
什么是feign?
1.feign采用的是基于接口的注解
2.feign整合了ribbon，具有負載均衡的能力
3.整合了Hystrix支子，具有熔斷的能力
feign的工作流程创肥？
1、通過動態(tài)代理生成實現(xiàn)類
2值朋、根據(jù)接口類的注解生命規(guī)則叹侄，解析出底層的methodhandler
3、攔截器負責(zé)對請求和返回進行包裝和處理
4昨登、通過均衡負載http去訪問遠程服務(wù)
什么是Hystrix趾代？
在分布式系統(tǒng)，我們一定會依賴各種服務(wù)丰辣，那么這些個服務(wù)一定會出現(xiàn)失敗的情況撒强，就會導(dǎo)致雪崩，Hystrix就是這樣的一個工具糯俗，防雪崩利器尿褪，它具有服務(wù)降級睦擂，服務(wù)熔斷得湘，服務(wù)隔離，監(jiān)控等一些防止雪崩的技術(shù)顿仇。
Hystrix有四種防雪崩方式：
-
服務(wù)降級：接口調(diào)用失敗就調(diào)用本地的方法返回一個空 -
服務(wù)熔斷：接口調(diào)用失敗就會進入調(diào)用接口提前定義好的一個熔斷的方法淘正，返回錯誤信息 -
服務(wù)隔離：隔離服務(wù)之間相互影響 -
服務(wù)監(jiān)控：在服務(wù)發(fā)生調(diào)用時,會將每秒請求數(shù)、成功請求數(shù)等運行指標(biāo)記錄下來臼闻。
Hystrix流程?
1鸿吆、構(gòu)造一個 HystrixCommand或HystrixObservableCommand對象，用于封裝請求述呐，并在構(gòu)造方法配置請求被執(zhí)行需要的參數(shù)惩淳；
2、執(zhí)行命令乓搬，Hystrix提供了4種執(zhí)行命令的方法思犁；
3、判斷是否使用緩存響應(yīng)請求进肯，若啟用了緩存激蹲，且緩存可用，直接使用緩存響應(yīng)請求江掩。Hystrix支持請求緩存学辱，但需要用戶自定義啟動乘瓤；
4、判斷熔斷器是否打開策泣，如果打開衙傀，跳到第8步；
5萨咕、判斷線程池/隊列/信號量是否已滿差油，已滿則跳到第8步；
6任洞、執(zhí)行HystrixObservableCommand.construct()或HystrixCommand.run()蓄喇，如果執(zhí)行失敗或者超時，跳到第8步交掏；否則妆偏，跳到第9步；
7盅弛、統(tǒng)計熔斷器監(jiān)控指標(biāo)钱骂；
8、走Fallback備用邏輯
9挪鹏、返回請求響應(yīng)
什么是服務(wù)熔斷见秽？什么是服務(wù)降級？
服務(wù)熔斷：
熔斷機制是應(yīng)對雪崩效應(yīng)的一種微服務(wù)鏈路保護機制讨盒。
當(dāng)某個微服務(wù)不可用或者響應(yīng)時間太長時解取，會進行服務(wù)降級，進而熔斷該節(jié)點微服務(wù)的調(diào)用返顺，快速返回“錯誤”的響應(yīng)信息禀苦。當(dāng)檢測到該節(jié)點微服務(wù)調(diào)用響應(yīng)正常后恢復(fù)調(diào)用鏈路。
在SpringCloud框架里熔斷機制通過Hystrix實現(xiàn)遂鹊，Hystrix會監(jiān)控微服務(wù)間調(diào)用的狀況振乏，當(dāng)失敗的調(diào)用到一定閾值，缺省是5秒內(nèi)調(diào)用20次秉扑，如果失敗慧邮，就會啟動熔斷機制。
服務(wù)降級：
服務(wù)降級舟陆，一般是從整體負荷考慮误澳。就是當(dāng)某個服務(wù)熔斷之后，服務(wù)器將不再被調(diào)用吨娜，此時客戶端可以自己準(zhǔn)備一個本地的fallback回調(diào)脓匿，返回一個缺省值。
什么是服務(wù)雪崩效應(yīng)?
雪崩效應(yīng)是在大型互聯(lián)網(wǎng)項目中宦赠，當(dāng)某個服務(wù)發(fā)生宕機時陪毡，調(diào)用這個服務(wù)的其他服務(wù)也會發(fā)生宕機米母，大型項目的微服務(wù)之間的調(diào)用是互通的，這樣就會將服務(wù)的不可用逐步擴大到各個其他服務(wù)中毡琉，從而使整個項目的服務(wù)宕機崩潰铁瞒。
Eureka怎么實現(xiàn)高可用？
集群：
注冊多臺 Eureka桅滋，把 SpringCloud服務(wù)互相注冊慧耍，客戶端從 Eureka獲取信息時，按照 Eureka的順序來訪問丐谋。
ZuulFilter常用有哪些方法芍碧？
-
Run()：過濾器的具體業(yè)務(wù)邏輯 -
shouldFilter()：判斷過濾器是否有效 -
filterOrder()：過濾器執(zhí)行順序 -
filterType()：過濾器攔截位置
如何實現(xiàn)動態(tài)Zuul網(wǎng)關(guān)路由轉(zhuǎn)發(fā)？
通過path配置攔截請求号俐，通過 Serviceld到配置中心獲取轉(zhuǎn)發(fā)的服務(wù)列表泌豆，zuul內(nèi)部使用 Ribbon實現(xiàn)本地負載均衡和轉(zhuǎn)發(fā)。
Zuul網(wǎng)關(guān)如何搭建集群吏饿？
使用Nginx的 upstream設(shè)置Zuul服務(wù)集群踪危，通過location攔截請求并轉(zhuǎn)發(fā)到 upstream，默認使用輪詢機制對Zuul集群發(fā)送請求猪落。
負載平衡的意義什么?
通俗易懂的理解：
集群：是把一個的事情交給多個人去做贞远，假如要做1000個產(chǎn)品給一個人做要10天，叫10個人做就是一天笨忌；
負載均衡：用來控制集群蓝仲，他把做的最多的人讓他慢慢做休息會，把做的最少的人讓他加量讓他做多點蜜唾。
在計算中：
負載平衡可以改善跨計算機計算機集群杂曲，網(wǎng)絡(luò)鏈接，中央處理單元或磁盤驅(qū)動器等多種計算資源的工作負載分布袁余，負載平衡旨在優(yōu)化資源使用，最大化吞吐量咱揍，最小化響應(yīng)時間并避免任何單一資源的過載颖榜，使用多個組件進行負載平衡，而不是單個組件煤裙，可能會通過冗余來提高可靠性和可用性掩完，負載平衡通常及專用軟件或硬件，例如多層交換機或域名系統(tǒng)服務(wù)器進程硼砰。
服務(wù)降級底層是如何實現(xiàn)的?
Hystrix實現(xiàn)服務(wù)降級的功能是通過重寫 HystrixCommand中的 getFallback()方法,當(dāng) Hystrix的run方法或 construct執(zhí)行發(fā)生誤時轉(zhuǎn)而執(zhí)行 getFallback()方法且蓬。
什么是 Spring Cloud Bus?
- Spring Cloud Bus就像個分布式執(zhí)行器，用于擴展的 Spring Boot應(yīng)用程序的配置文件题翰，但也可以用作應(yīng)用程序之間的通信通道恶阴。
- Spring Cloud Bus不能單獨完成通信诈胜，需要配合MQ支持
- Spring Cloud Bus一般是配合Spring Cloud Config做配置中心的
- Spring Cloud config實時刷新也必須采用 SpringCloud Bus消息總線
Spring Cloud Bus 原理？
發(fā)送端（endpoint）構(gòu)造事件event冯事，將其publish到context上下文中（spring cloud bus有一個父上下文焦匈，bootstrap），然后將事件發(fā)送到channel中（json串message）昵仅，接收端從channel中獲取到message缓熟，將message轉(zhuǎn)為事件event，然后將event事件publish到context上下文中摔笤，最后接收端（Listener）收到event够滑，調(diào)用服務(wù)進行處理。
整個流程中吕世，只有發(fā)送/接收端從context上下文中取事件和發(fā)送事件是需要我們在代碼中明確寫出來的版述，其它部分都由框架封裝完成。
SpringCloud Config可以實現(xiàn)實時刷新嗎?
springcloud config實時刷新采用 SpringCloud Bus消息總線
什么是服務(wù)熔斷寞冯？什么是服務(wù)降級渴析？
熔斷機制：
是應(yīng)對雪崩效應(yīng)的一種微服務(wù)鏈路保護機制。
當(dāng)某個微服務(wù)不可用或者響應(yīng)時間太長時吮龄，會進行服務(wù)降級俭茧，進而熔斷該節(jié)點微服務(wù)的調(diào)用，快速返回“錯誤”的響應(yīng)信息漓帚。當(dāng)檢測到該節(jié)點微服務(wù)調(diào)用響應(yīng)正常后恢復(fù)調(diào)用鏈路母债。
在SpringCloud框架里熔斷機制通過Hystrix實現(xiàn)，Hystrix會監(jiān)控微服務(wù)間調(diào)用的狀況尝抖，當(dāng)失敗的調(diào)用到一定閾值毡们，缺省是5秒內(nèi)調(diào)用20次，如果失敗昧辽，就會啟動熔斷機制衙熔。
服務(wù)降級：
一般是從整體負荷考慮。就是當(dāng)某個服務(wù)熔斷之后搅荞，服務(wù)器將不再被調(diào)用红氯，此時客戶端可以自己準(zhǔn)備一個本地的fallback回調(diào)，返回一個缺省值
什么是服務(wù)雪崩效應(yīng)
雪崩效應(yīng)是在大型互聯(lián)網(wǎng)項目中咕痛，當(dāng)某個服務(wù)發(fā)生宕機時痢甘，調(diào)用這個服務(wù)的其他服務(wù)也會發(fā)生宕機，大型項目的微服務(wù)之間的調(diào)用是互通的茉贡，這樣就會將服務(wù)的不可用逐步擴大到各個其他服務(wù)中塞栅，從而使整個項目的服務(wù)宕機崩潰
