有些小伙伴經(jīng)過金九銀十這兩個月的面試奮戰(zhàn)，終于成功拿下了一些大廠的 offer。小編總結(jié)了這些小伙伴的 Java 面試經(jīng)驗，整理了一份微服務(wù)面試題分享給大家，希望能給大家一點幫助。

1、什么是微服務(wù)？

---

微服務(wù)架構(gòu)是一種架構(gòu)模式或者說是一種架構(gòu)風(fēng)格，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，每個服務(wù)運行在其獨立的自己的進(jìn)程中，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。 服務(wù)之間采用輕量級的通信機(jī)制互相溝通（通常是基于 HTTP 的 RESTful API）。每個服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對具體的一個服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對其進(jìn)行構(gòu)建，可以有一個非常輕量級的集中式管理來協(xié)調(diào)這些服務(wù)，可以使用不同的語言來編寫服務(wù)，也可以使用不同的數(shù)據(jù)存儲。

從技術(shù)維度來說：

微服務(wù)化的核心就是將傳統(tǒng)的一站式應(yīng)用，根據(jù)業(yè)務(wù)拆分成一個一個的服務(wù)，徹底地去耦合,每一個微服務(wù)提供單個業(yè)務(wù)功能的服務(wù)，一個服務(wù)做一件事，從技術(shù)角度看就是一種小而獨立的處理過程，類似進(jìn)程概念，能夠自行單獨啟動或銷毀，擁有自己獨立的數(shù)據(jù)庫。

2、微服務(wù)之間是如何通訊的？

---

① 遠(yuǎn)程過程調(diào)用（Remote Procedure Invocation）

直接通過遠(yuǎn)程過程調(diào)用來訪問別的 service。

示例：REST、gRPC、Apache、Thrift

優(yōu)點：

簡單，常見。因為沒有中間件代理，系統(tǒng)更簡單

缺點：

只支持請求/響應(yīng)的模式，不支持別的，比如通知、請求/異步響應(yīng)、發(fā)布/訂閱、發(fā)布/異步響應(yīng)降低了可用性，因為客戶端和服務(wù)端在請求過程中必須都是可用的

② 消息

使用異步消息來做服務(wù)間通信。服務(wù)間通過消息管道來交換消息，從而通信。

示例：Apache Kafka、RabbitMQ

優(yōu)點：

把客戶端和服務(wù)端解耦，更松耦合 提高可用性，因為消息中間件緩存了消息，直到消費者可以消費支持很多通信機(jī)制比如通知、請求/異步響應(yīng)、發(fā)布/訂閱、發(fā)布/異步響應(yīng)

缺點：

消息中間件有額外的復(fù)雜性

3、springcloud 與 dubbo 有哪些區(qū)別？

---

相同點：

SpringCloud 和 Dubbo 可以實現(xiàn) RPC 遠(yuǎn)程調(diào)用框架，可以實現(xiàn)服務(wù)治理。

不同點：

SpringCloud 是一套目前比較網(wǎng)站微服務(wù)框架了，整合了分布式常用解決方案遇到了問題注冊中心 Eureka、負(fù)載均衡器 Ribbon ，客戶端調(diào)用工具 Rest 和 Feign，分布式配置中心 Config，服務(wù)保護(hù) Hystrix，網(wǎng)關(guān) Zuul Gateway ，服務(wù)鏈路 Zipkin，消息總線 Bus 等。

Dubbo 內(nèi)部實現(xiàn)功能沒有 SpringCloud 強(qiáng)大（全家桶），只是實現(xiàn)服務(wù)治理，缺少分布式配置中心、網(wǎng)關(guān)、鏈路、總線等，如果需要用到這些組件，需要整合其他框架。

① SpringBoot 專注于快速方便的開發(fā)單個個體微服務(wù)。

