頂級微服務(wù)面試問題

根據(jù)Gartner的說法，微服務(wù)是云開發(fā)的新應(yīng)用平臺。微服務(wù)是獨立部署和管理的，一旦在容器內(nèi)實現(xiàn)，它們與底層操作系統(tǒng)的交互很少。 因此，如果您計劃在微服務(wù)中開始您的職業(yè)生涯，那么現(xiàn)在正是潛入技術(shù)處于新生狀態(tài)的時候。因此，為了幫助您準(zhǔn)備面試，我提出了微服務(wù)面試問題和答案博客。

在這個微服務(wù)面試問題博客中，我收集了面試官最常問的問題。這些問題是在咨詢微服務(wù)和相關(guān)技術(shù)領(lǐng)域的頂級行業(yè)專家后收集的。

如果您最近參加過任何微服務(wù)面試，請將這些面試問題粘貼到評論部分，我們會盡快回答。如果您有任何疑問，也可以在下面發(fā)表評論，這可能會在您的微服務(wù)面試中遇到。

您可以瀏覽微服務(wù)面試問題和答案的錄音，我們的講師已經(jīng)詳細(xì)解釋了這些主題，并提供了一些示例，可幫助您更好地理解這一概念。

Q1。您對微服務(wù)有何了解？

微服務(wù)，又稱微服務(wù)

架構(gòu)，是一種架構(gòu)風(fēng)格，它將應(yīng)用程序構(gòu)建為以業(yè)務(wù)領(lǐng)域為模型的小型自治服務(wù)集合 。

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

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

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

Q2。微服務(wù)架構(gòu)有哪些優(yōu)勢？

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

• 獨立開發(fā) – 所有微服務(wù)都可以根據(jù)各自的功能輕松開發(fā)
• 獨立部署 – 基于其服務(wù)，可以在任何應(yīng)用程序中單獨部署它們
• 故障隔離 – 即使應(yīng)用程序的一項服務(wù)不起作用，系統(tǒng)仍可繼續(xù)運行
• 混合技術(shù)堆棧 – 可以使用不同的語言和技術(shù)來構(gòu)建同一應(yīng)用程序的不同服務(wù)
• 粒度縮放 – 單個組件可根據(jù)需要進(jìn)行縮放，無需將所有組件縮放在一起

Q3。微服務(wù)有哪些特點？

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

• 解耦 – 系統(tǒng)內(nèi)的服務(wù)很大程度上是分離的。因此，整個應(yīng)用程序可以輕松構(gòu)建，更改和擴展
• 組件化 – 微服務(wù)被視為可以輕松更換和升級的獨立組件
• 業(yè)務(wù)能力 – 微服務(wù)非常簡單，專注于單一功能
• 自治 – 開發(fā)人員和團隊可以彼此獨立工作，從而提高速度
• 持續(xù)交付 – 通過軟件創(chuàng)建，測試和批準(zhǔn)的系統(tǒng)自動化，允許頻繁發(fā)布軟件
• 責(zé)任 – 微服務(wù)不關(guān)注應(yīng)用程序作為項目。相反，他們將應(yīng)用程序視為他們負(fù)責(zé)的產(chǎn)品
• 分散治理 – 重點是使用正確的工具來做正確的工作。這意味著沒有標(biāo)準(zhǔn)化模式或任何技術(shù)模式。開發(fā)人員可以自由選擇最有用的工具來解決他們的問題
• 敏捷 – 微服務(wù)支持敏捷開發(fā)。任何新功能都可以快速開發(fā)并再次丟棄

Q4。設(shè)計微服務(wù)的最佳實踐是什么？

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

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

Q5。微服務(wù)架構(gòu)如何運作？

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

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

• 客戶端 – 來自不同設(shè)備的不同用戶發(fā)送請求。
• 身份提供商 – 驗證用戶或客戶身份并頒發(fā)安全令牌。
• API網(wǎng)關(guān) – 處理客戶端請求。
• 靜態(tài)內(nèi)容 – 容納系統(tǒng)的所有內(nèi)容。
• 管理 – 在節(jié)點上平衡服務(wù)并識別故障。
• 服務(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)程訪問信息。

