20道你必須要背會的微服務面試題，面試一定會被問到

寫在前面： 我是「揚帆向海」，這個暱稱來源於我的名字以及女朋友的名字。我熱愛技術、熱愛開源、熱愛程式設計。技術是開源的、知識是共享的。

這部落格是對自己學習的一點點總結及記錄，如果您對 Java、演算法 感興趣，可以關注我的動態，我們一起學習。

用知識改變命運，讓我們的家人過上更好的生活。

在學習springcloud之前大家一定要先了解下，常見的面試題有那塊，然後我們帶著問題去學習這個微服務技術，那麼就會更加理解springcloud技術。如果你已經學了springcloud，那麼在準備面試的時候，一定要看看看這些面試題。

相關文章：

Springboot 系列文章

【Java基礎】易錯面試題，初級程式設計師面試必看

---

1、什麼是微服務？

微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程式劃分成一組小的服務，每個服務執行在其獨立的自己的程式中，服務之間互相協調、互相配合，為使用者提供最終價值。 服務之間採用輕量級的通訊機制互相溝通（通常是基於HTTP的RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的資料儲存。

從技術維度來說：

微服務化的核心就是將傳統的一站式應用，根據業務拆分成一個一個的服務，徹底地去耦合,每一個微服務提供單個業務功能的服務，一個服務做一件事，從技術角度看就是一種小而獨立的處理過程，類似程式概念，能夠自行單獨啟動或銷燬，擁有自己獨立的資料庫。

2、微服務之間是如何通訊的？

① 遠端過程呼叫（Remote Procedure Invocation）

直接通過遠端過程呼叫來訪問別的service。

示例：REST、gRPC、Apache、Thrift

優點：

簡單，常見。因為沒有中介軟體代理，系統更簡單

缺點：

只支援請求/響應的模式，不支援別的，比如通知、請求/非同步響應、釋出/訂閱、釋出/非同步響應
降低了可用性，因為客戶端和服務端在請求過程中必須都是可用的

② 訊息

使用非同步訊息來做服務間通訊。服務間通過訊息管道來交換訊息，從而通訊。

示例：Apache Kafka、RabbitMQ

優點:

• 把客戶端和服務端解耦，更鬆耦合 提高可用性，因為訊息中介軟體快取了訊息，直到消費者可以消費
• 支援很多通訊機制比如通知、請求/非同步響應、釋出/訂閱、釋出/非同步響應

缺點:

訊息中介軟體有額外的複雜性

3、springcloud 與dubbo有哪些區別？

相同點：
SpringCloud 和Dubbo可以實現RPC遠端呼叫框架，可以實現服務治理。

不同點:
SpringCloud是一套目前比較網站微服務框架了，整合了分散式常用解決方案遇到了問題註冊中心Eureka、負載均衡器Ribbon ，客戶端呼叫工具Rest和Feign，分散式配置中心Config，服務保護Hystrix，閘道器Zuul Gateway ，服務鏈路Zipkin，訊息匯流排Bus等。

Dubbo內部實現功能沒有SpringCloud強大（全家桶），只是實現服務治理，缺少分散式配置中心、閘道器、鏈路、匯流排等，如果需要用到這些元件，需要整合其他框架。

表 Spring Cloud與Dubbo功能對比

功能名稱	Dubbo	Spring Cloud
服務註冊中心	ZooKeeper	Spring Cloud Netflix Eureka、ZooKeeper
服務呼叫方式	RPC	REST API
服務閘道器	無	Spring Cloud Netflix Zuul
斷路器	不完善	Spring Cloud Netflix Hystrix
分散式配置	無	Spring Cloud Config
服務跟蹤	無	Spring Cloud Sleuth
訊息匯流排	無	Spring Cloud Bus
資料流	無	Spring Cloud Stream
批量任務	無	Spring Cloud Task

4、請談談對SpringBoot 和SpringCloud的理解

① SpringBoot專注於快速方便的開發單個個體微服務。

