1、您對(duì)微服務(wù)有何了解？

微服務(wù)，又稱微服務(wù) 架 構(gòu)，是一種架構(gòu)風(fēng)格，它將應(yīng)用程序構(gòu)建為以業(yè)務(wù)領(lǐng)域?yàn)槟Ｐ偷男⌒妥灾畏?wù)集合 。

通俗地說，你必須看到蜜蜂如何通過對(duì)齊六角形蠟細(xì)胞來構(gòu)建它們的蜂窩狀物。他們最初從使用各種材料的小部分開始，并繼續(xù)從中構(gòu)建一個(gè)大型蜂箱。這些細(xì)胞形成圖案，產(chǎn)生堅(jiān)固的結(jié)構(gòu)，將蜂窩的特定部分固定在一起。這里，每個(gè)細(xì)胞獨(dú)立于另一個(gè)細(xì)胞，但它也與其他細(xì)胞相關(guān)。這意味著對(duì)一個(gè)細(xì)胞的損害不會(huì)損害其他細(xì)胞，因此，蜜蜂可以在不影響完整蜂箱的情況下重建這些細(xì)胞。

圖 1：微服務(wù)的蜂窩表示 – 微服務(wù)訪談問題

請(qǐng)參考上圖。這里，每個(gè)六邊形形狀代表單獨(dú)的服務(wù)組件。與蜜蜂的工作類似，每個(gè)敏捷團(tuán)隊(duì)都使用可用的框架和所選的技術(shù)堆棧構(gòu)建單獨(dú)的服務(wù)組件。就像在蜂箱中一樣，每個(gè)服務(wù)組件形成一個(gè)強(qiáng)大的微服務(wù)架構(gòu)，以提供更好的可擴(kuò)展性。此外，敏捷團(tuán)隊(duì)可以單獨(dú)處理每個(gè)服務(wù)組件的問題，而對(duì)整個(gè)應(yīng)用程序沒有影響或影響最小。

2、微服務(wù)架構(gòu)有哪些優(yōu)勢(shì)？

圖 2：微服務(wù)的 優(yōu)點(diǎn) – 微服務(wù)訪談問題

· 獨(dú)立開發(fā) – 所有微服務(wù)都可以根據(jù)各自的功能輕松開發(fā)

· 獨(dú)立部署 – 基于其服務(wù)，可以在任何應(yīng)用程序中單獨(dú)部署它們

· 故障隔離 – 即使應(yīng)用程序的一項(xiàng)服務(wù)不起作用，系統(tǒng)仍可繼續(xù)運(yùn)行

· 混合技術(shù)堆棧 – 可以使用不同的語言和技術(shù)來構(gòu)建同一應(yīng)用程序的不同服務(wù)

· 粒度縮放 – 單個(gè)組件可根據(jù)需要進(jìn)行縮放，無需將所有組件縮放在一起

3、微服務(wù)有哪些特點(diǎn)？

圖 3：微服務(wù)的 特點(diǎn) – 微服務(wù)訪談問題

· 解耦 – 系統(tǒng)內(nèi)的服務(wù)很大程度上是分離的。因此，整個(gè)應(yīng)用程序可以輕松構(gòu)建，更改和擴(kuò)展

· 組件化 – 微服務(wù)被視為可以輕松更換和升級(jí)的獨(dú)立組件

· 業(yè)務(wù)能力 – 微服務(wù)非常簡(jiǎn)單，專注于單一功能

· 自治 – 開發(fā)人員和團(tuán)隊(duì)可以彼此獨(dú)立工作，從而提高速度

· 持續(xù)交付 – 通過軟件創(chuàng)建，測(cè)試和批準(zhǔn)的系統(tǒng)自動(dòng)化，允許頻繁發(fā)布軟件

· 責(zé)任 – 微服務(wù)不關(guān)注應(yīng)用程序作為項(xiàng)目。相反，他們將應(yīng)用程序視為他們負(fù)責(zé)的產(chǎn)品

· 分散治理 – 重點(diǎn)是使用正確的工具來做正確的工作。這意味著沒有標(biāo)準(zhǔn)化模式或任何技術(shù)模式。開發(fā)人員可以自由選擇最有用的工具來解決他們的問題

· 敏捷 – 微服務(wù)支持敏捷開發(fā)。任何新功能都可以快速開發(fā)并再次丟棄

4、設(shè)計(jì)微服務(wù)的最佳實(shí)踐是什么？

以下是設(shè)計(jì)微服務(wù)的最佳實(shí)踐：

圖 4：設(shè)計(jì)微服務(wù)的最佳實(shí)踐 – 微服務(wù)訪談問題

5、微服務(wù)架構(gòu)如何運(yùn)作？

微服務(wù)架構(gòu)具有以下組件：

圖 5：微服務(wù) 架構(gòu) – 微服務(wù)面試問題

· 客戶端 – 來自不同設(shè)備的不同用戶發(fā)送請(qǐng)求。

· 身份提供商 – 驗(yàn)證用戶或客戶身份并頒發(fā)安全令牌。

· API 網(wǎng)關(guān) – 處理客戶端請(qǐng)求。

· 靜態(tài)內(nèi)容 – 容納系統(tǒng)的所有內(nèi)容。