② SpringCloud 是關(guān)注全局的微服務(wù)協(xié)調(diào)整理治理框架，它將 SpringBoot 開發(fā)的一個個單體微服務(wù)整合并管理起來，為各個微服務(wù)之間提供，配置管理、服務(wù)發(fā)現(xiàn)、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等等集成服務(wù)

③ SpringBoot 可以離開 SpringCloud 獨立使用開發(fā)項目，但是 SpringCloud 離不開 SpringBoot，屬于依賴的關(guān)系.

④ SpringBoot 專注于快速、方便的開發(fā)單個微服務(wù)個體，SpringCloud 關(guān)注全局的服務(wù)治理框架。

Spring Boot 可以離開 Spring Cloud 獨立使用開發(fā)項目，但是 Spring Cloud 離不開 Spring Boot，屬于依賴的關(guān)系。

5、分布式系統(tǒng)面臨的問題

---

復(fù)雜分布式體系結(jié)構(gòu)中的應(yīng)用程序有數(shù)十個依賴關(guān)系，每個依賴關(guān)系在某些時候?qū)⒉豢杀苊獾厥　?/p>

服務(wù)雪崩

多個微服務(wù)之間調(diào)用的時候，假設(shè)微服務(wù) A 調(diào)用微服務(wù) B 和微服務(wù) C，微服務(wù) B 和微服務(wù) C 又調(diào)用其它的微服務(wù)，這就是所謂的“扇出”。如果扇出的鏈路上某個微服務(wù)的調(diào)用響應(yīng)時間過長或者不可用，對微服務(wù) A 的調(diào)用就會占用越來越多的系統(tǒng)資源，進(jìn)而引起系統(tǒng)崩潰，所謂的“雪崩效應(yīng)”。

對于高流量的應(yīng)用來說，單一的后端依賴可能會導(dǎo)致所有服務(wù)器上的所有資源都在幾秒鐘內(nèi)飽和。比失敗更糟糕的是，這些應(yīng)用程序還可能導(dǎo)致服務(wù)之間的延遲增加，備份隊列，線程和其他系統(tǒng)資源緊張，導(dǎo)致整個系統(tǒng)發(fā)生更多的級聯(lián)故障。這些都表示需要對故障和延遲進(jìn)行隔離和管理，以便單個依賴關(guān)系的失敗，不能取消整個應(yīng)用程序或系統(tǒng)。

一般情況對于服務(wù)依賴的保護(hù)主要有以下三種解決方案：

**① 熔斷模式：**這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災(zāi)。放到我們的系統(tǒng)中，如果某個目標(biāo)服務(wù)調(diào)用慢或者有大量超時，此時，熔斷該服務(wù)的調(diào)用，對于后續(xù)調(diào)用請求，不再繼續(xù)調(diào)用目標(biāo)服務(wù)，直接返回，快速釋放資源。如果目標(biāo)服務(wù)情況好轉(zhuǎn)則恢復(fù)調(diào)用。

**② 隔離模式：**這種模式就像對系統(tǒng)請求按類型劃分成一個個小島的一樣，當(dāng)某個小島被火燒光了，不會影響到其他的小島。例如可以對不同類型的請求使用線程池來資源隔離，每種類型的請求互不影響，如果一種類型的請求線程資源耗盡，則對后續(xù)的該類型請求直接返回，不再調(diào)用后續(xù)資源。這種模式使用場景非常多，例如將一個服務(wù)拆開，對于重要的服務(wù)使用單獨服務(wù)器來部署，再或者公司最近推廣的多中心。

**③ 限流模式：**上述的熔斷模式和隔離模式都屬于出錯后的容錯處理機(jī)制，而限流模式則可以稱為預(yù)防模式。限流模式主要是提前對各個類型的請求設(shè)置最高的 QPS 閾值，若高于設(shè)置的閾值則對該請求直接返回，不再調(diào)用后續(xù)資源。這種模式不能解決服務(wù)依賴的問題，只能解決系統(tǒng)整體資源分配問題，因為沒有被限流的請求依然有可能造成雪崩效應(yīng)。