② SpringCloud是關注全域性的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，
為各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件匯流排、全域性鎖、決策競選、分散式會話等等整合服務

③ SpringBoot可以離開SpringCloud獨立使用開發專案，但是SpringCloud離不開SpringBoot，屬於依賴的關係.

④ SpringBoot專注於快速、方便的開發單個微服務個體，SpringCloud關注全域性的服務治理框架。

Spring Boot可以離開Spring Cloud獨立使用開發專案，但是Spring Cloud離不開Spring Boot，屬於依賴的關係。

5、分散式系統面臨的問題

複雜分散式體系結構中的應用程式有數十個依賴關係，每個依賴關係在某些時候將不可避免地失敗。

• 服務雪崩
  多個微服務之間呼叫的時候，假設微服務A呼叫微服務B和微服務C，微服務B和微服務C又呼叫其它的微服務，這就是所謂的“扇出”。如果扇出的鏈路上某個微服務的呼叫響應時間過長或者不可用，對微服務A的呼叫就會佔用越來越多的系統資源，進而引起系統崩潰，所謂的“雪崩效應”.

• 對於高流量的應用來說，單一的後端依賴可能會導致所有伺服器上的所有資源都在幾秒鐘內飽和。比失敗更糟糕的是，這些應用程式還可能導致服務之間的延遲增加，備份佇列，執行緒和其他系統資源緊張，導致整個系統發生更多的級聯故障。這些都表示需要對故障和延遲進行隔離和管理，以便單個依賴關係的失敗，不能取消整個應用程式或系統。

一般情況對於服務依賴的保護主要有以下三種解決方案：

① 熔斷模式：這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災。放到我們的系統中，如果某個目標服務呼叫慢或者有大量超時，此時，熔斷該服務的呼叫，對於後續呼叫請求，不在繼續呼叫目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復呼叫。

② 隔離模式：這種模式就像對系統請求按型別劃分成一個個小島的一樣，當某個小島被火少光了，不會影響到其他的小島。例如可以對不同型別的請求使用執行緒池來資源隔離，每種型別的請求互不影響，如果一種型別的請求執行緒資源耗盡，則對後續的該型別請求直接返回，不再呼叫後續資源。這種模式使用場景非常多，例如將一個服務拆開，對於重要的服務使用單獨伺服器來部署，再或者公司最近推廣的多中心。

③ 限流模式：上述的熔斷模式和隔離模式都屬於出錯後的容錯處理機制，而限流模式則可以稱為預防模式。限流模式主要是提前對各個型別的請求設定最高的QPS閾值，若高於設定的閾值則對該請求直接返回，不再呼叫後續資源。這種模式不能解決服務依賴的問題，只能解決系統整體資源分配問題，因為沒有被限流的請求依然有可能造成雪崩效應。

6、什麼是服務熔斷，什麼是服務降級

服務熔斷

熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。
當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的呼叫，快速返回"錯誤"的響應資訊。當檢測到該節點微服務呼叫響應正常後恢復呼叫鏈路。在SpringCloud框架裡熔斷機制通過Hystrix實現。Hystrix會監控微服務間呼叫的狀況，當失敗的呼叫到一定閾值，預設是5秒內20次呼叫失敗就會啟動熔斷機制。熔斷機制的註解是@HystrixCommand。

Hystrix服務降級

其實就是執行緒池中單個執行緒障處理，防止單個執行緒請求時間太長，導致資源長期被佔有而得不到釋放，從而導致執行緒池被快速佔用完，導致服務崩潰。

Hystrix能解決如下問題：

① 請求超時降級，執行緒資源不足降級，降級之後可以返回自定義資料
② 執行緒池隔離降級，分散式服務可以針對不同的服務使用不同的執行緒池，從而互不影響
③ 自動觸發降級與恢復
④ 實現請求快取和請求合併

7、微服務的優缺點分別是什麼？說下你在專案開發中碰到的坑？

優點

