現在，為適應業務的需要，越來越多的企業開始使用微服務架構。
在開發過程中每個獨立服務都有一個業務邊界，可以獨立開發、測試、部署、監控和擴展，甚至可以用不同的編程語言開發。因此，很多企業在招聘的時候都會問微服務相關的問題。
下面是微服務面試常見的50個問題，這些問題是在諮詢微服務和相關技術領域的頂級行業專家後收集的。供大家參考學習，希望對您面試有所幫助。
也可訂閱關注 面試哥 全網同號，獲取更多面試題答案和麵試學習資料。
微服務思維腦圖
微服務面試問題目錄
- 說說微服務架構的優勢。
- 你對微服務是怎麼理解的？
- 微服務有哪些特點？
- 設計微服務的最佳實踐是什麼？
- 微服務架構是如何運作的？
- 微服務架構的優點和缺點是什麼？
- 單體應用、SOA 和微服務架構有什麼區別？
- 在使用微服務架構時，你面臨的挑戰是什麼？
- SOA 和微服務架構之間的主要區別是什麼？
- 微服務有什麼特點？
- 什麼是領域驅動設計（DDD）
- 為什麼需要域驅動設計（DDD）？
- 什麼是通用語言（UL）？
- 什麼是內聚？
- 什麼是耦合？
- 什麼是REST/RESTful ？它的用途是什麼？
- 你怎麼理解 Spring Boot？
- Spring boot 的執行器是什麼？
- 什麼是 Spring Cloud？
- Spring Cloud 解決了哪些問題？
- 在 Spring MVC 中使用 WebMvcTest 註釋有什麼用？
- 你能否給出關於 Rest 和微服務的要點？REST微服務
- 什麼是不同類型的微服務測試？
- 你對分佈式事務的理解？
- 什麼是冪等性（Idempotence）及用在那裡？
- 什麼是有界上下文？
- 什麼是雙因素身份驗證？
- 雙因素身份驗證的憑據類型有哪些？
- 什麼是客戶端證書
- PACT 在微服務架構中的用途是什麼？在微服務中的用法：
- 什麼是OAuth？
- 什麼是康威定律？
- 契約測試（contract test）是什麼？
- 什麼是端到端微服務測試？
- 容器在微服務中的用途是什麼？
- 微服務架構中的DRY是什麼？
- 消費者驅動的契約（CDC）是什麼？
- Web、RESTful API 在微服務中的作用是什麼？
- 你對微服務架構中的語義監控有何瞭解？
- 我們如何進行跨功能測試？
- 如何在測試中消除不確定性？
- Mock 與 Stub 有什麼區別？Stub模擬
- 你對Mike Cohn的測試金字塔瞭解多少？
- Docker 的用途是什麼？
- 什麼是金絲雀發佈（Canary Releasing）？
- 架構師在微服務架構中的角色是什麼？
- 可以用微服務創建狀態機嗎？
- 微服務中的反應性擴展是什麼？
- 微服務設計的基礎是什麼？
1. 說說微服務架構的優勢。
優勢說明 獨立開發所有微服務都可以根據各自的功能輕鬆開發獨立部署根據他們所提供的服務，可以在任何應用中單獨部署故障隔離即使應用中的一個服務不起作用，系統仍然繼續運行混合技術棧可以用不同的語言和技術來構建同一應用程序的不同服務粒度縮放各個組件可根據需要進行擴展，無需將所有組件融合到一起
2. 你對微服務是怎麼理解的？
- 微服務，又名微服務架構，是一種架構風格，它將應用構建為一個小型自治服務的集合，以業務領域為模型。
- 通俗地說，就像蜜蜂通過對蠟制的等邊六角形單元來構建它們的蜂巢。
- 他們最初從使用各種材料的小單元開始，一點點的搭建出一個大型蜂巢。
- 這些小單元組成堅固的結構，將蜂窩的特定部分固定在一起。
- 這裡，每個小單元都獨立於另一個，但它也與其他小單元相關。
- 這意味著對一個小單元的損害不會損害其他的單元，因此，蜜蜂可以在不影響完整蜂巢的情況下重建這些單元。
請參考上圖。這裡，每個六邊形都代表單獨的服務組件。與蜜蜂的工作類似，每個敏捷團隊都使用可用的框架和所選的技術棧構建單獨的服務組件。就像在蜂巢中一樣，這些服務組件形成一個強大的微服務架構，以提供更好的可擴展性。此外敏捷團隊可以單獨處理每個服務組件的問題，而不會對整個應用程序產生影響或使影響最小。
3. 微服務有哪些特點？
- 解耦（Decoupling） - 系統內的服務很大程度上是分離的。因此整個應用可以被輕鬆構建、修改和擴展
- 組件化（Componentization） - 微服務被視為可以被輕鬆替換和升級的獨立組件
- 業務能力（Business Capabilities） - 微服務非常簡單，專注於單一功能
- 自治（Autonomy） - 開發人員和團隊可以相互獨立工作，從而提高效率
- 持續交付（ContinousDelivery） - 允許頻繁發版，通過系統自動化完成對軟件的創建、測試和審核，
- 責任（Responsibility） - 微服務不把程序作為項目去關注。相反，他們將程序視為自己負責的產品
- 分散治理（Decentralized Governance） - 重點是用正確的工具去做正確的事。這意味著沒有任何標準化模式或著技術模式。開發人員可以自由選擇最合適的工具來解決自己的問題
- 敏捷性（Agility） - 微服務支持敏捷開發。任何新功能都可以快速開發並被再次丟棄
4. 設計微服務的最佳實踐是什麼？
以下是設計微服務的最佳實踐：
- 為每個微服務分開數據存儲
- 將代碼保持在類似的成熟度等級上
- 為每個微服務進行單獨的構建
- 部署到容器中
- 將服務器視為無狀態的
5. 微服務架構是如何運作的？
微服務架構具有以下組件：
- Clients – 來自不同設備的不同用戶發送請求。
- Identity Providers – 對用戶或客戶端身份進行身份驗證，並頒發安全令牌。
- API Gateway – 處理客戶端請求。
- Static Content – 容納系統的所有內容。
- Management – 平衡節點上的服務壓力並識別故障。
- Service Discovery – 用於找到微服務之間通信路徑的嚮導。
- Content Delivery Networks – 代理服務器及其數據中心的分佈式網絡。
- Remote Service – 啟用駐留在 IT 設備網絡上的遠程訪問信息。
6. 微服務架構的優點和缺點是什麼？
微服務架構的優點微服務架構的缺點 可以自由使用不同的技術增加故障排除的難度每個微服務都專注於單一功能由於遠程調用而導致延遲增加支持單個可部署單元增加配置和其他操作的工作量允許軟件的持續發佈難以維持處理的安全性可確保每項服務的安全性很難跟蹤各種邊界的數據並行開發和部署多個服務服務之間難以編碼
7. 單體應用、SOA 和微服務架構有什麼區別？
- 單體應用類似於一個大容器，其中程序的所有組件都被組裝在一起並緊密包裝。
- SOA是一組相互通信的服務。通信可以涉及簡單的數據傳送，也可以涉及兩個或多個協調某些活動的服務。
- 微服務架構是一種架構風格，它將應用程序構建為以業務域為模型的小型自治服務集合。
8. 在使用微服務架構時，你面臨的挑戰是什麼？
開發較小的微服務聽起來很容易，但在開發時會經常遇到一些挑戰。
- 自動化組件：難以自動化，因為有許多較小的組件。對於每個組件，都必須採取構建、發佈和監控的步驟。
- 可感知性：將大量組件維持在一起會帶來難以部署、維護、監控和識別的問題。它需要在所有組件周圍具有很好的感知能力。
- 配置管理：有時在各種環境中維護組件的配置會很困難。
- 調試：很難找到與產生的錯誤相關的每一項服務。維護一個集中式的日誌和控制面板對調試問題至關重要。
9. SOA 和微服務架構之間的主要區別是什麼？
SOA 和微服務之間的主要區別如下：
SOA微服務 遵循“儘可能多的共享”架構方法遵循“儘可能少的共享”的架構方法側重點是業務功能重用側重點在於“bounded context”的概念遵循共同治理並有相關的標準專注於人的合作和其他選擇的自由使用企業服務總線（ESB）進行通信簡單的消息系統支持
多消息協議使用輕量級協議，例如 HTTP/REST 等多線程，有更多的開銷來處理I / O單線程，通常使用事件循環進行非鎖定 I/O 處理最大化服務的可重用性專注於解耦使用傳統關係數據庫較多使用現代關係型數據庫較多系統發生變化時需要修改整體系統發生變化是創建一項新服務DevOps和持續交付正在變得流行，但尚未成為主流專注於DevOps和持續交付10 . 微服務有什麼特點？
你可以列出微服務的特徵，如下所示：
- 圍繞業務功能組織團隊
- 做產品而不是做項目
- 基本的消息傳遞框架
- 去中心化治理
- 去中心化管理數據
- 基礎設施自動化
- 容錯設計
11 . 什麼是領域驅動設計（DDD）
- 專注於核心領域邏輯
- 在模型上找到綜合的設計
- 不斷與領域專家合作，改進應用程序模型並解決與領域相關的問題
12. 為什麼需要域驅動設計（DDD）？
- 映射領域
- 降低複雜性
- 可測試性
- 可維護性
- 知識豐富的設計
- 將業務和服務結合在一起
- 上下文集中
- 通用語言
13. 什麼是通用語言（UL）？
如果你必須定義通用語言（UL），那麼它是特定域的開發人員和用戶使用的通用語言，通過該語言可以輕鬆解釋領域。
通用語言必須非常清晰，以便將所有團隊成員處於同一水平線上，並以機器可以理解的方式進行翻譯。
14. 什麼是內聚？
內聚是一個模塊內部各元素之間相關聯程度的度量
15. 什麼是耦合？
組件之間依賴關係強度的度量被稱為耦合。好的設計總是高內聚和低耦合的。
16. 什麼是REST/RESTful ？它的用途是什麼？
Representational State Transfer（REST）/ RESTful （表述性狀態轉移）是一種幫助計算機系統通過 Internet 進行通信的架構風格。這使得微服務更容易理解和實現。
微服務可以用 RESTful API 來實現，當然也可以不用，但是用 RESTful API 去構建鬆散耦合的微服務總是更容易些。
17. 你怎麼理解 Spring Boot？
隨著新功能的增加，spring 變得越來越複雜。如果必須啟動新的 spring 項目，必須添加構建路徑或添加 maven 依賴項，配置服務器，添加 spring 配置。所以一切都必須從頭開始。
Spring Boot 是解決這個問題的方法。使用 spring boot 可以避免所有樣板代碼和配置。因此，基本上認為自己就好像在烤蛋糕一樣，spring 就像做蛋糕所需的原料一樣， spring boot 就是完整的蛋糕。
18. Spring boot 的執行器是什麼？
Spring Boot 執行器提供 restful 服務，以訪問在生產環境中運行程序的當前狀態。在執行器的幫助下，你可以檢查各種指標並監控自己的程序。
19. 什麼是 Spring Cloud？
根據 Spring Cloud 的官方網站，Spring Cloud 為開發人員提供了一些快速構建分佈式系統常見模式的工具（例如配置管理、服務發現、斷路器、智能路由、領導選舉、分佈式會話、集群狀態）。
20. Spring Cloud 解決了哪些問題？
在使用 Spring Boot 開發分佈式微服務時，我們面臨的一些問題可以由 Spring Cloud 解決。
- 與分佈式系統相關的複雜性 - 這包括網絡問題、延遲開銷、帶寬問題、安全問題。
- 處理服務發現的能力 - 服務發現允許群集中的進程和服務找到彼此並進行通信。
- 解決了冗餘問題 - 冗餘問題經常發生在分佈式系統中。
- 負載平衡 - 改進跨多種計算資源（如計算機集群、網絡鏈接、中央處理單元）的工作負載分配。
- 減少性能問題 - 減少因各種操作開銷導致的性能問題。
21. 在 Spring MVC 中使用 WebMvcTest 註釋有什麼用？
<code>@WebMvcTest(value
= ToTestController.class
,secure
=false
): /<code>
WebMvcTest** 註釋用於 Spring MVC 程序的單元測試，其目標是專注於Spring MVC組件。在上面顯示的快照中，我們只想啟動 ToTestController。執行此單元測試時，將不會啟動所有其他控制器和映射。
22. 你能否給出關於 Rest 和微服務的要點？
REST
雖然你可以通過多種方式實現微服務，但 REST over HTTP 是實現微服務的一種方式。 REST 還用於其他應用程序，如 Web 應用、API 設計和 MV C應用以提供業務數據。
微服務
微服務是一種體系結構，其中系統的所有組件都被放入單獨的組件中，這些組件可以單獨構建、部署和擴展。微服務的某些原則和最佳實踐有助於構建彈性應用程序。
簡而言之，你可以認為 REST 是構建微服務的媒介。
23. 什麼是不同類型的微服務測試？
在使用微服務時，由於有多個微服務協同工作，測試變得非常複雜。因此，測試分為不同的級別。
- 在底層，我們有面向技術的測試 —— 單元測試和性能測試。這些是完全自動化的。
- 在中間層，我們有探測性測試，如壓力測試和可用性測試。
- 在頂級，我們有很少的驗收測試。這些驗收測試有助於利益相關者理解和驗證軟件功能。
24. 你對分佈式事務的理解？
分佈式事務是單個事件導致兩個或多個不能以原子方式提交的單獨數據源的突變的情況。在微服務的世界中，它變得更加複雜，因為每個服務都是一個工作單元，並且在大多數情況下，多個服務必須協同工作才能使業務成功。
25. 什麼是冪等性（Idempotence）及用在那裡？
冪等性是能夠以同樣的方式做兩次，而最終結果將保持不變，就好像它只做了一次的特性。
用法：在遠程服務或數據源中使用冪等性，以便當它多次接收指令時，只處理一次。
26. 什麼是有界上下文？
有界上下文是領域驅動設計的核心模式。 DDD 戰略設計部門的重點是處理大型模型和團隊。 DDD 通過將大型模型劃分為不同的有界上下文並明確其相互關係來處理大型模型。
27. 什麼是雙因素身份驗證？
雙因素身份驗證是在帳戶登錄過程中啟用第二級身份驗證。
因此，如果用戶只需要輸入用戶名和密碼，那麼就被認為是單因素身份驗證。
28. 雙因素身份驗證的憑據類型有哪些？
這三種憑證是：
- 你知道的東西——如：PIN、密碼或模式
- 你有的東西——如：ATM 卡、電話或 OTP
- 你是誰——如：生物特徵指紋或聲紋
29. 什麼是客戶端證書？
客戶端系統向遠程服務器發出經過身份驗證的請求所用的數字證書被稱為客戶端證書。客戶端證書在許多相互認證設計中起著非常重要的作用，為請求者的身份提供了強有力的保證。
30. PACT 在微服務架構中的用途是什麼？
PACT 是一個開源工具，允許測試服務提供者和消費者之間的交互，與契約隔離，從而提高微服務集成的可靠性。
在微服務中的用法：
- 用於在微服務中實現消費者驅動的契約。
- 測試微服務的消費者和生產者之間的消費者驅動的契約。
32. 什麼是OAuth？
OAuth 代表開放授權協議。這允許通過在 HTTP 服務上啟用客戶端應用（例如第三方提供商 Facebook，GitHub等）來訪問資源所有者的資源。因此，你可以在不使用其憑據的情況下與另一個站點共享存儲在一個站點上的資源。
32. 什麼是康威定律？
“任何設計系統的組織（廣泛定義）都將產生一種設計，其結構是組織通信結構的副本。” —— Mel Conway
該定律基本上試圖傳達這樣一個事實：即為了使軟件模塊起作用，整個團隊應該進行良好的溝通。因此係統的結構反映了產生它的組織的社會邊界。
33. 契約測試（contract test）是什麼？
根據 Martin Flower 的說法，契約測試是在外部服務邊界進行的測試，用於驗證其是否符合消費者服務預期的契約。
此外，契約測試不會深入測試服務的行為。相反，它測試服務調用的輸入和輸出包含所需的屬性和響應延遲，吞吐量在允許的限制範圍內。
34. 什麼是端到端微服務測試？
端到端測試驗證了工作流中的每個流程都正常運行。這可確保系統作為一個整體協同工作並滿足所有要求。
通俗地說，你可以說端到端測試是一種測試，在特定時期後測試所有東西。
35. 容器在微服務中的用途是什麼？
容器是管理基於微服務的程序以便單獨開發和部署它們的好方法。你可以將微服務封裝在容器鏡像及其依賴項中，然後可以用它來滾動開發按需實例的微服務而無需任何額外的工作。
37. 微服務架構中的DRY是什麼？
DRY 代表不要重複自己。它基本上促進了重用代碼的概念。這導致開發並共享庫，但是反過來導致緊耦合。
38. 消費者驅動的契約（CDC）是什麼？
這基本上是用於開發微服務的模式，以便它們可以被外部系統使用。當我們處理微服務時，有一個特定的生產者者構建它，並且有一個或多個使用微服務的消費者。
通常，生產者程序在 XML 文檔中指定接口。但在消費者驅動的契約中，每個服務的消費者都傳達了生產者期望的接口。
39. Web、RESTful API 在微服務中的作用是什麼？
微服務架構基於一個概念，為了構建業務功能其中所有服務應該能夠彼此交互。因此要實現這一點，每個微服務必須具有接口。這使得 Web API 成為微服務的一個非常重要的推動者。 RESTful API 基於 Web 的開放網絡原則，為構建微服務架構的各個組件之間的接口提供了最合理的模型。
40. 你對微服務架構中的語義監控有何瞭解？
語義監控，也稱為綜合監控，將自動化測試與監控程序相結合，以檢測業務失敗的因素。
41. 我們如何進行跨功能測試？
跨功能測試是對非功能性需求的驗證，即那些不能像普通功能那樣實現的要求。
42. 如何在測試中消除不確定性？
不確定性測試 （NDT）基本上是不可靠的測試。因此，它們有時可能會通過，顯然有時也可能會失敗。當它們失敗時，會重新運行以通過。
從測試中排除不確定性的一些方法如下：
- 隔離
- 異步
- 遠程服務
- 分離
- 時間
- 資源洩漏
43. Mock 與 Stub 有什麼區別？
Stub
- 一個有助於運行測試的虛擬對象。
- 在某些可以硬編碼的條件下提供固定的行為。
- 從未測試stub的所有其他行為。
例如，對於空棧，你可以創建一個對於 empty() 方法只返回 true 的 stub。因此這並不關心棧中是否存在元素。
模擬
- 一個虛擬對象，其中最初設置了某些屬性。
- 此對象的行為取決於設置的屬性。
- 也可以測試對象的行為。
例如，對於 Customer 對象，你可以通過設置姓名和年齡來模擬它。你可以將年齡設置為 12，然後測試isAdult()方法，該方法將在大於 18 歲時返回 true。因此你的 Mock Customer 對象適用於指定的條件。
44. 你對Mike Cohn的測試金字塔瞭解多少？
Mike Cohn 提供了一個名為 測試金字塔 的模型。這描述了軟件開發所需的自動化測試類型。
圖16： Mike Cohn 的測試金字塔 - 微服務面試問題
根據金字塔，第一層的測試量應該最高。在服務層，測試次數應小於單元測試級別，但應大於端到端級別。
45. Docker 的用途是什麼？
Docker 提供了一個可用於託管任何應用程序的容器環境。將軟件應用程序和支持它的依賴項緊密打包在一起。
這個打包的產品被稱為容器 ，因為它是由 Docker 完成的，所以被稱為 Docker 容器。
46. 什麼是金絲雀發佈（Canary Releasing）？
金絲雀發佈是一種降低在生產中引入新版本軟件風險的技術。通過在將更改傳遞給整個基礎架構之前將更改緩慢地推廣到一小部分用戶來完成的。
47. 架構師在微服務架構中的角色是什麼？
微服務架構中的架構師扮演以下角色：
- 決定整個軟件系統的佈局。
- 有助於確定組件的分區。因此，他們確保組件相互粘合，但不緊密耦合。
- 與開發人員一起編寫代碼，瞭解日常面臨的挑戰。
- 為開發微服務的團隊提供某些工具和技術的建議。
- 提供技術治理，以便技術開發團隊遵循微服務原則。
48. 可以用微服務創建狀態機嗎？
我們知道擁有自己數據庫的每個微服務都是一個可獨立部署的程序單元，這反過來又讓我們可以創建一個狀態機。因此，我們可以為特定的微服務指定不同的狀態和事件。
例如，我們可以定義 Order 微服務。訂單可以具有不同的狀態。Order 狀態的轉換可以是 Order 微服務中的獨立事件。
49. 微服務中的反應性擴展是什麼？
Reactive Extensions 也稱為Rx。這是一種設計方法，我們通過調用多個服務來收集結果，然後編譯組合響應。這些調用可以是同步或異步，阻塞或非阻塞。 Rx 是分佈式系統中非常流行的工具，與傳統流程相反。
50. 微服務設計的基礎是什麼？
這可能是最常見的微服務面試問題之一。在回答這個問題時，你需要記住以下內容：
- 定義範圍。
- 結合低耦合和高內聚。
- 創建一個有唯一標識的服務，唯一標識將充當識別源，非常像數據庫表中的唯一鍵。
- 創建正確的API並在集成過程中特別注意。
- 限制對數據的訪問並將其限制到所需級別。
- 在請求和響應之間保持順暢的流程。
- 自動化大多數流程，以減少時間複雜性。
- 將表的數量保持在最低水平，以減少空間複雜性。
- 不斷監控架構，發現缺陷及時修復。
- 每個微服務的數據存儲應該分開。
- 對於每個微服務，都應該有一個獨立的構建。
- 將微服務部署到容器中。
- 服務器應被視為無狀態。