· 管理 – 在節(jié)點(diǎn)上平衡服務(wù)并識(shí)別故障。

· 服務(wù)發(fā)現(xiàn) – 查找微服務(wù)之間通信路徑的指南。

· 內(nèi)容交付網(wǎng)絡(luò) – 代理服務(wù)器及其數(shù)據(jù)中心的分布式網(wǎng)絡(luò)。

· 遠(yuǎn)程服務(wù) – 啟用駐留在 IT 設(shè)備網(wǎng)絡(luò)上的遠(yuǎn)程訪問信息。

6、微服務(wù)架構(gòu)的優(yōu)缺點(diǎn)是什么？

7、單片，SOA 和微服務(wù)架構(gòu)有什么區(qū)別？

圖 6： 單片 SOA 和微服務(wù)之間的比較 – 微服務(wù)訪談問題

· 單片架構(gòu)類似于大容器，其中應(yīng)用程序的所有軟件組件組裝在一起并緊密封裝。

· 一個(gè)面向服務(wù)的架構(gòu)是一種相互通信服務(wù)的集合。通信可以涉及簡(jiǎn)單的數(shù)據(jù)傳遞，也可以涉及兩個(gè)或多個(gè)協(xié)調(diào)某些活動(dòng)的服務(wù)。

· 微服務(wù)架構(gòu)是一種架構(gòu)風(fēng)格，它將應(yīng)用程序構(gòu)建為以業(yè)務(wù)域?yàn)槟Ｐ偷男⌒妥灾畏?wù)集合。

8、在使用微服務(wù)架構(gòu)時(shí)，您面臨哪些挑戰(zhàn)？

開發(fā)一些較小的微服務(wù)聽起來很容易，但開發(fā)它們時(shí)經(jīng)常遇到的挑戰(zhàn)如下。

· 自動(dòng)化組件：難以自動(dòng)化，因?yàn)橛性S多較小的組件。因此，對(duì)于每個(gè)組件，我們必須遵循 Build，Deploy 和 Monitor 的各個(gè)階段。

· 易感性：將大量組件維護(hù)在一起變得難以部署，維護(hù)，監(jiān)控和識(shí)別問題。它需要在所有組件周圍具有很好的感知能力。

· 配置管理：有時(shí)在各種環(huán)境中維護(hù)組件的配置變得困難。

· 調(diào)試：很難找到錯(cuò)誤的每一項(xiàng)服務(wù)。維護(hù)集中式日志記錄和儀表板以調(diào)試問題至關(guān)重要。

9、SOA 和微服務(wù)架構(gòu)之間的主要區(qū)別是什么？

SOA 和微服務(wù)之間的主要區(qū)別如下：

10、微服務(wù)有什么特點(diǎn)？

您可以列出微服務(wù)的特征，如下所示：

圖 7：微服務(wù)的特征 – 微服務(wù)訪談問題

11、什么是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)？

圖 8： DDD 原理 – 微服務(wù)面試問題

12、為什么需要域驅(qū)動(dòng)設(shè)計(jì)（DDD）？

圖 9：我們需要 DDD 的因素 – 微服務(wù)面試問題

13、什么是無所不在的語言？

如果您必須定義泛在語言（UL），那么它是特定域的開發(fā)人員和用戶使用的通用語言，通過該語言可以輕松解釋域。

無處不在的語言必須非常清晰，以便它將所有團(tuán)隊(duì)成員放在同一頁面上，并以機(jī)器可以理解的方式進(jìn)行翻譯。

14、什么是凝聚力？

模塊內(nèi)部元素所屬的程度被認(rèn)為是凝聚力。

15、什么是耦合？

組件之間依賴關(guān)系強(qiáng)度的度量被認(rèn)為是耦合。一個(gè)好的設(shè)計(jì)總是被認(rèn)為具有高內(nèi)聚力和低耦合性。

16、什么是 REST / RESTful 以及它的用途是什么？

Representational State Transfer（REST）/ RESTful Web 服務(wù)是一種幫助計(jì)算機(jī)系統(tǒng)通過 Internet 進(jìn)行通信的架構(gòu)風(fēng)格。這使得微服務(wù)更容易理解和實(shí)現(xiàn)。

微服務(wù)可以使用或不使用 RESTful API 實(shí)現(xiàn)，但使用 RESTful API 構(gòu)建松散耦合的微服務(wù)總是更容易。

17、你對(duì) Spring Boot 有什么了解？

事實(shí)上，隨著新功能的增加，彈簧變得越來越復(fù)雜。如果必須啟動(dòng)新的 spring 項(xiàng)目，則必須添加構(gòu)建路徑或添加 maven 依賴項(xiàng)，配置應(yīng)用程序服務(wù)器，添加 spring配置。所以一切都必須從頭開始。

Spring Boot 是解決這個(gè)問題的方法。使用 spring boot 可以避免所有樣板代碼和配置。因此，基本上認(rèn)為自己就好像你正在烘烤蛋糕一樣，春天就像制作蛋糕所需的成分一樣，彈簧靴就是你手中的完整蛋糕。

圖 10： Spring Boot 的因素 – 微服務(wù)面試問題