• 每個服務足夠內聚，足夠小，程式碼容易理解這樣能聚焦一個指定的業務功能或業務需求
• 開發簡單、開發效率提高，一個服務可能就是專一的只幹一件事。
• 微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
• 微服務是鬆耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。
• 微服務能使用不同的語言開發。
• 易於和第三方整合，微服務允許容易且靈活的方式整合自動部署，通過持續整合工具，如Jenkins, Hudson, bamboo 。
• 微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值。
• 微服務允許你利用融合最新技術。
• 微服務只是業務邏輯的程式碼，不會和HTML,CSS 或其他介面元件混合。
• 每個微服務都有自己的儲存能力，可以有自己的資料庫。也可以有統一資料庫。

缺點

• 開發人員要處理分散式系統的複雜性
• 多服務運維難度，隨著服務的增加，運維的壓力也在增大
• 系統部署依賴
• 服務間通訊成本
• 資料一致性
• 系統整合測試
• 效能監控……

8、你所知道的微服務技術棧有哪些？請列舉一二

• 服務開發
  Springboot、Spring、SpringMVC
• 服務配置與管理
  Netflix公司的Archaius、阿里的Diamond等
• 服務註冊與發現
  Eureka、Consul、Zookeeper等
• 服務呼叫
  Rest、RPC、gRPC
• 服務熔斷器
  Hystrix、Envoy等
• 負載均衡
  Ribbon、Nginx等
• 服務介面呼叫(客戶端呼叫服務的簡化工具)
  Feign等
• 訊息佇列
  Kafka、RabbitMQ、ActiveMQ等
• 服務配置中心管理
  SpringCloudConfig、Chef等
• 服務路由（API閘道器）
  Zuul等
• 服務監控
  Zabbix、Nagios、Metrics、Spectator等
• 全鏈路追蹤
  Zipkin，Brave、Dapper等
• 服務部署
  Docker、OpenStack、Kubernetes等
• 資料流操作開發包
  SpringCloud Stream（封裝與Redis,Rabbit、Kafka等傳送接收訊息）
• 事件訊息匯流排
  Spring Cloud Bus

9、什麼是 Eureka服務註冊與發現

Eureka是Netflix的一個子模組，也是核心模組之一。Eureka是一個基於REST的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。服務註冊與發現對於微服務架構來說是非常重要的，有了服務發現與註冊，只需要使用服務的識別符號，就可以訪問到服務，而不需要修改服務呼叫的配置檔案了。功能類似於dubbo的註冊中心，比如Zookeeper。

10、Eureka的基本架構是什麼？

Spring Cloud 封裝了 Netflix 公司開發的 Eureka 模組來實現服務註冊和發現(請對比Zookeeper)。

Eureka 採用了 C-S 的設計架構。Eureka Server 作為服務註冊功能的伺服器，它是服務註冊中心。

而系統中的其他微服務，使用 Eureka 的客戶端連線到 Eureka Server並維持心跳連線。這樣系統的維護人員就可以通過 Eureka Server 來監控系統中各個微服務是否正常執行。SpringCloud 的一些其他模組（比如Zuul）就可以通過 Eureka Server 來發現系統中的其他微服務，並執行相關的邏輯。

Eureka包含兩個元件： Eureka Server 和 Eureka Client

Eureka Server提供服務註冊服務
各個節點啟動後，會在EurekaServer中進行註冊，這樣EurekaServer中的服務登錄檔中將會儲存所有可用服務節點的資訊，服務節點的資訊可以在介面中直觀的看到

EurekaClient是一個Java客戶端
用於簡化Eureka Server的互動，客戶端同時也具備一個內建的、使用輪詢(round-robin)負載演算法的負載均衡器。在應用啟動後，將會向Eureka Server傳送心跳(預設週期為30秒)。如果Eureka Server在多個心跳週期內沒有接收到某個節點的心跳，EurekaServer將會從服務登錄檔中把這個服務節點移除（預設90秒）

11、作為服務註冊中心，Eureka比Zookeeper好在哪裡?