6、什么是服務(wù)熔斷，什么是服務(wù)降級

---

服務(wù)熔斷

熔斷機(jī)制是應(yīng)對雪崩效應(yīng)的一種微服務(wù)鏈路保護(hù)機(jī)制。

當(dāng)刪出鏈路的某個微服務(wù)不可用或者響應(yīng)時間太長時，會進(jìn)行服務(wù)的降級，進(jìn)而熔斷該節(jié)點微服務(wù)的調(diào)用，快速返回"錯誤"的響應(yīng)信息。當(dāng)檢測到該節(jié)點微服務(wù)調(diào)用響應(yīng)正常后恢復(fù)調(diào)用鏈路。在 SpringCloud 框架里熔斷機(jī)制通過 Hystrix 實現(xiàn)。Hystrix 會監(jiān)控微服務(wù)間調(diào)用的狀況，當(dāng)失敗的調(diào)用到一定閾值，缺省是 5 秒內(nèi) 20 次調(diào)用失敗就會啟動熔斷機(jī)制。熔斷機(jī)制的注解是 @HystrixCommand。

Hystrix 服務(wù)降級

其實就是線程池中單個線程障處理，防止單個線程請求時間太長，導(dǎo)致資源長期被占有而得不到釋放，從而導(dǎo)致線程池被快速占用完，導(dǎo)致服務(wù)崩潰。

Hystrix 能解決如下問題：

① 請求超時降級，線程資源不足降級，降級之后可以返回自定義數(shù)據(jù)

② 線程池隔離降級，分布式服務(wù)可以針對不同的服務(wù)使用不同的線程池，從而互不影響

③ 自動觸發(fā)降級與恢復(fù)

④ 實現(xiàn)請求緩存和請求合并

7、微服務(wù)的優(yōu)缺點分別是什么？說下你在項目開發(fā)中碰到的坑？

---

優(yōu)點

• 每個服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解這樣能聚焦一個指定的業(yè)務(wù)功能或業(yè)務(wù)需求

• 開發(fā)簡單、開發(fā)效率提高，一個服務(wù)可能就是專一的只干一件事

• 微服務(wù)能夠被小團(tuán)隊單獨開發(fā)，這個小團(tuán)隊是 2 到 5 人的開發(fā)人員組成

• 微服務(wù)是松耦合的，是有功能意義的服務(wù)，無論是在開發(fā)階段或部署階段都是獨立的

• 微服務(wù)能使用不同的語言開發(fā)

• 易于和第三方集成，微服務(wù)允許容易且靈活的方式集成自動部署，通過持續(xù)集成工具，如 Jenkins, Hudson, bamboo

• 微服務(wù)易于被一個開發(fā)人員理解，修改和維護(hù)，這樣小團(tuán)隊能夠更關(guān)注自己的工作成果。無需通過合作才能體現(xiàn)價值

• 微服務(wù)允許你利用融合最新技術(shù)

• 微服務(wù)只是業(yè)務(wù)邏輯的代碼，不會和 HTML,CSS 或其他界面組件混合

• 每個微服務(wù)都有自己的存儲能力，可以有自己的數(shù)據(jù)庫。也可以有統(tǒng)一數(shù)據(jù)庫

缺點

• 開發(fā)人員要處理分布式系統(tǒng)的復(fù)雜性

• 多服務(wù)運維難度，隨著服務(wù)的增加，運維的壓力也在增大

• 系統(tǒng)部署依賴

• 服務(wù)間通信成本

• 數(shù)據(jù)一致性

• 系統(tǒng)集成測試

• 性能監(jiān)控……

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

---

• 服務(wù)開發(fā)

Springboot、Spring、SpringMVC

• 服務(wù)配置與管理

Netflix 公司的 Archaius、阿里的 Diamond 等

• 服務(wù)注冊與發(fā)現(xiàn)

Eureka、Consul、Zookeeper 等

• 服務(wù)調(diào)用

Rest、RPC、gRPC

• 服務(wù)熔斷器