18、什么是 Spring 引導(dǎo)的執(zhí)行器？

Spring Boot 執(zhí)行程序提供了 restful Web 服務(wù)，以訪問生產(chǎn)環(huán)境中運(yùn)行應(yīng)用程序的當(dāng)前狀態(tài)。在執(zhí)行器的幫助下，您可以檢查各種指標(biāo)并監(jiān)控您的應(yīng)用程序。

19、什么是 Spring Cloud？

根據(jù) Spring Cloud 的官方網(wǎng)站，Spring Cloud 為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見模式的工具（例如配置管理，服務(wù)發(fā)現(xiàn)，斷路器，智能路由，領(lǐng)導(dǎo)選舉，分布式會(huì)話，集群狀態(tài)）。

20、Spring Cloud 解決了哪些問題？

在使用 Spring Boot 開發(fā)分布式微服務(wù)時(shí)，我們面臨的問題很少由 Spring Cloud解決。

· 與分布式系統(tǒng)相關(guān)的復(fù)雜性 – 包括網(wǎng)絡(luò)問題，延遲開銷，帶寬問題，安全問題。

· 處理服務(wù)發(fā)現(xiàn)的能力 – 服務(wù)發(fā)現(xiàn)允許集群中的進(jìn)程和服務(wù)找到彼此并進(jìn)行通信。

· 解決冗余問題 – 冗余問題經(jīng)常發(fā)生在分布式系統(tǒng)中。

· 負(fù)載平衡 – 改進(jìn)跨多個(gè)計(jì)算資源（例如計(jì)算機(jī)集群，網(wǎng)絡(luò)鏈接，中央處理單元）的工作負(fù)載分布。

· 減少性能問題 – 減少因各種操作開銷導(dǎo)致的性能問題。

21、在 Spring MVC 應(yīng)用程序中使用 WebMvcTest 注釋有什么用處？

在測(cè)試目標(biāo)只關(guān)注 Spring MVC 組件的情況下，WebMvcTest 注釋用于單元測(cè)試Spring MVC 應(yīng)用程序。在上面顯示的快照中，我們只想啟動(dòng) ToTestController。執(zhí)行此單元測(cè)試時(shí)，不會(huì)啟動(dòng)所有其他控制器和映射。

22、你能否給出關(guān)于休息和微服務(wù)的要點(diǎn)？

雖然您可以通過多種方式實(shí)現(xiàn)微服務(wù)，但 REST over HTTP 是實(shí)現(xiàn)微服務(wù)的一種方式。REST 還可用于其他應(yīng)用程序，如 Web 應(yīng)用程序，API 設(shè)計(jì)和 MVC 應(yīng)用程序，以提供業(yè)務(wù)數(shù)據(jù)。

微服務(wù)是一種體系結(jié)構(gòu)，其中系統(tǒng)的所有組件都被放入單獨(dú)的組件中，這些組件可以單獨(dú)構(gòu)建，部署和擴(kuò)展。微服務(wù)的某些原則和最佳實(shí)踐有助于構(gòu)建彈性應(yīng)用程序。

簡(jiǎn)而言之，您可以說 REST 是構(gòu)建微服務(wù)的媒介。

23、什么是不同類型的微服務(wù)測(cè)試？

在使用微服務(wù)時(shí)，由于有多個(gè)微服務(wù)協(xié)同工作，測(cè)試變得非常復(fù)雜。因此，測(cè)試分為不同的級(jí)別。

· 在底層，我們有面向技術(shù)的測(cè)試，如單元測(cè)試和性能測(cè)試。這些是完全自動(dòng)化的。

· 在中間層面，我們進(jìn)行了諸如壓力測(cè)試和可用性測(cè)試之類的探索性測(cè)試。

· 在頂層， 我們的 驗(yàn)收測(cè)試數(shù)量很少。這些驗(yàn)收測(cè)試有助于利益相關(guān)者理解和驗(yàn)證軟件功能。

24、您對(duì) Distributed Transaction 有何了解？

分布式事務(wù)是指單個(gè)事件導(dǎo)致兩個(gè)或多個(gè)不能以原子方式提交的單獨(dú)數(shù)據(jù)源的突變的任何情況。在微服務(wù)的世界中，它變得更加復(fù)雜，因?yàn)槊總€(gè)服務(wù)都是一個(gè)工作單元，并且大多數(shù)時(shí)候多個(gè)服務(wù)必須協(xié)同工作才能使業(yè)務(wù)成功。

25、什么是 Idempotence 以及它在哪里使用？

冪等性是能夠以這樣的方式做兩次事情的特性，即最終結(jié)果將保持不變，即好像它只做了一次。

用法：在遠(yuǎn)程服務(wù)或數(shù)據(jù)源中使用 Idempotence，這樣當(dāng)它多次接收指令時(shí)，它只處理指令一次。

26、什么是有界上下文？

有界上下文是域驅(qū)動(dòng)設(shè)計(jì)的核心模式。DDD 戰(zhàn)略設(shè)計(jì)部門的重點(diǎn)是處理大型模型和團(tuán)隊(duì)。DDD 通過將大型模型劃分為不同的有界上下文并明確其相互關(guān)系來處理大型模型。