Q6。微服務(wù)架構(gòu)的優(yōu)缺點是什么？

微服務(wù)架構(gòu)的優(yōu)點

微服務(wù)架構(gòu)的缺點

自由使用不同的技術(shù)	增加故障排除挑戰(zhàn)
每個微服務(wù)都側(cè)重于單一功能	由于遠(yuǎn)程呼叫而增加延遲
支持單個可部署單元	增加了配置和其他操作的工作量
允許經(jīng)常發(fā)布軟件	難以保持交易安全
確保每項服務(wù)的安全性	艱難地跨越各種邊界跟蹤數(shù)據(jù)
多個服務(wù)是并行開發(fā)和部署的	難以在服務(wù)之間進(jìn)行編碼

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

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

• 單片架構(gòu)類似于大容器，其中應(yīng)用程序的所有軟件組件組裝在一起并緊密封裝。
• 一個面向服務(wù)的架構(gòu)是一種相互通信服務(wù)的集合。通信可以涉及簡單的數(shù)據(jù)傳遞，也可以涉及兩個或多個協(xié)調(diào)某些活動的服務(wù)。
• 微服務(wù)架構(gòu)是一種架構(gòu)風(fēng)格，它將應(yīng)用程序構(gòu)建為以業(yè)務(wù)域為模型的小型自治服務(wù)集合。

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

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

• 自動化組件：難以自動化，因為有許多較小的組件。因此，對于每個組件，我們必須遵循Build，Deploy和Monitor的各個階段。
• 易感性：將大量組件維護在一起變得難以部署，維護，監(jiān)控和識別問題。它需要在所有組件周圍具有很好的感知能力。
• 配置管理：有時在各種環(huán)境中維護組件的配置變得困難。
• 調(diào)試：很難找到錯誤的每一項服務(wù)。維護集中式日志記錄和儀表板以調(diào)試問題至關(guān)重要。

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

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

SOA

微服務(wù)

遵循“ 盡可能多的共享 ”架構(gòu)方法	遵循“ 盡可能少分享 ”的架構(gòu)方法
重要性在于 業(yè)務(wù)功能 重用	重要性在于“ 有界背景 ” 的概念
他們有 共同的 治理 和標(biāo)準(zhǔn)	他們專注于 人們的 合作 和其他選擇的自由
使用 企業(yè)服務(wù)總線（ESB） 進(jìn)行通信	簡單的消息系統(tǒng)
它們支持 多種消息協(xié)議	他們使用 輕量級協(xié)議 ，如 HTTP / REST 等。
多線程， 有更多的開銷來處理I / O.	單線程 通常使用Event Loop功能進(jìn)行非鎖定I / O處理
最大化應(yīng)用程序服務(wù)可重用性	專注于 解耦
傳統(tǒng)的關(guān)系數(shù)據(jù)庫 更常用	現(xiàn)代 關(guān)系數(shù)據(jù)庫 更常用
系統(tǒng)的變化需要修改整體	系統(tǒng)的變化是創(chuàng)造一種新的服務(wù)
DevOps / Continuous Delivery正在變得流行，但還不是主流	專注于DevOps /持續(xù)交付

Q10。微服務(wù)有什么特點？

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

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

Q11。什么是領(lǐng)域驅(qū)動設(shè)計？

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

Q12。為什么需要域驅(qū)動設(shè)計（DDD）？

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

Q13。什么是無所不在的語言？

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

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

Q14。什么是凝聚力？

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

Q15。什么是耦合？

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

Q16。什么是REST / RESTful以及它的用途是什么？

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

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

Q17。你對Spring Boot有什么了解？

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

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

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

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

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

Q19。什么是Spring Cloud？

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

Q20。Spring Cloud解決了哪些問題？

