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

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

通俗地說(shuō)，你必須看到蜜蜂如何通過(guò)對(duì)齊六角形蠟細(xì)胞來(lái)構(gòu)建它們的蜂窩狀物。他們最初從使用各種材料的小部分開(kāi)始，并繼續(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ù)訪談問(wèn)題

請(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ù)組件的問(wèn)題，而對(duì)整個(gè)應(yīng)用程序沒(méi)有影響或影響最小。

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

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

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

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

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

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

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

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

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

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

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

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

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

· 持續(xù)交付 – 通過(guò)軟件創(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)是使用正確的工具來(lái)做正確的工作。這意味著沒(méi)有標(biāo)準(zhǔn)化模式或任何技術(shù)模式。開(kāi)發(fā)人員可以自由選擇最有用的工具來(lái)解決他們的問(wèn)題

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

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

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

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

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

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

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

· 客戶端 – 來(lái)自不同設(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)程訪問(wèn)信息。

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

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

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

· 單片架構(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)？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13、什么是無(wú)所不在的語(yǔ)言？

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

無(wú)處不在的語(yǔ)言必須非常清晰，以便它將所有團(tuán)隊(duì)成員放在同一頁(yè)面上，并以機(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)通過(guò) 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í)上，隨著新功能的增加，彈簧變得越來(lái)越復(fù)雜。如果必須啟動(dòng)新的 spring 項(xiàng)目，則必須添加構(gòu)建路徑或添加 maven 依賴項(xiàng)，配置應(yīng)用程序服務(wù)器，添加 spring配置。所以一切都必須從頭開(kāi)始。

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

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

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

Spring Boot 執(zhí)行程序提供了 restful Web 服務(wù)，以訪問(wèn)生產(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 為開(kāi)發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見(jiàn)模式的工具（例如配置管理，服務(wù)發(fā)現(xiàn)，斷路器，智能路由，領(lǐng)導(dǎo)選舉，分布式會(huì)話，集群狀態(tài)）。

20、Spring Cloud 解決了哪些問(wèn)題？

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

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

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

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

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

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

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)？

雖然您可以通過(guò)多種方式實(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)而言之，您可以說(shuō) 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ò)將大型模型劃分為不同的有界上下文并明確其相互關(guān)系來(lái)處理大型模型。

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

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

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

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

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

這三種憑證是：

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

29、什么是客戶證書(shū)？

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

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

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

微服務(wù)中的用法

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

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

查看即將到來(lái)的批次

31、什么是 OAuth？

OAuth 代表開(kāi)放授權(quán)協(xié)議。這允許通過(guò)在 HTTP 服務(wù)上啟用客戶端應(yīng)用程序（例如第三方提供商 Facebook，GitHub 等）來(lái)訪問(wèn)資源所有者的資源。因此，您可以在不使用其憑據(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ù)訪談問(wèn)題

