目錄
一、什么微服務？
二、微服務優缺點
三、場景啟動器的工作原理是什么？
四、Spring Boot 的自動配置是如何實現的？
五、Eureka的工作原理
六、Ribbon的負載均衡原理
七、Ribbon的負載均衡算法
八、Hystrix斷路器工作原理
九、Hystrix的核心功能

一、什么微服務？

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

二、微服務優缺點
優點：

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

1.運維要求較高；
2.分布式的復雜性；
3.接口調整成本高；

三、場景啟動器的工作原理是什么？

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

四、Spring Boot 的自動配置是如何實現的？

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

五、Eureka的工作原理

Eureka包含兩個組件：Eureka Server和Eureka Client。在Eureka Client啟動的時候，將自身的服務的信息發送到Eureka Server，同時也會從Eureka Server下載服務注冊信息保存到Eureka Client緩存中。當服務間相互調用其它服務時，在Eureka Client中獲取服務信息（如服務地址，端口等）后，實現服務之間的交互。

六、Ribbon的負載均衡原理

簡單的說，就是在配置文件中列出Load Balancer（簡稱LB）后面所有的機器，Ribbon會自動的幫助你基于某種規則（如簡單輪詢，隨機連接等）去連接這些機器。我們也很容易使用Ribbon實現自定義的負載均衡算法,將請求平攤的分配到多個服務上，從而達到系統的高可用。

七、Ribbon的負載均衡算法

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

八、Hystrix斷路器工作原理

1、 當滿足一定的閥值時候 （默認 10 秒內 超過 20 個請求 次數 ）
2、 當失敗率達到一定的時候（ 默認 10 秒內超過 秒內超過 50%的請求失敗 ）
3、 到達以上閥值 ，斷路器將會開啟
4、 當開啟的時候 ，所有請求都不會進行轉發
5、 一段時間之后（ 默認是 5秒），這個時候斷路器是半開狀態， 會讓其中一請求進行轉發。如果成功斷路器會關閉，若失敗繼續開啟。重復 4和 5。

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。