目錄
一、什么微服務(wù)？
二、微服務(wù)優(yōu)缺點(diǎn)
三、場景啟動(dòng)器的工作原理是什么？
四、Spring Boot 的自動(dòng)配置是如何實(shí)現(xiàn)的？
五、Eureka的工作原理
六、Ribbon的負(fù)載均衡原理
七、Ribbon的負(fù)載均衡算法
八、Hystrix斷路器工作原理
九、Hystrix的核心功能

一、什么微服務(wù)？

微服務(wù)是一種將單個(gè)應(yīng)用程序開發(fā)為一組小服務(wù)的方法，每個(gè)服務(wù)都在自己的進(jìn)程中運(yùn)行，并通過輕量級機(jī)制（通常是HTTP資源API）進(jìn)行服務(wù)之間交互。這些服務(wù)基于業(yè)務(wù)能力構(gòu)建的，可以通過全自動(dòng)部署機(jī)制獨(dú)立部署。通常情況下我們很少去集中化去管理這些服務(wù)，而且這些服務(wù)可以用不同的編程語言編寫，并使用不同的數(shù)據(jù)存儲技術(shù)。

二、微服務(wù)優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：

1.每個(gè)微服務(wù)都很小，這樣能聚焦一個(gè)指定的業(yè)務(wù)功能或業(yè)務(wù)需求；
2.微服務(wù)能夠被小團(tuán)隊(duì)單獨(dú)開發(fā)；
3.微服務(wù)是松耦合的，是有功能意義的服務(wù)，無論是在開發(fā)階段或部署階段都是獨(dú)立的；
4.微服務(wù)能使用不同的語言開發(fā)；
5.微服務(wù)易于被一個(gè)開發(fā)人員理解，修改和維護(hù)，這樣小團(tuán)隊(duì)能夠更關(guān)注自己的工作成果，無需通過合作才能體現(xiàn)價(jià)值；
6.微服務(wù)只是業(yè)務(wù)邏輯的代碼，不會(huì)和HTML,CSS 或其他界面組件混合；
缺點(diǎn)：

1.運(yùn)維要求較高；
2.分布式的復(fù)雜性；
3.接口調(diào)整成本高；

三、場景啟動(dòng)器的工作原理是什么？

其實(shí)就是 Spring Boot 在啟動(dòng)的時(shí)候，按照約定去讀取 Spring Boot Starter 的配置信息，再根據(jù)配置信息對資源進(jìn)行初始化，并注入到 Spring 容器中。這樣 Spring Boot 啟動(dòng)完畢后，就已經(jīng)準(zhǔn)備好了一切資源，使用過程中直接注入對應(yīng) Bean 資源即可。

四、Spring Boot 的自動(dòng)配置是如何實(shí)現(xiàn)的？

主要是通過@SpringBootApplication下面的@EnableAutoConfiguration注解實(shí)現(xiàn)的，該注解通過 @Import 注解導(dǎo)入了AutoConfigurationImportSelector，然后在該類中加載 META-INF/spring.factories 的配置信息，最后篩選出以 EnableAutoConfiguration 為 key 的數(shù)據(jù)，加載到 IOC 容器中，實(shí)現(xiàn)自動(dòng)配置功能！

五、Eureka的工作原理

Eureka包含兩個(gè)組件：Eureka Server和Eureka Client。在Eureka Client啟動(dòng)的時(shí)候，將自身的服務(wù)的信息發(fā)送到Eureka Server，同時(shí)也會(huì)從Eureka Server下載服務(wù)注冊信息保存到Eureka Client緩存中。當(dāng)服務(wù)間相互調(diào)用其它服務(wù)時(shí)，在Eureka Client中獲取服務(wù)信息（如服務(wù)地址，端口等）后，實(shí)現(xiàn)服務(wù)之間的交互。

六、Ribbon的負(fù)載均衡原理

簡單的說，就是在配置文件中列出Load Balancer（簡稱LB）后面所有的機(jī)器，Ribbon會(huì)自動(dòng)的幫助你基于某種規(guī)則（如簡單輪詢，隨機(jī)連接等）去連接這些機(jī)器。我們也很容易使用Ribbon實(shí)現(xiàn)自定義的負(fù)載均衡算法,將請求平攤的分配到多個(gè)服務(wù)上，從而達(dá)到系統(tǒng)的高可用。

七、Ribbon的負(fù)載均衡算法

1.RoundRobinRule(輪詢算法)
2.RandomRule(隨機(jī)算法)
3.AvailabilityFilteringRule()：會(huì)先過濾由于多次訪問故障而處于斷路器跳閘狀態(tài)的服務(wù)，還有并發(fā)的連接數(shù)量超過閾值的服務(wù)，然后對剩余的服務(wù)列表按照輪詢策略進(jìn)行訪問；
4.WeightedResponseTimeRule()：根據(jù)平均響應(yīng)的時(shí)間計(jì)算所有服務(wù)的權(quán)重，響應(yīng)時(shí)間越快服務(wù)權(quán)重越大被選中的概率越高，剛啟動(dòng)時(shí)如果統(tǒng)計(jì)信息不足，則使用RoundRobinRule策略，等統(tǒng)計(jì)信息足夠會(huì)切換到WeightedResponseTimeRule；
5.RetryRule()：先按照RoundRobinRule的策略獲取服務(wù)，如果獲取失敗則在制定時(shí)間內(nèi)進(jìn)行重試，獲取可用的服務(wù)；
6.BestAviableRule()：會(huì)先過濾掉由于多次訪問故障而處于斷路器跳閘狀態(tài)的服務(wù)，然后選擇一個(gè)并發(fā)量最小的服務(wù)；
7.ZoneAvoidanceRule()：默認(rèn)規(guī)則，符合判斷server所在區(qū)域的性能和server的可用性選擇服務(wù)器；