27、什么是雙因素身份驗(yàn)證？

雙因素身份驗(yàn)證為帳戶登錄過程啟用第二級(jí)身份驗(yàn)證。

圖 11： 雙因素認(rèn)證的表示 – 微服務(wù)訪談問題

因此，假設(shè)用戶必須只輸入用戶名和密碼，那么這被認(rèn)為是單因素身份驗(yàn)證。

28、雙因素身份驗(yàn)證的憑據(jù)類型有哪些？

這三種憑證是：

圖 12： 雙因素認(rèn)證的證書類型 – 微服務(wù)面試問題

29、什么是客戶證書？

客戶端系統(tǒng)用于向遠(yuǎn)程服務(wù)器發(fā)出經(jīng)過身份驗(yàn)證的請(qǐng)求的一種數(shù)字證書稱為客戶端證書?？蛻舳俗C書在許多相互認(rèn)證設(shè)計(jì)中起著非常重要的作用，為請(qǐng)求者的身份提供了強(qiáng)有力的保證。

30、PACT 在微服務(wù)架構(gòu)中的用途是什么？

PACT 是一個(gè)開源工具，允許測(cè)試服務(wù)提供者和消費(fèi)者之間的交互，與合同隔離，從而提高微服務(wù)集成的可靠性。

微服務(wù)中的用法

· 用于在微服務(wù)中實(shí)現(xiàn)消費(fèi)者驅(qū)動(dòng)的合同。

· 測(cè)試微服務(wù)的消費(fèi)者和提供者之間的消費(fèi)者驅(qū)動(dòng)的合同。

查看即將到來的批次

31、什么是 OAuth？

OAuth 代表開放授權(quán)協(xié)議。這允許通過在 HTTP 服務(wù)上啟用客戶端應(yīng)用程序（例如第三方提供商 Facebook，GitHub 等）來訪問資源所有者的資源。因此，您可以在不使用其憑據(jù)的情況下與另一個(gè)站點(diǎn)共享存儲(chǔ)在一個(gè)站點(diǎn)上的資源。

32、康威定律是什么？

“任 何 設(shè) 計(jì) 系 統(tǒng) 的 組 織 （ 廣 泛 定 義 ） 都 將 產(chǎn) 生 一 種 設(shè) 計(jì) ， 其 結(jié) 構(gòu) 是 組 織 通 信 結(jié) 構(gòu)的 副 本 。” – Mel Conway

圖 13： Conway 定律的表示 – 微服務(wù)訪談問題

該法律基本上試圖傳達(dá)這樣一個(gè)事實(shí)：為了使軟件模塊起作用，整個(gè)團(tuán)隊(duì)?wèi)?yīng)該進(jìn)行良好的溝通。因此，系統(tǒng)的結(jié)構(gòu)反映了產(chǎn)生它的組織的社會(huì)邊界。

33、合同測(cè)試你懂什么？

根據(jù) Martin Flower 的說法，合同測(cè)試是在外部服務(wù)邊界進(jìn)行的測(cè)試，用于驗(yàn)證其是否符合消費(fèi)服務(wù)預(yù)期的合同。

此外，合同測(cè)試不會(huì)深入測(cè)試服務(wù)的行為。更確切地說，它測(cè)試該服務(wù)調(diào)用的輸入＆輸出包含所需的屬性和所述響應(yīng)延遲，吞吐量是允許的限度內(nèi)。

34、什么是端到端微服務(wù)測(cè)試？

端到端測(cè)試驗(yàn)證了工作流中的每個(gè)流程都正常運(yùn)行。這可確保系統(tǒng)作為一個(gè)整體協(xié)同工作并滿足所有要求。

通俗地說，你可以說端到端測(cè)試是一種測(cè)試，在特定時(shí)期后測(cè)試所有東西。

圖 14：測(cè)試層次 – 微服務(wù)面試問題

35、Container 在微服務(wù)中的用途是什么？

容器是管理基于微服務(wù)的應(yīng)用程序以便單獨(dú)開發(fā)和部署它們的好方法。您可以將微服務(wù)封裝在容器映像及其依賴項(xiàng)中，然后可以使用它來滾動(dòng)按需實(shí)例的微服務(wù)，而無需任何額外的工作。

圖 15： 容器的表示及其在微服務(wù)中的使用方式 – 微服務(wù)訪談問題

36、什么是微服務(wù)架構(gòu)中的 DRY？

DRY 代表不要重復(fù)自己。它基本上促進(jìn)了重用代碼的概念。這導(dǎo)致開發(fā)和共享庫(kù)，這反過來導(dǎo)致緊密耦合。

37、什么是消費(fèi)者驅(qū)動(dòng)的合同（CDC）？

這基本上是用于開發(fā)微服務(wù)的模式，以便它們可以被外部系統(tǒng)使用。當(dāng)我們處理微服務(wù)時(shí)，有一個(gè)特定的提供者構(gòu)建它，并且有一個(gè)或多個(gè)使用微服務(wù)的消費(fèi)者。

通常，提供程序在 XML 文檔中指定接口。但在消費(fèi)者驅(qū)動(dòng)的合同中，每個(gè)服務(wù)消費(fèi)者都傳達(dá)了提供商期望的接口。