著名的CAP理論指出，一個分散式系統不可能同時滿足C(一致性)、A(可用性)和P(分割槽容錯性)。由於分割槽容錯性P在是分散式系統中必須要保證的，因此我們只能在A和C之間進行權衡。

因此，Zookeeper 保證的是CP, Eureka 則是AP。

Zookeeper保證CP

當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因為網路故障與其他節點失去聯絡時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30~120s,且選舉期間整個zk叢集都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網路問題使得zk叢集失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。

Eureka保證AP

Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時如果發現連線失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的資訊可能不是最新的(不保證強一致性)。

除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：

1. Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務
2. Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網路穩定時，當前例項新的註冊資訊會被同步到其它節點中

因此， Eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。

12、什麼是 Ribbon負載均衡

Spring Cloud Ribbon是基於Netflix Ribbon實現的一套客戶端 負載均衡的工具。

簡單的說，Ribbon是Netflix釋出的開源專案，主要功能是提供客戶端的軟體負載均衡演算法，將Netflix的中間層服務連線在一起。Ribbon客戶端元件提供一系列完善的配置項如連線超時，重試等。簡單的說，就是在配置檔案中列出Load Balancer（簡稱LB）後面所有的機器，Ribbon會自動的幫助你基於某種規則（如簡單輪詢，隨機連線等）去連線這些機器。我們也很容易使用Ribbon實現自定義的負載均衡演算法。

13、Ribbon負載均衡能幹嘛？

• LB（負載均衡)
  LB，即負載均衡(Load Balance)，在微服務或分散式叢集中經常用的一種應用。
  負載均衡簡單的說就是將使用者的請求平攤的分配到多個服務上，從而達到系統的HA。
  常見的負載均衡有軟體Nginx，LVS，硬體 F5等。
  相應的在中介軟體，例如：dubbo和SpringCloud中均給我們提供了負載均衡，SpringCloud的負載均衡演算法可以自定義。

• 集中式LB
  即在服務的消費方和提供方之間使用獨立的LB設施(可以是硬體，如F5, 也可以是軟體，如nginx), 由該設施負責把訪問請求通過某種策略轉發至服務的提供方；

• 程式內LB
  將LB邏輯整合到消費方，消費方從服務註冊中心獲知有哪些地址可用，然後自己再從這些地址中選擇出一個合適的伺服器。

注意： Ribbon就屬於程式內LB，它只是一個類庫，整合於消費方程式，消費方通過它來獲取到服務提供方的地址。

14、什麼是 Feign 負載均衡

Feign是一個宣告式WebService客戶端。使用Feign能讓編寫Web Service客戶端更加簡單, 它的使用方法是定義一個介面，然後在上面新增註解，同時也支援JAX-RS標準的註解。Feign也支援可拔插式的編碼器和解碼器。Spring Cloud對Feign進行了封裝，使其支援了Spring MVC標準註解和HttpMessageConverters。 Feign可以與Eureka和Ribbon組合使用以支援負載均衡。

Feign是一個宣告式的Web服務客戶端，使得編寫Web服務客戶端變得非常容易，只需要建立一個介面，然後在上面新增註解即可。

15、Feign 能幹什麼

Feign旨在使編寫Java Http客戶端變得更容易。

前面在使用Ribbon+RestTemplate時，利用RestTemplate對http請求的封裝處理，形成了一套模版化的呼叫方法。但是在實際開發中，由於對服務依賴的呼叫可能不止一處，往往一個介面會被多處呼叫，所以通常都會針對每個微服務自行封裝一些客戶端類來包裝這些依賴服務的呼叫。所以，Feign在此基礎上做了進一步封裝，由他來幫助我們定義和實現依賴服務介面的定義。在Feign的實現下，我們只需建立一個介面並使用註解的方式來配置它(以前是Dao介面上面標註Mapper註解,現在是一個微服務介面上面標註一個Feign註解即可)，即可完成對服務提供方的介面繫結，簡化了使用Spring cloud Ribbon時，自動封裝服務呼叫客戶端的開發量。