該法律基本上試圖傳達(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 的說(shuō)法，合同測(cè)試是在外部服務(wù)邊界進(jìn)行的測(cè)試，用于驗(yàn)證其是否符合消費(fèi)服務(wù)預(yù)期的合同。

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

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

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

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

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

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

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

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

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

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

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

這基本上是用于開(kāi)發(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 的開(kāi)放網(wǎng)絡(luò)原則，為構(gòu)建微服務(wù)架構(gòu)的各個(gè)組件之間的接口提供了最合理的模型。

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

語(yǔ)義監(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)證，即那些無(wú)法像普通功能那樣實(shí)現(xiàn)的需求。

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

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

從測(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ì)象，您可以通過(guò)設(shè)置名稱和年齡來(lái)模擬它。您可以將 age設(shè)置為 12，然后測(cè)試 isAdult（）方法，該方法將在年齡大于 18 時(shí)返回 true。因此，您的 Mock Customer 對(duì)象適用于指定的條件。

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

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

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

根據(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ù)。這是通過(guò)將變更緩慢地推廣到一小部分用戶，然后將其發(fā)布到整個(gè)基礎(chǔ)架構(gòu)，即將其提供給每個(gè)人來(lái)完成的。

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

持續(xù)集成（CI）是每次團(tuán)隊(duì)成員提交版本控制更改時(shí)自動(dòng)構(gòu)建和測(cè)試代碼的過(guò)程。這鼓勵(lì)開(kāi)發(fā)人員通過(guò)在每個(gè)小任務(wù)完成后將更改合并到共享版本控制存儲(chǔ)庫(kù)來(lái)共享代碼和單元測(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ū)。因此，他們確保組件相互粘合，但不緊密耦合。

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

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

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

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

我們知道擁有自己的數(shù)據(jù)庫(kù)的每個(gè)微服務(wù)都是一個(gè)可獨(dú)立部署的程序單元，這反過(guò)來(lái)又讓我們可以創(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ì)方法，我們通過(guò)調(diào)用多個(gè)服務(wù)來(lái)收集結(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 開(kāi)發(fā)分布式微服務(wù)時(shí)，我們面臨以下問(wèn)題

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

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

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

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

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

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

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

當(dāng)我們開(kāi)始一個(gè)項(xiàng)目時(shí)，我們通常在屬性文件中進(jìn)行所有的配置。隨著越來(lái)越多的服務(wù)開(kāi)發(fā)和部署，添加和修改這些屬性變得更加復(fù)雜。有些服務(wù)可能會(huì)下降，而某些位置可能會(huì)發(fā)生變化。手動(dòng)更改屬性可能會(huì)產(chǎn)生問(wèn)題。 Eureka 服務(wù)注冊(cè)和發(fā)現(xiàn)可以在這種情況下提供幫助。由于所有服務(wù)都在 Eureka 服務(wù)器上注冊(cè)并通過(guò)調(diào)用 Eureka 服務(wù)器完成查找，因此無(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本身沒(méi)有實(shí)現(xiàn)，只能通過(guò)其他第三方技術(shù)整合，springcloud有Zuul路由網(wǎng)關(guān)，作為路由服務(wù)器，進(jìn)行消費(fèi)者的請(qǐng)求分發(fā),springcloud支持?jǐn)嗦菲鳎cgit完美集成配置文件支持版本控制，事物總線實(shí)現(xiàn)配置文件的更新與服務(wù)自動(dòng)裝配等等一系列的微服務(wù)架構(gòu)要素。

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

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ù)治理框架。

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

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

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

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

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

思考以下微服務(wù)

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

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

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

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

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

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

如果 firstPage method() 中的異常繼續(xù)發(fā)生，則 Hystrix 電路將中斷，并且員工使用者將一起跳過(guò) firtsPage 方法，并直接調(diào)用回退方法。 斷路器的目的是給第一頁(yè)方法或第一頁(yè)方法可能調(diào)用的其他方法留出時(shí)間，并導(dǎo)致異常恢復(fù)?？赡馨l(fā)生的情況是，在負(fù)載較小的情況下，導(dǎo)致異常的問(wèn)題有更好的恢復(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模板公開(kāi)的 REST 服務(wù)。

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

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

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

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

@Controller
public class ConsumerControllerClient {
    @Autowired
    private 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)行，這特別有用。這是通過(guò)將所有微服務(wù)連接到單個(gè)消息代理來(lái)實(shí)現(xiàn)的。無(wú)論何時(shí)刷新實(shí)例，此事件都會(huì)訂閱到偵聽(tīng)此代理的所有微服務(wù)，并且它們也會(huì)刷新。可以通過(guò)使用端點(diǎn)/總線/刷新來(lái)實(shí)現(xiàn)對(duì)任何單個(gè)實(shí)例的刷新。

11.springcloud斷路器的作用

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

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

半開(kāi):短時(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)常見(jià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是各種過(guò)濾器，用來(lái)對(duì)請(qǐng)求做各種判斷和修改。

Spring Boot面試題

1、什么是 Spring Boot？

多年來(lái)，隨著新功能的增加，spring 變得越來(lái)越復(fù)雜。訪問(wèn)spring官網(wǎng)頁(yè)面，我們就會(huì)看到可以在我們的應(yīng)用程序中使用的所有 Spring 項(xiàng)目的不同功能。如果必須啟動(dòng)一個(gè)新的 Spring 項(xiàng)目，我們必須添加構(gòu)建路徑或添加 Maven 依賴關(guān)系，配置應(yīng)用程序服務(wù)器，添加 spring 配置。因此，開(kāi)始一個(gè)新的 spring 項(xiàng)目需要很多努力，因?yàn)槲覀儸F(xiàn)在必須從頭開(kāi)始做所有事情。

Spring Boot 是解決這個(gè)問(wèn)題的方法。Spring Boot 已經(jīng)建立在現(xiàn)有 spring 框架之上。使用 spring 啟動(dòng)，我們避免了之前我們必須做的所有樣板代碼和配置。因此，Spring Boot 可以幫助我們以最少的工作量，更加健壯地使用現(xiàn)有的 Spring功能。

2、Spring Boot 有哪些優(yōu)點(diǎn)？

Spring Boot 的優(yōu)點(diǎn)有：

1、減少開(kāi)發(fā)，測(cè)試時(shí)間和努力。

2、使用 JavaConfig 有助于避免使用 XML。

3、避免大量的 Maven 導(dǎo)入和各種版本沖突。

4、提供意見(jiàn)發(fā)展方法。

5、通過(guò)提供默認(rèn)值快速開(kāi)始開(kāi)發(fā)。

6、沒(méi)有單獨(dú)的 Web 服務(wù)器需要。這意味著你不再需要啟動(dòng) Tomcat，Glassfish或其他任何東西。

7、需要更少的配置 因?yàn)闆](méi)有 web.xml 文件。只需添加用@ Configuration 注釋的類，然后添加用@Bean 注釋的方法，Spring 將自動(dòng)加載對(duì)象并像以前一樣對(duì)其進(jìn)行管理。您甚至可以將@Autowired 添加到 bean 方法中，以使 Spring 自動(dòng)裝入需要的依賴關(guān)系中。

8、基于環(huán)境的配置 使用這些屬性，您可以將您正在使用的環(huán)境傳遞到應(yīng)用程序：-Dspring.profiles.active = {enviornment}。在加載主應(yīng)用程序?qū)傩晕募?，Spring 將在（application{environment} .properties）中加載后續(xù)的應(yīng)用程序?qū)傩晕募?/p>