38、Web，RESTful API 在微服務(wù)中的作用是什么？

微服務(wù)架構(gòu)基于一個(gè)概念，其中所有服務(wù)應(yīng)該能夠彼此交互以構(gòu)建業(yè)務(wù)功能。因此，要實(shí)現(xiàn)這一點(diǎn)，每個(gè)微服務(wù)必須具有接口。這使得 Web API 成為微服務(wù)的一個(gè)非常重要的推動(dòng)者。RESTful API 基于 Web 的開放網(wǎng)絡(luò)原則，為構(gòu)建微服務(wù)架構(gòu)的各個(gè)組件之間的接口提供了最合理的模型。

39、您對(duì)微服務(wù)架構(gòu)中的語義監(jiān)控有何了解？

語義監(jiān)控，也稱為 綜合監(jiān)控， 將自動(dòng)化測(cè)試與監(jiān)控應(yīng)用程序相結(jié)合，以檢測(cè)業(yè)務(wù)失敗因素。

40、我們?nèi)绾芜M(jìn)行跨功能測(cè)試？

跨功能測(cè)試是對(duì)非功能性需求的驗(yàn)證，即那些無法像普通功能那樣實(shí)現(xiàn)的需求。

41、我們?nèi)绾卧跍y(cè)試中消除非決定論？

非確定性測(cè)試（NDT）基本上是不可靠的測(cè)試。所以，有時(shí)可能會(huì)發(fā)生它們通過，顯然有時(shí)它們也可能會(huì)失敗。當(dāng)它們失敗時(shí)，它們會(huì)重新運(yùn)行通過。

從測(cè)試中刪除非確定性的一些方法如下：

1、 隔離

2、 異步

3、 遠(yuǎn)程服務(wù)

4、 隔離

5、 時(shí)間

6、 資源泄漏

42、Mock 或 Stub 有什么區(qū)別？

存根

· 一個(gè)有助于運(yùn)行測(cè)試的虛擬對(duì)象。

· 在某些可以硬編碼的條件下提供固定行為。

· 永遠(yuǎn)不會(huì)測(cè)試存根的任何其他行為。

例如，對(duì)于空堆棧，您可以創(chuàng)建一個(gè)只為 empty（）方法 返回 true 的存根。因此，這并不關(guān)心堆棧中是否存在元素。

嘲笑

· 一個(gè)虛擬對(duì)象，其中最初設(shè)置了某些屬性。

· 此對(duì)象的行為取決于 set 屬性。

· 也可以測(cè)試對(duì)象的行為。

例如，對(duì)于 Customer 對(duì)象，您可以通過設(shè)置名稱和年齡來模擬它。您可以將 age設(shè)置為 12，然后測(cè)試 isAdult（）方法，該方法將在年齡大于 18 時(shí)返回 true。因此，您的 Mock Customer 對(duì)象適用于指定的條件。

43、您對(duì) Mike Cohn 的測(cè)試金字塔了解多少？

Mike Cohn 提供了一個(gè)名為 Test Pyramid 的模型。這描述了軟件開發(fā)所需的自動(dòng)化測(cè)試類型。

圖 16： Mike Cohn 的測(cè)試金字塔 – 微服務(wù)面試問題

根據(jù)金字塔，第一層的測(cè)試數(shù)量應(yīng)該最高。在服務(wù)層，測(cè)試次數(shù)應(yīng)小于單元測(cè)試級(jí)別，但應(yīng)大于端到端級(jí)別。

44、Docker 的目的是什么？

Docker 提供了一個(gè)可用于托管任何應(yīng)用程序的容器環(huán)境。在此，軟件應(yīng)用程序和支持它的依賴項(xiàng)緊密打包在一起。

因此，這個(gè)打包的產(chǎn)品被稱為 Container，因?yàn)樗怯?Docker 完成的，所以它被稱為 Docker 容器！

45、什么是金絲雀釋放？

Canary Releasing 是一種降低在生產(chǎn)中引入新軟件版本的風(fēng)險(xiǎn)的技術(shù)。這是通過將變更緩慢地推廣到一小部分用戶，然后將其發(fā)布到整個(gè)基礎(chǔ)架構(gòu)，即將其提供給每個(gè)人來完成的。

46、什么是持續(xù)集成（CI）？

持續(xù)集成（CI）是每次團(tuán)隊(duì)成員提交版本控制更改時(shí)自動(dòng)構(gòu)建和測(cè)試代碼的過程。這鼓勵(lì)開發(fā)人員通過在每個(gè)小任務(wù)完成后將更改合并到共享版本控制存儲(chǔ)庫(kù)來共享代碼和單元測(cè)試。

47、什么是持續(xù)監(jiān)測(cè)？

持續(xù)監(jiān)控深入監(jiān)控覆蓋范圍，從瀏覽器內(nèi)前端性能指標(biāo)，到應(yīng)用程序性能，再到主機(jī)虛擬化基礎(chǔ)架構(gòu)指標(biāo)。

48、架構(gòu)師在微服務(wù)架構(gòu)中的角色是什么？

微服務(wù)架構(gòu)中的架構(gòu)師扮演以下角色：