Hystrix、Envoy 等

• 負(fù)載均衡

Ribbon、Nginx 等

• 服務(wù)接口調(diào)用(客戶端調(diào)用服務(wù)的簡化工具)

Feign 等

• 消息隊列

Kafka、RabbitMQ、ActiveMQ 等

• 服務(wù)配置中心管理

SpringCloudConfig、Chef 等

• 服務(wù)路由（API 網(wǎng)關(guān)）

Zuul 等

• 服務(wù)監(jiān)控

Zabbix、Nagios、Metrics、Spectator 等

• 全鏈路追蹤

Zipkin，Brave、Dapper 等

• 服務(wù)部署

Docker、OpenStack、Kubernetes 等

• 數(shù)據(jù)流操作開發(fā)包

SpringCloud Stream（封裝與 Redis,Rabbit、Kafka 等發(fā)送接收消息）

• 事件消息總線

Spring Cloud Bus

9、什么是 Eureka 服務(wù)注冊與發(fā)現(xiàn)

---

Eureka 是 Netflix 的一個子模塊，也是核心模塊之一。Eureka 是一個基于 REST 的服務(wù)，用于定位服務(wù)，以實現(xiàn)云端中間層服務(wù)發(fā)現(xiàn)和故障轉(zhuǎn)移。服務(wù)注冊與發(fā)現(xiàn)對于微服務(wù)架構(gòu)來說是非常重要的，有了服務(wù)發(fā)現(xiàn)與注冊，只需要使用服務(wù)的標(biāo)識符，就可以訪問到服務(wù)，而不需要修改服務(wù)調(diào)用的配置文件了。功能類似于 dubbo 的注冊中心，比如 Zookeeper。

10、Eureka 的基本架構(gòu)是什么？

---

Spring Cloud 封裝了 Netflix 公司開發(fā)的 Eureka 模塊來實現(xiàn)服務(wù)注冊和發(fā)現(xiàn)(請對比 Zookeeper)。Eureka 采用了 C-S 的設(shè)計架構(gòu)。Eureka Server 作為服務(wù)注冊功能的服務(wù)器，它是服務(wù)注冊中心。

而系統(tǒng)中的其他微服務(wù)，使用 Eureka 的客戶端連接到 Eureka Server 并維持心跳連接。這樣系統(tǒng)的維護(hù)人員就可以通過 Eureka Server 來監(jiān)控系統(tǒng)中各個微服務(wù)是否正常運行。SpringCloud 的一些其他模塊（比如 Zuul）就可以通過 Eureka Server 來發(fā)現(xiàn)系統(tǒng)中的其他微服務(wù)，并執(zhí)行相關(guān)的邏輯。

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

Eureka Server 提供服務(wù)注冊服務(wù)

各個節(jié)點啟動后，會在 EurekaServer 中進(jìn)行注冊，這樣 EurekaServer 中的服務(wù)注冊表中將會存儲所有可用服務(wù)節(jié)點的信息，服務(wù)節(jié)點的信息可以在界面中直觀的看到 EurekaClient 是一個 Java 客戶端

用于簡化 Eureka Server 的交互，客戶端同時也具備一個內(nèi)置的、使用輪詢(round-robin)負(fù)載算法的負(fù)載均衡器。在應(yīng)用啟動后，將會向 Eureka Server 發(fā)送心跳(默認(rèn)周期為 30 秒)。如果 Eureka Server 在多個心跳周期內(nèi)沒有接收到某個節(jié)點的心跳，EurekaServer 將會從服務(wù)注冊表中把這個服務(wù)節(jié)點移除（默認(rèn) 90 秒）

11、作為服務(wù)注冊中心，Eureka 比 Zookeeper 好在哪里?

---

著名的 CAP 理論指出，一個分布式系統(tǒng)不可能同時滿足 C(一致性)、A(可用性)和 P(分區(qū)容錯性)。由于分區(qū)容錯性 P 在是分布式系統(tǒng)中必須要保證的，因此我們只能在 A 和 C 之間進(jìn)行權(quán)衡。

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