3、什么是 JavaConfig？

Spring JavaConfig 是 Spring 社區(qū)的產(chǎn)品，它提供了配置 Spring IoC 容器的純Java 方法。因此它有助于避免使用 XML 配置。使用 JavaConfig 的優(yōu)點(diǎn)在于：

（1）面向?qū)ο蟮呐渲谩Ｓ捎谂渲帽欢x為 JavaConfig 中的類，因此用戶可以充分利用 Java 中的面向?qū)ο蠊δ?。一個(gè)配置類可以繼承另一個(gè)，重寫(xiě)它的@Bean 方法等。

（2）減少或消除 XML 配置。基于依賴注入原則的外化配置的好處已被證明。但是，許多開(kāi)發(fā)人員不希望在 XML 和 Java 之間來(lái)回切換。JavaConfig 為開(kāi)發(fā)人員提供了一種純 Java 方法來(lái)配置與 XML 配置概念相似的 Spring 容器。從技術(shù)角度來(lái)講，只使用 JavaConfig 配置類來(lái)配置容器是可行的，但實(shí)際上很多人認(rèn)為將JavaConfig 與 XML 混合匹配是理想的。

（3）類型安全和重構(gòu)友好。JavaConfig 提供了一種類型安全的方法來(lái)配置 Spring容器。由于 Java 5.0 對(duì)泛型的支持，現(xiàn)在可以按類型而不是按名稱檢索 bean，不需要任何強(qiáng)制轉(zhuǎn)換或基于字符串的查找。

4、如何重新加載 Spring Boot 上的更改，而無(wú)需重新啟動(dòng)服務(wù)器？

這可以使用 DEV 工具來(lái)實(shí)現(xiàn)。通過(guò)這種依賴關(guān)系，您可以節(jié)省任何更改，嵌入式tomcat 將重新啟動(dòng)。Spring Boot 有一個(gè)開(kāi)發(fā)工具（DevTools）模塊，它有助于提高開(kāi)發(fā)人員的生產(chǎn)力。Java 開(kāi)發(fā)人員面臨的一個(gè)主要挑戰(zhàn)是將文件更改自動(dòng)部署到服務(wù)器并自動(dòng)重啟服務(wù)器。開(kāi)發(fā)人員可以重新加載 Spring Boot 上的更改，而無(wú)需重新啟動(dòng)服務(wù)器。這將消除每次手動(dòng)部署更改的需要。Spring Boot 在發(fā)布它的第一個(gè)版本時(shí)沒(méi)有這個(gè)功能。這是開(kāi)發(fā)人員最需要的功能。DevTools 模塊完全滿足開(kāi)發(fā)人員的需求。該模塊將在生產(chǎn)環(huán)境中被禁用。它還提供 H2 數(shù)據(jù)庫(kù)控制臺(tái)以更好地測(cè)試應(yīng)用程序。

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<optional>true</optional>

5、Spring Boot 中的監(jiān)視器是什么？

Spring boot actuator 是 spring 啟動(dòng)框架中的重要功能之一。Spring boot 監(jiān)視器可幫助您訪問(wèn)生產(chǎn)環(huán)境中正在運(yùn)行的應(yīng)用程序的當(dāng)前狀態(tài)。有幾個(gè)指標(biāo)必須在生產(chǎn)環(huán)境中進(jìn)行檢查和監(jiān)控。即使一些外部應(yīng)用程序可能正在使用這些服務(wù)來(lái)向相關(guān)人員觸發(fā)警報(bào)消息。監(jiān)視器模塊公開(kāi)了一組可直接作為 HTTP URL 訪問(wèn)的REST 端點(diǎn)來(lái)檢查狀態(tài)。