· 決定整個(gè)軟件系統(tǒng)的布局。

· 幫助確定組件的分區(qū)。因此，他們確保組件相互粘合，但不緊密耦合。

· 與開發(fā)人員共同編寫代碼，了解日常生活中面臨的挑戰(zhàn)。

· 為開發(fā)微服務(wù)的團(tuán)隊(duì)提供某些工具和技術(shù)的建議。

· 提供技術(shù)治理，以便技術(shù)開發(fā)團(tuán)隊(duì)遵循微服務(wù)原則。

49、我們可以用微服務(wù)創(chuàng)建狀態(tài)機(jī)嗎？

我們知道擁有自己的數(shù)據(jù)庫(kù)的每個(gè)微服務(wù)都是一個(gè)可獨(dú)立部署的程序單元，這反過來又讓我們可以創(chuàng)建一個(gè)狀態(tài)機(jī)。因此，我們可以為特定的微服務(wù)指定不同的狀態(tài)和事件。

例如，我們可以定義 Order 微服務(wù)。訂單可以具有不同的狀態(tài)。Order 狀態(tài)的轉(zhuǎn)換可以是 Order 微服務(wù)中的獨(dú)立事件。

50、什么是微服務(wù)中的反應(yīng)性擴(kuò)展？

Reactive Extensions 也稱為 Rx。這是一種設(shè)計(jì)方法，我們通過調(diào)用多個(gè)服務(wù)來收集結(jié)果，然后編譯組合響應(yīng)。這些調(diào)用可以是同步或異步，阻塞或非阻塞。Rx是分布式系統(tǒng)中非常流行的工具，與傳統(tǒng)流程相反。

SpringCloud面試題

1、什么是 Spring Cloud？

Spring cloud 流應(yīng)用程序啟動(dòng)器是基于 Spring Boot 的 Spring 集成應(yīng)用程序，提供與外部系統(tǒng)的集成。Spring cloud Task，一個(gè)生命周期短暫的微服務(wù)框架，用于快速構(gòu)建執(zhí)行有限數(shù)據(jù)處理的應(yīng)用程序。

2、使用 Spring Cloud 有什么優(yōu)勢(shì)？

使用 Spring Boot 開發(fā)分布式微服務(wù)時(shí)，我們面臨以下問題

（1）與分布式系統(tǒng)相關(guān)的復(fù)雜性-這種開銷包括網(wǎng)絡(luò)問題，延遲開銷，帶寬問題，安全問題。

（2）服務(wù)發(fā)現(xiàn)-服務(wù)發(fā)現(xiàn)工具管理群集中的流程和服務(wù)如何查找和互相交談。它涉及一個(gè)服務(wù)目錄，在該目錄中注冊(cè)服務(wù)，然后能夠查找并連接到該目錄中的服務(wù)。

（3）冗余-分布式系統(tǒng)中的冗余問題。

（4）負(fù)載平衡 --負(fù)載平衡改善跨多個(gè)計(jì)算資源的工作負(fù)荷，諸如計(jì)算機(jī)，計(jì)算機(jī)集群，網(wǎng)絡(luò)鏈路，中央處理單元，或磁盤驅(qū)動(dòng)器的分布。

（5）性能-問題 由于各種運(yùn)營(yíng)開銷導(dǎo)致的性能問題。

（6）部署復(fù)雜性-Devops 技能的要求。

3、服務(wù)注冊(cè)和發(fā)現(xiàn)是什么意思？Spring Cloud 如何實(shí)現(xiàn)？

當(dāng)我們開始一個(gè)項(xiàng)目時(shí)，我們通常在屬性文件中進(jìn)行所有的配置。隨著越來越多的服務(wù)開發(fā)和部署，添加和修改這些屬性變得更加復(fù)雜。有些服務(wù)可能會(huì)下降，而某些位置可能會(huì)發(fā)生變化。手動(dòng)更改屬性可能會(huì)產(chǎn)生問題。 Eureka 服務(wù)注冊(cè)和發(fā)現(xiàn)可以在這種情況下提供幫助。由于所有服務(wù)都在 Eureka 服務(wù)器上注冊(cè)并通過調(diào)用 Eureka 服務(wù)器完成查找，因此無需處理服務(wù)地點(diǎn)的任何更改和處理。

4、Spring Cloud 和dubbo區(qū)別?

（1）服務(wù)調(diào)用方式 dubbo是RPC springcloud Rest Api

（2）注冊(cè)中心,dubbo 是zookeeper springcloud是eureka，也可以是zookeeper

（3）服務(wù)網(wǎng)關(guān),dubbo本身沒有實(shí)現(xiàn)，只能通過其他第三方技術(shù)整合，springcloud有Zuul路由網(wǎng)關(guān)，作為路由服務(wù)器，進(jìn)行消費(fèi)者的請(qǐng)求分發(fā),springcloud支持?jǐn)嗦菲?#xff0c;與git完美集成配置文件支持版本控制，事物總線實(shí)現(xiàn)配置文件的更新與服務(wù)自動(dòng)裝配等等一系列的微服務(wù)架構(gòu)要素。

5、SpringBoot和SpringCloud的區(qū)別？

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

