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

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

---

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

從技術(shù)維度來(lái)說(shuō)：

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

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

---

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

直接通過(guò)遠(yuǎn)程過(guò)程調(diào)用來(lái)訪問(wèn)別的 service。

示例：REST、gRPC、Apache、Thrift

優(yōu)點(diǎn)：

簡(jiǎn)單，常見(jiàn)。因?yàn)闆](méi)有中間件代理，系統(tǒng)更簡(jiǎn)單

缺點(diǎn)：

只支持請(qǐng)求/響應(yīng)的模式，不支持別的，比如通知、請(qǐng)求/異步響應(yīng)、發(fā)布/訂閱、發(fā)布/異步響應(yīng)降低了可用性，因?yàn)榭蛻舳撕头?wù)端在請(qǐng)求過(guò)程中必須都是可用的

② 消息

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

示例：Apache Kafka、RabbitMQ

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

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

---

相同點(diǎn)：

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

不同點(diǎn)：

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

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

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

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

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

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

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

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

---

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

服務(wù)雪崩

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

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

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

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

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

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

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

---

服務(wù)熔斷

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

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

Hystrix 服務(wù)降級(jí)

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

Hystrix 能解決如下問(wèn)題：

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

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

③ 自動(dòng)觸發(fā)降級(jí)與恢復(fù)

④ 實(shí)現(xiàn)請(qǐng)求緩存和請(qǐng)求合并

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

---

優(yōu)點(diǎn)

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

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

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

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

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

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

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

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

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

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

缺點(diǎn)

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

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

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

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

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

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

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

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

---

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

Springboot、Spring、SpringMVC

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

Netflix 公司的 Archaius、阿里的 Diamond 等

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

Eureka、Consul、Zookeeper 等

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

Rest、RPC、gRPC

• 服務(wù)熔斷器

Hystrix、Envoy 等

• 負(fù)載均衡

Ribbon、Nginx 等

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

Feign 等

• 消息隊(duì)列

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ù)流操作開(kāi)發(fā)包

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

• 事件消息總線

Spring Cloud Bus

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

---

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

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

---

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

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

Eureka 包含兩個(gè)組件： Eureka Server 和 Eureka Client

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

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

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

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

---

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

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

Zookeeper 保證 CP

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

Eureka 保證 AP

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

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

Eureka 不再?gòu)淖?cè)列表中移除因?yàn)殚L(zhǎng)時(shí)間沒(méi)收到心跳而應(yīng)該過(guò)期的服務(wù)

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

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

---

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

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

總結(jié)

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

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