面試位元組、阿里等大廠后，總結了今年的Java面試必問的微服務面試題（含答案）-有解無憂

前言

有些小伙伴經過金九銀十這兩個月的面試奮戰，終于成功拿下了一些大廠的offer，小編總結了這些小伙伴的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強大（全家桶），只是實作服務治理，缺少分布式配置中心、網關、鏈路、總線等，如果需要用到這些組件，需要整合其他框架，

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就認為客戶端與注冊中心出現了網路故障，此時會出現以下幾種情況：

Eureka不再從注冊串列中移除因為長時間沒收到心跳而應該過期的服務

Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)當網路穩定時，當前實體新的注冊資訊會被同步到其它節點中，因此， 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還提供了準實時的呼叫監控（HystrixDashboard），Hystrix會持續地記錄所有通過Hystrix發起的請求的執行資訊，并以統計報表和圖形的形式展示給用戶，包括每秒執行多少請求多少成功，多少失敗等，Netflix通過hystrix-metrics-event-stream專案實作了對以上指標的監控，SpringCloud也提供了Hystrix Dashboard的整合，對監控內容轉化成可視化界面，

18、什么是 zuul路由網關

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

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

注意： Zuul服務最侄訓是會注冊進Eureka

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