八、Hystrix斷路器工作原理

1、 當(dāng)滿足一定的閥值時(shí)候 （默認(rèn) 10 秒內(nèi) 超過 20 個(gè)請求 次數(shù) ）
2、 當(dāng)失敗率達(dá)到一定的時(shí)候（ 默認(rèn) 10 秒內(nèi)超過 秒內(nèi)超過 50%的請求失敗 ）
3、 到達(dá)以上閥值 ，斷路器將會(huì)開啟
4、 當(dāng)開啟的時(shí)候 ，所有請求都不會(huì)進(jìn)行轉(zhuǎn)發(fā)
5、 一段時(shí)間之后（ 默認(rèn)是 5秒），這個(gè)時(shí)候斷路器是半開狀態(tài)， 會(huì)讓其中一請求進(jìn)行轉(zhuǎn)發(fā)。如果成功斷路器會(huì)關(guān)閉，若失敗繼續(xù)開啟。重復(fù) 4和 5。

九、Hystrix的核心功能 請求熔斷：

當(dāng)Hystrix Command請求后端服務(wù)失敗數(shù)量超過一定比例(默認(rèn)50%)，斷路器會(huì)切換到開路狀態(tài)(Open)。這時(shí)所有請求會(huì)直接失敗而不會(huì)發(fā)送到后端服務(wù)，斷路器保持在開路狀態(tài)一段時(shí)間后(默認(rèn)5秒)，自動(dòng)切換到半開路狀態(tài)(HALF-OPEN)，這時(shí)會(huì)判斷下一次請求的返回情況，如果請求成功，斷路器切回閉路狀態(tài)(CLOSED)，否則重新切換到開路狀態(tài)(OPEN). Hystrix的斷路器就像我們家庭電路中的保險(xiǎn)絲, 一旦后端服務(wù)不可用, 斷路器會(huì)直接切斷請求鏈，避免發(fā)送大量無效請求影響系統(tǒng)吞吐量，并且斷路器有自我檢測并恢復(fù)的能力。在此我向大家推薦一個(gè)架構(gòu)學(xué)習(xí)交流圈。交流學(xué)習(xí)指導(dǎo)偽鑫：1253431195（里面有大量的面試題及答案）里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化、分布式架構(gòu)等這些成為架構(gòu)師必備的知識體系。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多
服務(wù)降級：
Fallback相當(dāng)于是降級操作。對于查詢操作，我們可以實(shí)現(xiàn)一個(gè)fallback方法，當(dāng)請求后端服務(wù)出現(xiàn)異常的時(shí)候，可以使用fallback方法返回的值。fallback方法的返回值一般是設(shè)置的默認(rèn)值或者來自緩存，告知后面的請求服務(wù)不可用了不要再來了。依賴隔離(采用艙壁模式，Docker就是艙壁模式的一種)：
在Hystrix中主要通過線程池來實(shí)現(xiàn)資源隔離。通常在使用的時(shí)候我們會(huì)根據(jù)調(diào)用的遠(yuǎn)程服務(wù)劃分出多個(gè)線程池。比如說，一個(gè)服務(wù)調(diào)用另外兩個(gè)服務(wù)，你如果調(diào)用的兩個(gè)服務(wù)都用一個(gè)線程池，那么如果一個(gè)服務(wù)卡在哪里，資源沒被釋放后面的請求又來了，導(dǎo)致后面的請求都卡在哪里等待，導(dǎo)致你依賴的A服務(wù)把你卡在那里，耗盡了資源，也導(dǎo)致了你另外一個(gè)B服務(wù)也不可用了。這時(shí)如果依賴隔離，某一個(gè)服務(wù)調(diào)用A B兩個(gè)服務(wù)，如果這時(shí)我有100個(gè)線程可用，我給A服務(wù)分配50個(gè)，給B服務(wù)分配50個(gè)，這樣就算A服務(wù)掛了，我的B服務(wù)依然可以用。
請求緩存：
比如一個(gè)請求過來請求我userId=1的數(shù)據(jù)，你后面的請求也過來請求同樣的數(shù)據(jù)，這時(shí)我不會(huì)繼續(xù)走原來的那條請求鏈路了，而是把第一次請求緩存過了，把第一次的請求結(jié)果返回給后面的請求。請求合并：
比如說查數(shù)據(jù)庫的時(shí)候，我發(fā)了N條請求發(fā)了N條SQL然后拿到一堆結(jié)果，這時(shí)候我們可以把多個(gè)請求合并成一個(gè)請求，發(fā)送一個(gè)查詢多條數(shù)據(jù)的SQL的請求，這樣我們只需查詢一次數(shù)據(jù)庫，提升了效率。

總結(jié)

以上是生活随笔為你收集整理的Java微服务面试题及答案2022,微服务面试题2022的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。