进大厂必须掌握的50个微服务面试问题！
頂級微服務面試問題
根據Gartner的說法，微服務是云開發的新應用平臺。微服務是獨立部署和管理的，一旦在容器內實現，它們與底層操作系統的交互很少。 因此，如果您計劃在微服務中開始您的職業生涯，那么現在正是潛入技術處于新生狀態的時候。因此，為了幫助您準備面試，我提出了微服務面試問題和答案博客。
在這個微服務面試問題博客中，我收集了面試官最常問的問題。這些問題是在咨詢微服務和相關技術領域的頂級行業專家后收集的。
如果您最近參加過任何微服務面試，請將這些面試問題粘貼到評論部分，我們會盡快回答。如果您有任何疑問，也可以在下面發表評論，這可能會在您的微服務面試中遇到。
您可以瀏覽微服務面試問題和答案的錄音，我們的講師已經詳細解釋了這些主題，并提供了一些示例，可幫助您更好地理解這一概念。
Q1。您對微服務有何了解？
微服務，又稱微服務
架構，是一種架構風格，它將應用程序構建為以業務領域為模型的小型自治服務集合 。通俗地說，你必須看到蜜蜂如何通過對齊六角形蠟細胞來構建它們的蜂窩狀物。他們最初從使用各種材料的小部分開始，并繼續從中構建一個大型蜂箱。這些細胞形成圖案，產生堅固的結構，將蜂窩的特定部分固定在一起。這里，每個細胞獨立于另一個細胞，但它也與其他細胞相關。這意味著對一個細胞的損害不會損害其他細胞，因此，蜜蜂可以在不影響完整蜂箱的情況下重建這些細胞。
圖1：微服務的蜂窩表示 – 微服務訪談問題
請參考上圖。這里，每個六邊形形狀代表單獨的服務組件。與蜜蜂的工作類似，每個敏捷團隊都使用可用的框架和所選的技術堆棧構建單獨的服務組件。就像在蜂箱中一樣，每個服務組件形成一個強大的微服務架構，以提供更好的可擴展性。此外，敏捷團隊可以單獨處理每個服務組件的問題，而對整個應用程序沒有影響或影響最小。
Q2。微服務架構有哪些優勢？
圖2：微服務的 優點 – 微服務訪談問題
- 獨立開發 – 所有微服務都可以根據各自的功能輕松開發
- 獨立部署 – 基于其服務，可以在任何應用程序中單獨部署它們
- 故障隔離 – 即使應用程序的一項服務不起作用，系統仍可繼續運行
- 混合技術堆棧 – 可以使用不同的語言和技術來構建同一應用程序的不同服務
- 粒度縮放 – 單個組件可根據需要進行縮放，無需將所有組件縮放在一起
Q3。微服務有哪些特點？
圖3：微服務的 特點 – 微服務訪談問題
- 解耦 – 系統內的服務很大程度上是分離的。因此，整個應用程序可以輕松構建，更改和擴展
- 組件化 – 微服務被視為可以輕松更換和升級的獨立組件
- 業務能力 – 微服務非常簡單，專注于單一功能
- 自治 – 開發人員和團隊可以彼此獨立工作，從而提高速度
- 持續交付 – 通過軟件創建，測試和批準的系統自動化，允許頻繁發布軟件
- 責任 – 微服務不關注應用程序作為項目。相反，他們將應用程序視為他們負責的產品
- 分散治理 – 重點是使用正確的工具來做正確的工作。這意味著沒有標準化模式或任何技術模式。開發人員可以自由選擇最有用的工具來解決他們的問題
- 敏捷 – 微服務支持敏捷開發。任何新功能都可以快速開發并再次丟棄
Q4。設計微服務的最佳實踐是什么？
以下是設計微服務的最佳實踐：
圖4：設計微服務的最佳實踐 – 微服務訪談問題
Q5。微服務架構如何運作？
微服務架構具有以下組件：
圖5：微服務 架構 – 微服務面試問題
- 客戶端 – 來自不同設備的不同用戶發送請求。
- 身份提供商 – 驗證用戶或客戶身份并頒發安全令牌。
- API網關 – 處理客戶端請求。
- 靜態內容 – 容納系統的所有內容。
- 管理 – 在節點上平衡服務并識別故障。
- 服務發現 – 查找微服務之間通信路徑的指南。
- 內容交付網絡 – 代理服務器及其數據中心的分布式網絡。
- 遠程服務 – 啟用駐留在IT設備網絡上的遠程訪問信息。
Q6。微服務架構的優缺點是什么？
自由使用不同的技術 | 增加故障排除挑戰 |
每個微服務都側重于單一功能 | 由于遠程呼叫而增加延遲 |
支持單個可部署單元 | 增加了配置和其他操作的工作量 |
允許經常發布軟件 | 難以保持交易安全 |
確保每項服務的安全性 | 艱難地跨越各種邊界跟蹤數據 |
多個服務是并行開發和部署的 | 難以在服務之間進行編碼 |
Q7。單片，SOA和微服務架構有什么區別？
圖6： 單片SOA和微服務之間的比較 – 微服務訪談問題
- 單片架構類似于大容器，其中應用程序的所有軟件組件組裝在一起并緊密封裝。
- 一個面向服務的架構是一種相互通信服務的集合。通信可以涉及簡單的數據傳遞，也可以涉及兩個或多個協調某些活動的服務。
- 微服務架構是一種架構風格，它將應用程序構建為以業務域為模型的小型自治服務集合。
Q8。在使用微服務架構時，您面臨哪些挑戰？
開發一些較小的微服務聽起來很容易，但開發它們時經常遇到的挑戰如下。
- 自動化組件：難以自動化，因為有許多較小的組件。因此，對于每個組件，我們必須遵循Build，Deploy和Monitor的各個階段。
- 易感性：將大量組件維護在一起變得難以部署，維護，監控和識別問題。它需要在所有組件周圍具有很好的感知能力。
- 配置管理：有時在各種環境中維護組件的配置變得困難。
- 調試：很難找到錯誤的每一項服務。維護集中式日志記錄和儀表板以調試問題至關重要。
Q9。SOA和微服務架構之間的主要區別是什么？
SOA和微服務之間的主要區別如下：
遵循“ 盡可能多的共享 ”架構方法 | 遵循“ 盡可能少分享 ”的架構方法 |
重要性在于 業務功能 重用 | 重要性在于“ 有界背景 ” 的概念 |
他們有 共同的 治理 和標準 | 他們專注于 人們的 合作 和其他選擇的自由 |
使用 企業服務總線（ESB） 進行通信 | 簡單的消息系統 |
它們支持 多種消息協議 | 他們使用 輕量級協議 ，如 HTTP / REST 等。 |
多線程， 有更多的開銷來處理I / O. | 單線程 通常使用Event Loop功能進行非鎖定I / O處理 |
最大化應用程序服務可重用性 | 專注于 解耦 |
傳統的關系數據庫 更常用 | 現代 關系數據庫 更常用 |
系統的變化需要修改整體 | 系統的變化是創造一種新的服務 |
DevOps / Continuous Delivery正在變得流行，但還不是主流 | 專注于DevOps /持續交付 |
Q10。微服務有什么特點？
您可以列出微服務的特征，如下所示：
圖7：微服務的特征 – 微服務訪談問題
Q11。什么是領域驅動設計？
圖8： DDD原理 – 微服務面試問題
Q12。為什么需要域驅動設計（DDD）？
圖9：我們需要DDD的因素 – 微服務面試問題
Q13。什么是無所不在的語言？
如果您必須定義泛在語言（UL），那么它是特定域的開發人員和用戶使用的通用語言，通過該語言可以輕松解釋域。
無處不在的語言必須非常清晰，以便它將所有團隊成員放在同一頁面上，并以機器可以理解的方式進行翻譯。
Q14。什么是凝聚力？
模塊內部元素所屬的程度被認為是凝聚力。
Q15。什么是耦合？
組件之間依賴關系強度的度量被認為是耦合。一個好的設計總是被認為具有高內聚力和低耦合性。
Q16。什么是REST / RESTful以及它的用途是什么？
Representational State Transfer（REST）/ RESTful Web服務是一種幫助計算機系統通過Internet進行通信的架構風格。這使得微服務更容易理解和實現。
微服務可以使用或不使用RESTful API實現，但使用RESTful API構建松散耦合的微服務總是更容易。
Q17。你對Spring Boot有什么了解？
事實上，隨著新功能的增加，彈簧變得越來越復雜。如果必須啟動新的spring項目，則必須添加構建路徑或添加maven依賴項，配置應用程序服務器，添加spring配置。所以一切都必須從頭開始。
Spring Boot是解決這個問題的方法。使用spring boot可以避免所有樣板代碼和配置。因此，基本上認為自己就好像你正在烘烤蛋糕一樣，春天就像制作蛋糕所需的成分一樣，彈簧靴就是你手中的完整蛋糕。
圖10： Spring Boot的因素 – 微服務面試問題
Q18。什么是Spring引導的執行器？
Spring Boot執行程序提供了restful Web服務，以訪問生產環境中運行應用程序的當前狀態。在執行器的幫助下，您可以檢查各種指標并監控您的應用程序。
Q19。什么是Spring Cloud？
根據Spring Cloud的官方網站，Spring Cloud為開發人員提供了快速構建分布式系統中一些常見模式的工具（例如配置管理，服務發現，斷路器，智能路由，領導選舉，分布式會話，集群狀態）。
Q20。Spring Cloud解決了哪些問題？
在使用Spring Boot開發分布式微服務時，我們面臨的問題很少由Spring Cloud解決。
- 與分布式系統相關的復雜性 – 包括網絡問題，延遲開銷，帶寬問題，安全問題。
- 處理服務發現的能力 – 服務發現允許集群中的進程和服務找到彼此并進行通信。
- 解決冗余問題 – 冗余問題經常發生在分布式系統中。
- 負載平衡 – 改進跨多個計算資源（例如計算機集群，網絡鏈接，中央處理單元）的工作負載分布。
- 減少性能問題 – 減少因各種操作開銷導致的性能問題。
Q21。在Spring MVC應用程序中使用WebMvcTest注釋有什么用處？
在測試目標只關注Spring MVC組件的情況下，WebMvcTest注釋用于單元測試Spring MVC應用程序。在上面顯示的快照中，我們只想啟動ToTestController。執行此單元測試時，不會啟動所有其他控制器和映射。
Q22。你能否給出關于休息和微服務的要點？
休息
雖然您可以通過多種方式實現微服務，但REST over HTTP是實現微服務的一種方式。REST還可用于其他應用程序，如Web應用程序，API設計和MVC應用程序，以提供業務數據。
微服務
微服務是一種體系結構，其中系統的所有組件都被放入單獨的組件中，這些組件可以單獨構建，部署和擴展。微服務的某些原則和最佳實踐有助于構建彈性應用程序。
簡而言之，您可以說REST是構建微服務的媒介。
Q23。什么是不同類型的微服務測試？
在使用微服務時，由于有多個微服務協同工作，測試變得非常復雜。因此，測試分為不同的級別。
- 在底層，我們有面向技術的測試，如單元測試和性能測試。這些是完全自動化的。
- 在中間層面，我們進行了諸如壓力測試和可用性測試之類的探索性測試。
- 在頂層， 我們的 驗收測試數量很少。這些驗收測試有助于利益相關者理解和驗證軟件功能。
Q24。您對Distributed Transaction有何了解？
分布式事務是指單個事件導致兩個或多個不能以原子方式提交的單獨數據源的突變的任何情況。在微服務的世界中，它變得更加復雜，因為每個服務都是一個工作單元，并且大多數時候多個服務必須協同工作才能使業務成功。
Q25。什么是Idempotence以及它在哪里使用？
冪等性是能夠以這樣的方式做兩次事情的特性，即最終結果將保持不變，即好像它只做了一次。
用法：在遠程服務或數據源中使用 Idempotence，這樣當它多次接收指令時，它只處理指令一次。
Q26。什么是有界上下文？
有界上下文是域驅動設計的核心模式。DDD戰略設計部門的重點是處理大型模型和團隊。DDD通過將大型模型劃分為不同的有界上下文并明確其相互關系來處理大型模型。
Q27。什么是雙因素身份驗證？
雙因素身份驗證為帳戶登錄過程啟用第二級身份驗證。
圖11： 雙因素認證的表示 – 微服務訪談問題
因此，假設用戶必須只輸入用戶名和密碼，那么這被認為是單因素身份驗證。
Q28。雙因素身份驗證的憑據類型有哪些？
這三種憑證是：
圖12： 雙因素認證的證書類型 – 微服務面試問題
Q29。什么是客戶證書？
客戶端系統用于向遠程服務器發出經過身份驗證的請求的一種數字證書稱為客戶端證書。客戶端證書在許多相互認證設計中起著非常重要的作用，為請求者的身份提供了強有力的保證。
Q30。PACT在微服務架構中的用途是什么？
PACT是一個開源工具，允許測試服務提供者和消費者之間的交互，與合同隔離，從而提高微服務集成的可靠性。
微服務中的用法：
- 用于在微服務中實現消費者驅動的合同。
- 測試微服務的消費者和提供者之間的消費者驅動的合同。
查看即將到來的批次
Q31。什么是OAuth？
OAuth 代表開放授權協議。這允許通過在HTTP服務上啟用客戶端應用程序（例如第三方提供商Facebook，GitHub等）來訪問資源所有者的資源。因此，您可以在不使用其憑據的情況下與另一個站點共享存儲在一個站點上的資源。
Q32。康威定律是什么？
“任何設計系統的組織（廣泛定義）都將產生一種設計，其結構是組織通信結構的副本。” – Mel Conway圖13： Conway定律的表示 – 微服務訪談問題
該法律基本上試圖傳達這樣一個事實：為了使軟件模塊起作用，整個團隊應該進行良好的溝通。因此，系統的結構反映了產生它的組織的社會邊界。
Q33。合同測試你懂什么？
根據Martin Flower的說法，合同測試是在外部服務邊界進行的測試，用于驗證其是否符合消費服務預期的合同。
此外，合同測試不會深入測試服務的行為。更確切地說，它測試該服務調用的輸入＆輸出包含所需的屬性和所述響應延遲，吞吐量是允許的限度內。
Q34。什么是端到端微服務測試？
端到端測試驗證了工作流中的每個流程都正常運行。這可確保系統作為一個整體協同工作并滿足所有要求。
通俗地說，你可以說端到端測試是一種測試，在特定時期后測試所有東西。
圖14：測試層次 – 微服務面試問題
Q35。Container在微服務中的用途是什么？
容器是管理基于微服務的應用程序以便單獨開發和部署它們的好方法
。您可以將微服務封裝在容器映像及其依賴項中，然后可以使用它來滾動按需實例的微服務，而無需任何額外的工作。圖15： 容器的表示及其在微服務中的使用方式 – 微服務訪談問題
Q36。什么是微服務架構中的DRY？
DRY代表不要重復自己。它基本上促進了重用代碼的概念。這導致開發和共享庫，這反過來導致緊密耦合。
Q37。什么是消費者驅動的合同（CDC）？
這基本上是用于開發微服務的模式，以便它們可以被外部系統使用。當我們處理微服務時，有一個特定的提供者構建它，并且有一個或多個使用微服務的消費者。
通常，提供程序在XML文檔中指定接口。但在消費者驅動的合同中，每個服務消費者都傳達了提供商期望的接口。
Q38。 Web，RESTful API在微服務中的作用是什么？
微服務架構基于一個概念，其中所有服務應該能夠彼此交互以構建業務功能。因此，要實現這一點，每個微服務必須具有接口。這使得Web API成為微服務的一個非常重要的推動者。RESTful API基于Web的開放網絡原則，為構建微服務架構的各個組件之間的接口提供了最合理的模型。
Q39。您對微服務架構中的語義監控有何了解？
語義監控，也稱為 綜合監控， 將自動化測試與監控應用程序相結合，以檢測業務失敗因素。
Q40。我們如何進行跨功能測試？
跨功能測試是對非功能性需求的驗證，即那些無法像普通功能那樣實現的需求。
Q41。我們如何在測試中消除非決定論？
非確定性測試（NDT）基本上是不可靠的測試。所以，有時可能會發生它們通過，顯然有時它們也可能會失敗。當它們失敗時，它們會重新運行通過。
從測試中刪除非確定性的一些方法如下：
Q42。Mock或Stub有什么區別？
存根
- 一個有助于運行測試的虛擬對象。
- 在某些可以硬編碼的條件下提供固定行為。
- 永遠不會測試存根的任何其他行為。
例如，對于空堆棧，您可以創建一個只為empty（）方法返回true的存根。因此，這并不關心堆棧中是否存在元素。
嘲笑
- 一個虛擬對象，其中最初設置了某些屬性。
- 此對象的行為取決于set屬性。
- 也可以測試對象的行為。
例如，對于Customer對象，您可以通過設置名稱和年齡來模擬它。您可以將age設置為12，然后測試isAdult（）方法，該方法將在年齡大于18時返回true。因此，您的Mock Customer對象適用于指定的條件。
Q43。您對Mike Cohn的測試金字塔了解多少？
Mike Cohn 提供了一個名為Test Pyramid的模型。這描述了軟件開發所需的自動化測試類型。
圖16： Mike Cohn的測試金字塔 – 微服務面試問題
根據金字塔，第一層的測試數量應該最高。在服務層，測試次數應小于單元測試級別，但應大于端到端級別。
Q44。Docker的目的是什么？
Docker提供了一個可用于托管任何應用程序的容器環境。在此，軟件應用程序和支持它的依賴項緊密打包在一起。
因此，這個打包的產品被稱為Container，因為它是由Docker完成的，所以它被稱為Docker容器！
Q45。什么是金絲雀釋放？
Canary Releasing是一種降低在生產中引入新軟件版本的風險的技術。這是通過將變更緩慢地推廣到一小部分用戶，然后將其發布到整個基礎架構，即將其提供給每個人來完成的。
Q46。什么是持續集成（CI）？
持續集成（CI）是每次團隊成員提交版本控制更改時自動構建和測試代碼的過程。這鼓勵開發人員通過在每個小任務完成后將更改合并到共享版本控制存儲庫來共享代碼和單元測試。
Q47。什么是持續監測？
持續監控深入監控覆蓋范圍，從瀏覽器內前端性能指標，到應用程序性能，再到主機虛擬化基礎架構指標。
Q48。架構師在微服務架構中的角色是什么？
微服務架構中的架構師扮演以下角色：
- 決定整個軟件系統的布局。
- 幫助確定組件的分區。因此，他們確保組件相互粘合，但不緊密耦合。
- 與開發人員共同編寫代碼，了解日常生活中面臨的挑戰。
- 為開發微服務的團隊提供某些工具和技術的建議。
- 提供技術治理，以便技術開發團隊遵循微服務原則。
這里推薦一下我的Java后端技術群： 834962734，群里有（分布式架構、高可擴展、高性能、高并發、性能優化、Spring boot、Redis、ActiveMQ、等學習資源）進群免費送給每一位Java小伙伴，不管你是轉行，還是工作中想提升自己能力都可以！
Q49。我們可以用微服務創建狀態機嗎？
我們知道擁有自己的數據庫的每個微服務都是一個可獨立部署的程序單元，這反過來又讓我們可以創建一個狀態機。因此，我們可以為特定的微服務指定不同的狀態和事件。
例如，我們可以定義Order微服務。訂單可以具有不同的狀態。Order狀態的轉換可以是Order微服務中的獨立事件。
Q50。什么是微服務中的反應性擴展？
Reactive Extensions也稱為Rx。這是一種設計方法，我們通過調用多個服務來收集結果，然后編譯組合響應。這些調用可以是同步或異步，阻塞或非阻塞。Rx是分布式系統中非常流行的工具，與傳統流程相反。
總結
以上是生活随笔為你收集整理的进大厂必须掌握的50个微服务面试问题！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 搜索类软件评价
- 下一篇： django学习（2）----APP