在使用Spring Boot開發(fā)分布式微服務(wù)時，我們面臨的問題很少由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)跨多個計算資源（例如計算機集群，網(wǎng)絡(luò)鏈接，中央處理單元）的工作負(fù)載分布。
• 減少性能問題 – 減少因各種操作開銷導(dǎo)致的性能問題。

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

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

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

休息

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

微服務(wù)

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

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

Q23。什么是不同類型的微服務(wù)測試？

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

• 在底層，我們有面向技術(shù)的測試，如單元測試和性能測試。這些是完全自動化的。
• 在中間層面，我們進(jìn)行了諸如壓力測試和可用性測試之類的探索性測試。
• 在頂層， 我們的 驗收測試數(shù)量很少。這些驗收測試有助于利益相關(guān)者理解和驗證軟件功能。

Q24。您對Distributed Transaction有何了解？

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

Q25。什么是Idempotence以及它在哪里使用？

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

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

Q26。什么是有界上下文？

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

Q27。什么是雙因素身份驗證？

雙因素身份驗證為帳戶登錄過程啟用第二級身份驗證。

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

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

Q28。雙因素身份驗證的憑據(jù)類型有哪些？

這三種憑證是：

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

Q29。什么是客戶證書？

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

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

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

微服務(wù)中的用法：

• 用于在微服務(wù)中實現(xiàn)消費者驅(qū)動的合同。
• 測試微服務(wù)的消費者和提供者之間的消費者驅(qū)動的合同。

查看即將到來的批次

Q31。什么是OAuth？

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

Q32?？低墒鞘裁?#xff1f;

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

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

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

Q33。合同測試你懂什么？

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

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

Q34。什么是端到端微服務(wù)測試？

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

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

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

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

容器是管理基于微服務(wù)的應(yīng)用程序以便單獨開發(fā)和部署它們的好方法

。您可以將微服務(wù)封裝在容器映像及其依賴項中，然后可以使用它來滾動按需實例的微服務(wù)，而無需任何額外的工作。

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

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

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

Q37。什么是消費者驅(qū)動的合同（CDC）？

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

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

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

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

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

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

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

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

Q41。我們?nèi)绾卧跍y試中消除非決定論？

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

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

隔離

異步

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

隔離

時間

資源泄漏

Q42。Mock或Stub有什么區(qū)別？

存根

• 一個有助于運行測試的虛擬對象。
• 在某些可以硬編碼的條件下提供固定行為。
• 永遠(yuǎn)不會測試存根的任何其他行為。

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

嘲笑

• 一個虛擬對象，其中最初設(shè)置了某些屬性。
• 此對象的行為取決于set屬性。
• 也可以測試對象的行為。

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

Q43。您對Mike Cohn的測試金字塔了解多少？

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

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

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

Q44。Docker的目的是什么？

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

因此，這個打包的產(chǎn)品被稱為Container，因為它是由Docker完成的，所以它被稱為Docker容器！

Q45。什么是金絲雀釋放？

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

Q46。什么是持續(xù)集成（CI）？

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

Q47。什么是持續(xù)監(jiān)測？

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

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

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

• 決定整個軟件系統(tǒng)的布局。
• 幫助確定組件的分區(qū)。因此，他們確保組件相互粘合，但不緊密耦合。
• 與開發(fā)人員共同編寫代碼，了解日常生活中面臨的挑戰(zhàn)。
• 為開發(fā)微服務(wù)的團隊提供某些工具和技術(shù)的建議。
• 提供技術(shù)治理，以便技術(shù)開發(fā)團隊遵循微服務(wù)原則。

• 這里推薦一下我的Java后端技術(shù)群： 834962734，群里有（分布式架構(gòu)、高可擴展、高性能、高并發(fā)、性能優(yōu)化、Spring boot、Redis、ActiveMQ、等學(xué)習(xí)資源）進(jìn)群免費送給每一位Java小伙伴，不管你是轉(zhuǎn)行，還是工作中想提升自己能力都可以！

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

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

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

Q50。什么是微服務(wù)中的反應(yīng)性擴展？

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

總結(jié)

以上是生活随笔為你收集整理的进大厂必须掌握的50个微服务面试问题！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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