SpringCloud是關(guān)注全局的微服務(wù)協(xié)調(diào)整理治理框架，它將SpringBoot開發(fā)的一個(gè)個(gè)單體微服務(wù)整合并管理起來，

為各個(gè)微服務(wù)之間提供，配置管理、服務(wù)發(fā)現(xiàn)、斷路器、路由、微代理、事件總線、全局鎖、決策競(jìng)選、分布式會(huì)話等等集成服務(wù)

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

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

6、負(fù)載平衡的意義什么？

在計(jì)算中，負(fù)載平衡可以改善跨計(jì)算機(jī)，計(jì)算機(jī)集群，網(wǎng)絡(luò)鏈接，中央處理單元或磁盤驅(qū)動(dòng)器等多種計(jì)算資源的工作負(fù)載分布。負(fù)載平衡旨在優(yōu)化資源使用，最大化吞吐量，最小化響應(yīng)時(shí)間并避免任何單一資源的過載。使用多個(gè)組件進(jìn)行負(fù)載平衡而不是單個(gè)組件可能會(huì)通過冗余來提高可靠性和可用性。負(fù)載平衡通常涉及專用軟件或硬件，例如多層交換機(jī)或域名系統(tǒng)服務(wù)器進(jìn)程。

7、什么是 Hystrix？它如何實(shí)現(xiàn)容錯(cuò)？

Hystrix 是一個(gè)延遲和容錯(cuò)庫(kù)，旨在隔離遠(yuǎn)程系統(tǒng)，服務(wù)和第三方庫(kù)的訪問點(diǎn)，當(dāng)出現(xiàn)故障是不可避免的故障時(shí)，停止級(jí)聯(lián)故障并在復(fù)雜的分布式系統(tǒng)中實(shí)現(xiàn)彈性。

通常對(duì)于使用微服務(wù)架構(gòu)開發(fā)的系統(tǒng)，涉及到許多微服務(wù)。這些微服務(wù)彼此協(xié)作。

思考以下微服務(wù)

假設(shè)如果上圖中的微服務(wù) 9 失敗了，那么使用傳統(tǒng)方法我們將傳播一個(gè)異常。但這仍然會(huì)導(dǎo)致整個(gè)系統(tǒng)崩潰。

隨著微服務(wù)數(shù)量的增加，這個(gè)問題變得更加復(fù)雜。微服務(wù)的數(shù)量可以高達(dá) 1000.這是 hystrix 出現(xiàn)的地方 我們將使用 Hystrix 在這種情況下的 Fallback 方法功能。我們有兩個(gè)服務(wù) employee-consumer 使用由 employee-consumer 公開的服務(wù)。

簡(jiǎn)化圖如下所示

現(xiàn)在假設(shè)由于某種原因，employee-producer 公開的服務(wù)會(huì)拋出異常。我們?cè)谶@種情況下使用 Hystrix 定義了一個(gè)回退方法。這種后備方法應(yīng)該具有與公開服務(wù)相同的返回類型。如果暴露服務(wù)中出現(xiàn)異常，則回退方法將返回一些值。

8、什么是 Hystrix 斷路器？我們需要它嗎？

由于某些原因，employee-consumer 公開服務(wù)會(huì)引發(fā)異常。在這種情況下使用Hystrix 我們定義了一個(gè)回退方法。如果在公開服務(wù)中發(fā)生異常，則回退方法返回一些默認(rèn)值。

如果 firstPage method() 中的異常繼續(xù)發(fā)生，則 Hystrix 電路將中斷，并且員工使用者將一起跳過 firtsPage 方法，并直接調(diào)用回退方法。 斷路器的目的是給第一頁方法或第一頁方法可能調(diào)用的其他方法留出時(shí)間，并導(dǎo)致異?；謴?fù)?？赡馨l(fā)生的情況是，在負(fù)載較小的情況下，導(dǎo)致異常的問題有更好的恢復(fù)機(jī)會(huì) 。

9、什么是 Netflix Feign？它的優(yōu)點(diǎn)是什么？

Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 啟發(fā)的 java 客戶端聯(lián)編程序。

Feign 的第一個(gè)目標(biāo)是將約束分母的復(fù)雜性統(tǒng)一到 http apis，而不考慮其穩(wěn)定性。

在 employee-consumer 的例子中，我們使用了 employee-producer 使用 REST模板公開的 REST 服務(wù)。

但是我們必須編寫大量代碼才能執(zhí)行以下步驟

（1）使用功能區(qū)進(jìn)行負(fù)載平衡。

（2）獲取服務(wù)實(shí)例，然后獲取基本 URL。

（3）利用 REST 模板來使用服務(wù)。 前面的代碼如下