6、如何在 Spring Boot 中禁用 Actuator 端點(diǎn)安全性？

默認(rèn)情況下，所有敏感的 HTTP 端點(diǎn)都是安全的，只有具有 ACTUATOR 角色的用戶才能訪問(wèn)它們。安全性是使用標(biāo)準(zhǔn)的 HttpServletRequest.isUserInRole 方法實(shí)施的。 我們可以使用來(lái)禁用安全性。只有在執(zhí)行機(jī)構(gòu)端點(diǎn)在防火墻后訪問(wèn)時(shí)，才建議禁用安全性。

7、如何在自定義端口上運(yùn)行 Spring Boot 應(yīng)用程序？

為了在自定義端口上運(yùn)行 Spring Boot 應(yīng)用程序，您可以在application.properties 中指定端口。server.port = 8090

8、什么是 YAML？

YAML 是一種人類可讀的數(shù)據(jù)序列化語(yǔ)言。它通常用于配置文件。與屬性文件相比，如果我們想要在配置文件中添加復(fù)雜的屬性，YAML 文件就更加結(jié)構(gòu)化，而且更少混淆?？梢钥闯?YAML 具有分層配置數(shù)據(jù)。

9、如何實(shí)現(xiàn) Spring Boot 應(yīng)用程序的安全性？

為了實(shí)現(xiàn) Spring Boot 的安全性，我們使用 spring-boot-starter-security 依賴項(xiàng)，并且必須添加安全配置。它只需要很少的代碼。配置類將必須擴(kuò)展WebSecurityConfigurerAdapter 并覆蓋其方法。

10、如何集成 Spring Boot 和 ActiveMQ？

對(duì)于集成 Spring Boot 和 ActiveMQ，我們使用依賴關(guān)系。 它只需要很少的配置，并且不需要樣板代碼。

11、如何使用 Spring Boot 實(shí)現(xiàn)分頁(yè)和排序？

使用 Spring Boot 實(shí)現(xiàn)分頁(yè)非常簡(jiǎn)單。使用 Spring Data-JPA 可以實(shí)現(xiàn)將可分頁(yè)的傳遞給存儲(chǔ)庫(kù)方法。

12、什么是 Swagger？你用 Spring Boot 實(shí)現(xiàn)了它嗎？

Swagger 廣泛用于可視化 API，使用 Swagger UI 為前端開(kāi)發(fā)人員提供在線沙箱。Swagger 是用于生成 RESTful Web 服務(wù)的可視化表示的工具，規(guī)范和完整框架實(shí)現(xiàn)。它使文檔能夠以與服務(wù)器相同的速度更新。當(dāng)通過(guò) Swagger 正確定義時(shí)，消費(fèi)者可以使用最少量的實(shí)現(xiàn)邏輯來(lái)理解遠(yuǎn)程服務(wù)并與其進(jìn)行交互。因此，Swagger消除了調(diào)用服務(wù)時(shí)的猜測(cè)。

13、什么是 Spring Profiles？

Spring Profiles 允許用戶根據(jù)配置文件（dev，test，prod 等）來(lái)注冊(cè) bean。因此，當(dāng)應(yīng)用程序在開(kāi)發(fā)中運(yùn)行時(shí)，只有某些 bean 可以加載，而在 PRODUCTION中，某些其他 bean 可以加載。假設(shè)我們的要求是 Swagger 文檔僅適用于 QA 環(huán)境，并且禁用所有其他文檔。這可以使用配置文件來(lái)完成。Spring Boot 使得使用配置文件非常簡(jiǎn)單。

14、什么是 Spring Batch？

Spring Boot Batch 提供可重用的函數(shù)，這些函數(shù)在處理大量記錄時(shí)非常重要，包括日志/跟蹤，事務(wù)管理，作業(yè)處理統(tǒng)計(jì)信息，作業(yè)重新啟動(dòng)，跳過(guò)和資源管理。它還提供了更先進(jìn)的技術(shù)服務(wù)和功能，通過(guò)優(yōu)化和分區(qū)技術(shù)，可以實(shí)現(xiàn)極高批量和高性能批處理作業(yè)。簡(jiǎn)單以及復(fù)雜的大批量批處理作業(yè)可以高度可擴(kuò)展的方式利用框架處理重要大量的信息。

15、什么是 FreeMarker 模板？