Zookeeper 保證 CP

當(dāng)向注冊中心查詢服務(wù)列表時，我們可以容忍注冊中心返回的是幾分鐘以前的注冊信息，但不能接受服務(wù)直接 down 掉不可用。也就是說，服務(wù)注冊功能對可用性的要求要高于一致性。但是 zk 會出現(xiàn)這樣一種情況，當(dāng) master 節(jié)點因為網(wǎng)絡(luò)故障與其他節(jié)點失去聯(lián)系時，剩余節(jié)點會重新進(jìn)行 leader 選舉。問題在于，選舉 leader 的時間太長，30~120s,且選舉期間整個 zk 集群都是不可用的，這就導(dǎo)致在選舉期間注冊服務(wù)癱瘓。在云部署的環(huán)境下，因網(wǎng)絡(luò)問題使得 zk 集群失去 master 節(jié)點是較大概率會發(fā)生的事，雖然服務(wù)能夠最終恢復(fù)，但是漫長的選舉時間導(dǎo)致的注冊長期不可用是不能容忍的。

Eureka 保證 AP

Eureka 看明白了這一點，因此在設(shè)計時就優(yōu)先保證可用性。Eureka 各個節(jié)點都是平等的，幾個節(jié)點掛掉不會影響正常節(jié)點的工作，剩余的節(jié)點依然可以提供注冊和查詢服務(wù)。而 Eureka 的客戶端在向某個 Eureka 注冊或時如果發(fā)現(xiàn)連接失敗，則會自動切換至其它節(jié)點，只要有一臺 Eureka 還在，就能保證注冊服務(wù)可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強(qiáng)一致性)。

除此之外，Eureka 還有一種自我保護(hù)機(jī)制，如果在 15 分鐘內(nèi)超過 85%的節(jié)點都沒有正常的心跳，那么 Eureka 就認(rèn)為客戶端與注冊中心出現(xiàn)了網(wǎng)絡(luò)故障，此時會出現(xiàn)以下幾種情況：

Eureka 不再從注冊列表中移除因為長時間沒收到心跳而應(yīng)該過期的服務(wù)

Eureka 仍然能夠接受新服務(wù)的注冊和查詢請求，但是不會被同步到其它節(jié)點上(即保證當(dāng)前節(jié)點依然可用)當(dāng)網(wǎng)絡(luò)穩(wěn)定時，當(dāng)前實例新的注冊信息會被同步到其它節(jié)點中，因此， Eureka 可以很好的應(yīng)對因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點失去聯(lián)系的情況，而不會像 zookeeper 那樣使整個注冊服務(wù)癱瘓。

12、什么是 Ribbon 負(fù)載均衡

---

Spring Cloud Ribbon 是基于 Netflix Ribbon 實現(xiàn)的一套客戶端 負(fù)載均衡的工具。

簡單的說，Ribbon 是 Netflix 發(fā)布的開源項目，主要功能是提供客戶端的軟件負(fù)載均衡算法，將 Netflix 的中間層服務(wù)連接在一起。Ribbon 客戶端組件提供一系列完善的配置項如連接超時，重試等。簡單說，就是在配置文件中列出 Load Balancer（簡稱 LB）后面所有的機(jī)器，Ribbon 會自動的幫助你基于某種規(guī)則（如簡單輪詢，隨機(jī)連接等）去連接這些機(jī)器。我們也很容易使用 Ribbon 實現(xiàn)自定義的負(fù)載均衡算法。
【這里想說，因為自己也走了很多彎路過來的，所以才下定決心整理，收集過程雖不易，但想到能幫助到一部分自學(xué)java 的人，心里也是甜的！有需要的伙伴請點?方】↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

總結(jié)

以上是生活随笔為你收集整理的面试字节、阿里等大厂后，总结了今年的 Java 面试必问的微服务面试题（含答案）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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