Feign整合了Ribbon
利用Ribbon維護了MicroServiceCloud-Dept的服務列表資訊，並且通過輪詢實現了客戶端的負載均衡。而與Ribbon不同的是，通過feign只需要定義服務繫結介面且以宣告式的方法，優雅而簡單的實現了服務呼叫

Feign通過介面的方法呼叫Rest服務（之前是Ribbon+RestTemplate），該請求傳送給Eureka伺服器（http://MICROSERVICECLOUD-DEPT/dept/list）,
通過Feign直接找到服務介面，由於在進行服務呼叫的時候融合了Ribbon技術，所以也支援負載均衡作用。

16、什麼是 Hystrix斷路器

Hystrix是一個用於處理分散式系統的延遲和容錯的開源庫，在分散式系統裡，許多依賴不可避免的會呼叫失敗，比如超時、異常等， Hystrix能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障，以提高分散式系統的彈性。

“斷路器”本身是一種開關裝置，當某個服務單元發生故障之後，通過斷路器的故障監控（類似熔斷保險絲），向呼叫方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者丟擲呼叫方無法處理的異常，這樣就保證了服務呼叫方的執行緒不會被長時間、不必要地佔用，從而避免了故障在分散式系統中的蔓延，乃至雪崩。

17、Hystrix斷路器能幹嘛？

① 服務降級

整體資源快不夠了，忍痛將某些服務先關掉，待渡過難關，再開啟回來

② 服務熔斷

熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。
當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的呼叫，快速返回"錯誤"的響應資訊。當檢測到該節點微服務呼叫響應正常後恢復呼叫鏈路。在SpringCloud框架裡熔斷機制通過Hystrix實現。Hystrix會監控微服務間呼叫的狀況，當失敗的呼叫到一定閾值，預設是5秒內20次呼叫失敗就會啟動熔斷機制。熔斷機制的註解是@HystrixCommand。

③ 服務限流

④ 接近實時的監控

除了隔離依賴服務的呼叫以外，Hystrix還提供了準實時的呼叫監控（Hystrix
Dashboard），Hystrix會持續地記錄所有通過Hystrix發起的請求的執行資訊，並以統計報表和圖形的形式展示給使用者，包括每秒執行多少請求多少成功，多少失敗等。Netflix通過hystrix-metrics-event-stream專案實現了對以上指標的監控。Spring
Cloud也提供了Hystrix Dashboard的整合，對監控內容轉化成視覺化介面。

18、什麼是 zuul路由閘道器

Zuul 包含了對請求的路由和過濾兩個最主要的功能：

其中路由功能負責將外部請求轉發到具體的微服務例項上，是實現外部訪問統一入口的基礎而過濾器功能則負責對請求的處理過程進行干預，是實現請求校驗、服務聚合等功能的基礎.Zuul和Eureka進行整合，將Zuul自身註冊為Eureka服務治理下的應用，同時從Eureka中獲得其他微服務的訊息，也即以後的訪問微服務都是通過Zuul跳轉後獲得。

注意： Zuul服務最終還是會註冊進Eureka

提供=代理+路由+過濾 三大功能

19、什麼是SpringCloud Config分散式配置中心

SpringCloud Config為微服務架構中的微服務提供集中化的外部配置支援，配置伺服器為各個不同微服務應用的所有環境提供了一箇中心化的外部配置。

20、分散式配置中心能幹嘛？

① 集中管理配置檔案，不同環境不同配置，動態化的配置更新，分環境部署比如dev/test/prod/beta/release
② 執行期間動態調整配置，不再需要在每個服務部署的機器上編寫配置檔案，服務會向配置中心統一拉取配置自己的資訊

③ 當配置發生變動時，服務不需要重啟==即可感知到配置的變化並應用新的配置將配置資訊以REST介面的形式暴露

---

由於水平有限，本部落格難免有不足，懇請各位大佬不吝賜教！