FreeMarker 是一個(gè)基于 Java 的模板引擎，最初專注于使用 MVC 軟件架構(gòu)進(jìn)行動(dòng)態(tài)網(wǎng)頁(yè)生成。使用 Freemarker 的主要優(yōu)點(diǎn)是表示層和業(yè)務(wù)層的完全分離。程序員可以處理應(yīng)用程序代碼，而設(shè)計(jì)人員可以處理 html 頁(yè)面設(shè)計(jì)。最后使用freemarker 可以將這些結(jié)合起來(lái)，給出最終的輸出頁(yè)面。

16、如何使用 Spring Boot 實(shí)現(xiàn)異常處理？

Spring 提供了一種使用 ControllerAdvice 處理異常的非常有用的方法。 我們通過(guò)實(shí)現(xiàn)一個(gè) ControlerAdvice 類，來(lái)處理控制器類拋出的所有異常。

17、您使用了哪些 starter maven 依賴項(xiàng)？

使用了下面的一些依賴項(xiàng)

spring-boot-starter-activemq

spring-boot-starter-security

這有助于增加更少的依賴關(guān)系，并減少版本的沖突。

18、什么是 CSRF 攻擊？

CSRF 代表跨站請(qǐng)求偽造。這是一種攻擊，迫使最終用戶在當(dāng)前通過(guò)身份驗(yàn)證的Web 應(yīng)用程序上執(zhí)行不需要的操作。CSRF 攻擊專門針對(duì)狀態(tài)改變請(qǐng)求，而不是數(shù)據(jù)竊取，因?yàn)楣粽邿o(wú)法查看對(duì)偽造請(qǐng)求的響應(yīng)。

19、什么是 WebSockets？

WebSocket 是一種計(jì)算機(jī)通信協(xié)議，通過(guò)單個(gè) TCP 連接提供全雙工通信信道。

1、WebSocket 是雙向的 -使用 WebSocket 客戶端或服務(wù)器可以發(fā)起消息發(fā)送。

2、WebSocket 是全雙工的 -客戶端和服務(wù)器通信是相互獨(dú)立的。

3、單個(gè) TCP 連接 -初始連接使用 HTTP，然后將此連接升級(jí)到基于套接字的連接。然后這個(gè)單一連接用于所有未來(lái)的通信

4、Light -與 http 相比，WebSocket 消息數(shù)據(jù)交換要輕得多。

20、什么是 AOP？

在軟件開(kāi)發(fā)過(guò)程中，跨越應(yīng)用程序多個(gè)點(diǎn)的功能稱為交叉問(wèn)題。這些交叉問(wèn)題與應(yīng)用程序的主要業(yè)務(wù)邏輯不同。因此，將這些橫切關(guān)注與業(yè)務(wù)邏輯分開(kāi)是面向方面編程（AOP）的地方。

21、什么是 Apache Kafka？

Apache Kafka 是一個(gè)分布式發(fā)布 - 訂閱消息系統(tǒng)。它是一個(gè)可擴(kuò)展的，容錯(cuò)的發(fā)布 - 訂閱消息系統(tǒng)，它使我們能夠構(gòu)建分布式應(yīng)用程序。這是一個(gè) Apache 頂級(jí)項(xiàng)目。Kafka 適合離線和在線消息消費(fèi)。

22、我們?nèi)绾伪O(jiān)視所有 Spring Boot 微服務(wù)？

Spring Boot 提供監(jiān)視器端點(diǎn)以監(jiān)控各個(gè)微服務(wù)的度量。這些端點(diǎn)對(duì)于獲取有關(guān)應(yīng)用程序的信息（如它們是否已啟動(dòng)）以及它們的組件（如數(shù)據(jù)庫(kù)等）是否正常運(yùn)行很有幫助。但是，使用監(jiān)視器的一個(gè)主要缺點(diǎn)或困難是，我們必須單獨(dú)打開(kāi)應(yīng)用程序的知識(shí)點(diǎn)以了解其狀態(tài)或健康狀況。想象一下涉及 50 個(gè)應(yīng)用程序的微服務(wù)，管理員將不得不擊中所有 50 個(gè)應(yīng)用程序的執(zhí)行終端。為了幫助我們處理這種情況，我們將使用位于的開(kāi)源項(xiàng)目。 它建立在 Spring Boot Actuator 之上，它提供了一個(gè) Web UI，使我們能夠可視化多個(gè)應(yīng)用程序的度量。

最后

 到此這篇關(guān)于85道Java微服務(wù)面試題整理,助力2020面試 的文章就介紹到這了,更多相關(guān)Java微服務(wù)面試題內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持腳本之家！

最新評(píng)論