@Controller public class ConsumerControllerClient {@Autowiredprivate LoadBalancerClient loadBalancer;public void getEmployee() throws RestClientException, IOException {ServiceInstance serviceInstance=loadBalancer.choose("employee-producer");System.out.println(serviceInstance.getUri());String baseUrl=serviceInstance.getUri().toString();baseUrl=baseUrl+"/employee";RestTemplate restTemplate = new RestTemplate();ResponseEntity<String> response=null;try{response=restTemplate.exchange(baseUrl,HttpMethod.GET, getHeaders(),String.class);}catch (Exception ex){System.out.println(ex);}System.out.println(response.getBody());}

之前的代碼，有像 NullPointer 這樣的例外的機(jī)會(huì)，并不是最優(yōu)的。我們將看到如何使用 Netflix Feign 使呼叫變得更加輕松和清潔。如果 Netflix Ribbon 依賴關(guān)系也在類路徑中，那么 Feign 默認(rèn)也會(huì)負(fù)責(zé)負(fù)載平衡。

10、什么是 Spring Cloud Bus？我們需要它嗎？

考慮以下情況：我們有多個(gè)應(yīng)用程序使用 Spring Cloud Config 讀取屬性，而Spring Cloud Config 從 GIT 讀取這些屬性。

下面的例子中多個(gè)員工生產(chǎn)者模塊從 Employee Config Module 獲取 Eureka 注冊(cè)的財(cái)產(chǎn)。

如果假設(shè) GIT 中的 Eureka 注冊(cè)屬性更改為指向另一臺(tái) Eureka 服務(wù)器，會(huì)發(fā)生什么情況。在這種情況下，我們將不得不重新啟動(dòng)服務(wù)以獲取更新的屬性。

還有另一種使用執(zhí)行器端點(diǎn)/刷新的方式。但是我們將不得不為每個(gè)模塊單獨(dú)調(diào)用這個(gè) url。例如，如果 Employee Producer1 部署在端口 8080 上，則調(diào)用 http：// localhost：8080 / refresh。同樣對(duì)于 Employee Producer2 http：//localhost：8081 / refresh 等等。這又很麻煩。這就是 Spring Cloud Bus 發(fā)揮作用的地方。

Spring Cloud Bus 提供了跨多個(gè)實(shí)例刷新配置的功能。因此，在上面的示例中，如果我們刷新 Employee Producer1，則會(huì)自動(dòng)刷新所有其他必需的模塊。如果我們有多個(gè)微服務(wù)啟動(dòng)并運(yùn)行，這特別有用。這是通過將所有微服務(wù)連接到單個(gè)消息代理來實(shí)現(xiàn)的。無論何時(shí)刷新實(shí)例，此事件都會(huì)訂閱到偵聽此代理的所有微服務(wù)，并且它們也會(huì)刷新。可以通過使用端點(diǎn)/總線/刷新來實(shí)現(xiàn)對(duì)任何單個(gè)實(shí)例的刷新。

11.springcloud斷路器的作用

當(dāng)一個(gè)服務(wù)調(diào)用另一個(gè)服務(wù)由于網(wǎng)絡(luò)原因或自身原因出現(xiàn)問題，調(diào)用者就會(huì)等待被調(diào)用者的響應(yīng) 當(dāng)更多的服務(wù)請(qǐng)求到這些資源導(dǎo)致更多的請(qǐng)求等待，發(fā)生連鎖效應(yīng)（雪崩效應(yīng)）

斷路器有完全打開狀態(tài):一段時(shí)間內(nèi) 達(dá)到一定的次數(shù)無法調(diào)用 并且多次監(jiān)測(cè)沒有恢復(fù)的跡象 斷路器完全打開 那么下次請(qǐng)求就不會(huì)請(qǐng)求到該服務(wù)

半開:短時(shí)間內(nèi) 有恢復(fù)跡象 斷路器會(huì)將部分請(qǐng)求發(fā)給該服務(wù)，正常調(diào)用時(shí) 斷路器關(guān)閉

關(guān)閉：當(dāng)服務(wù)一直處于正常狀態(tài) 能正常調(diào)用

12、什么是SpringCloudConfig?

在分布式系統(tǒng)中，由于服務(wù)數(shù)量巨多，為了方便服務(wù)配置文件統(tǒng)一管理，實(shí)時(shí)更新，所以需要分布式配置中心組件。在Spring Cloud中，有分布式配置中心組件spring cloud config ，它支持配置服務(wù)放在配置服務(wù)的內(nèi)存中（即本地），也支持放在遠(yuǎn)程Git倉(cāng)庫(kù)中。在spring cloud config 組件中，分兩個(gè)角色，一是config server，二是config client。

使用：

（1）添加pom依賴

（2）配置文件添加相關(guān)配置

（3）啟動(dòng)類添加注解@EnableConfigServer

13、Spring Cloud Gateway?

Spring Cloud Gateway是Spring Cloud官方推出的第二代網(wǎng)關(guān)框架，取代Zuul網(wǎng)關(guān)。網(wǎng)關(guān)作為流量的，在微服務(wù)系統(tǒng)中有著非常作用，網(wǎng)關(guān)常見的功能有路由轉(zhuǎn)發(fā)、權(quán)限校驗(yàn)、限流控制等作用。

使用了一個(gè)RouteLocatorBuilder的bean去創(chuàng)建路由，除了創(chuàng)建路由RouteLocatorBuilder可以讓你添加各種predicates和filters，predicates斷言的意思，顧名思義就是根據(jù)具體的請(qǐng)求的規(guī)則，由具體的route去處理，filters是各種過濾器，用來對(duì)請(qǐng)求做各種判斷和修改。

總結(jié)

以上是生活随笔為你收集整理的Java微服务面试题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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