50個必需要會的微服務面試題

時間 2019-11-10

原文原文鏈接

做者：Sahiti Kappagantula
翻譯：瘋狂的技術宅前端

原文：https://www.edureka.co/blog/i...程序員

未經容許嚴禁轉載面試

根據 Gartner 的說法，微服務是雲開發的新應用平臺。微服務是獨立部署和管理的，一旦應用實如今容器內，它們與底層操做系統的交互不多。所以，若是你但願把微服務添加到本身的技術棧中，並想要了解與之相關的技能，那麼如今正是潛心研究的時候。爲了幫你準備面試，我寫出了這篇關於微服務面試題的文章。spring

在本文中，我收集了面試官最常問到的問題。數據庫

微服務面試題與答案

Q1. 說說微服務架構的優點。

優點	說明
*獨立開發*	全部微服務均可以根據各自的功能輕鬆開發
*獨立部署*	根據他們所提供的服務，能夠在任何應用中單獨部署
*故障隔離*	即便應用中的一個服務不起做用，系統仍然繼續運行
*混合技術棧*	能夠用不一樣的語言和技術來構建同一應用程序的不一樣服務
*粒度縮放*	各個組件可根據須要進行擴展，無需將全部組件融合到一塊兒

Q2. 你對微服務是怎麼理解的？

微服務，又名微服務架構，是一種架構風格，它將應用構建爲一個小型自治服務的集合，以業務領域爲模型。
通俗地說，就像蜜蜂經過對蠟制的等邊六角形單元來構建它們的蜂巢。
他們最初從使用各類材料的小單元開始，一點點的搭建出一個大型蜂巢。
這些小單元組成堅固的結構，將蜂窩的特定部分固定在一塊兒。
這裏，每一個小單元都獨立於另外一個，但它也與其餘小單元相關。
這意味着對一個小單元的損害不會損害其餘的單元，所以，蜜蜂能夠在不影響完整蜂巢的狀況下重建這些單元。

請參考上圖。這裏，每一個六邊形都表明單獨的服務組件。與蜜蜂的工做相似，每一個敏捷團隊都使用可用的框架和所選的技術棧構建單獨的服務組件。就像在蜂巢中同樣，這些服務組件造成一個強大的微服務架構，以提供更好的可擴展性。此外敏捷團隊能夠單獨處理每一個服務組件的問題，而不會對整個應用程序產生影響或使影響最小。segmentfault

Q3. 微服務有哪些特色？

解耦（Decoupling） - 系統內的服務很大程度上是分離的。所以整個應用能夠被輕鬆構建、修改和擴展
組件化（Componentization） - 微服務被視爲能夠被輕鬆替換和升級的獨立組件
業務能力（Business Capabilities） - 微服務很是簡單，專一於單一功能
自治（Autonomy） - 開發人員和團隊能夠相互獨立工做，從而提升效率
持續交付（ContinousDelivery） - 容許頻繁發版，經過系統自動化完成對軟件的建立、測試和審覈，
責任（Responsibility） - 微服務不把程序做爲項目去關注。相反，他們將程序視爲本身負責的產品
分散治理（Decentralized Governance） - 重點是用正確的工具去作正確的事。這意味着沒有任何標準化模式或着技術模式。開發人員能夠自由選擇最合適的工具來解決本身的問題
敏捷性（Agility） - 微服務支持敏捷開發。任何新功能均可以快速開發並被再次丟棄

Q4. 設計微服務的最佳實踐是什麼？

如下是設計微服務的最佳實踐：
瀏覽器

爲每一個微服務分開數據存儲
將代碼保持在相似的成熟度等級上
爲每一個微服務進行單獨的構建
部署到容器中
將服務器視爲無狀態的

Q5. 微服務架構是如何運做的？

微服務架構具備如下組件：安全

Clients – 來自不一樣設備的不一樣用戶發送請求。
Identity Providers – 對用戶或客戶端身份進行身份驗證，並頒發安全令牌。
API Gateway – 處理客戶端請求。
Static Content – 容納系統的全部內容。
Management – 平衡節點上的服務壓力並識別故障。
Service Discovery – 用於找到微服務之間通訊路徑的嚮導。
Content Delivery Networks – 代理服務器及其數據中心的分佈式網絡。
Remote Service – 啓用駐留在 IT 設備網絡上的遠程訪問信息。

Q6. 微服務架構的優勢和缺點是什麼？

微服務架構的優勢	微服務架構的缺點
能夠自由使用不一樣的技術	增長故障排除的難度
每一個微服務都專一於單一功能	因爲遠程調用而致使延遲增長
支持單個可部署單元	增長配置和其餘操做的工做量
容許軟件的持續發佈	難以維持處理的安全性
可確保每項服務的安全性	很難跟蹤各類邊界的數據
並行開發和部署多個服務	服務之間難以編碼

Q7. 單體應用、SOA 和微服務架構有什麼區別？

單體應用相似於一個大容器，其中程序的全部組件都被組裝在一塊兒並緊密包裝。
SOA是一組相互通訊的服務。通訊能夠涉及簡單的數據傳送，也能夠涉及兩個或多個協調某些活動的服務。
微服務架構是一種架構風格，它將應用程序構建爲以業務域爲模型的小型自治服務集合。

Q8. 在使用微服務架構時，你面臨的挑戰是什麼？

開發較小的微服務聽起來很容易，但在開發時會常常遇到一些挑戰。服務器

自動化組件：難以自動化，由於有許多較小的組件。對於每一個組件，都必須採起構建、發佈和監控的步驟。
可感知性：將大量組件維持在一塊兒會帶來難以部署、維護、監控和識別的問題。它須要在全部組件周圍具備很好的感知能力。
配置管理：有時在各類環境中維護組件的配置會很困難。
調試：很難找到與產生的錯誤相關的每一項服務。維護一個集中式的日誌和控制面板對調試問題相當重要。

Q9. SOA 和微服務架構之間的主要區別是什麼？

SOA 和微服務之間的主要區別以下：微信

SOA	微服務
遵循「儘量多的共享」架構方法	遵循「儘量少的共享」的架構方法
側重點是業務功能重用	側重點在於「bounded context」的概念
遵循共同治理並有相關的標準	專一於人的合做和其餘選擇的自由
使用企業服務總線（ESB）進行通訊	簡單的消息系統
支持多消息協議	使用輕量級協議，例如 HTTP/REST 等
多線程，有更多的開銷來處理I / O	單線程，一般使用事件循環進行非鎖定 I/O 處理
最大化服務的可重用性	專一於解耦
使用傳統關係數據庫較多	使用現代關係型數據庫較多
系統發生變化時須要修改總體	系統發生變化是建立一項新服務
DevOps和持續交付正在變得流行，但還沒有成爲主流	專一於DevOps和持續交付

Q10. 微服務有什麼特色？

你能夠列出微服務的特徵，以下所示：

圍繞業務功能組織團隊
作產品而不是作項目
基本的消息傳遞框架
去中心化治理
去中心化管理數據
基礎設施自動化
容錯設計

Q11. 什麼是領域驅動設計（DDD）？

專一於核心領域邏輯
在模型上找到綜合的設計
不斷與領域專家合做，改進應用程序模型並解決與領域相關的問題

Q12. 爲何須要域驅動設計（DDD）？

映射領域
下降複雜性
可測試性
可維護性
知識豐富的設計
將業務和服務結合在一塊兒
上下文集中
通用語言

Q13. 什麼是通用語言（UL）？

若是你必須定義通用語言（UL），那麼它是特定域的開發人員和用戶使用的通用語言，經過該語言能夠輕鬆解釋領域。

通用語言必須很是清晰，以便將全部團隊成員處於同一水平線上，並以機器能夠理解的方式進行翻譯。

Q14. 什麼是內聚？

內聚是一個模塊內部各元素之間相關聯程度的度量

Q15. 什麼是耦合？

組件之間依賴關係強度的度量被稱爲耦合。好的設計老是高內聚和低耦合的。

Q16. 什麼是REST/RESTful ？它的用途是什麼？

Representational State Transfer（REST）/ RESTful （表述性狀態轉移）是一種幫助計算機系統經過 Internet 進行通訊的架構風格。這使得微服務更容易理解和實現。

微服務能夠用 RESTful API 來實現，固然也能夠不用，可是用 RESTful API 去構建鬆散耦合的微服務老是更容易些。

Q17. 你怎麼理解 Spring Boot？

隨着新功能的增長，spring 變得愈來愈複雜。若是必須啓動新的 spring 項目，必須添加構建路徑或添加 maven 依賴項，配置服務器，添加 spring 配置。因此一切都必須從頭開始。

Spring Boot 是解決這個問題的方法。使用 spring boot 能夠避免全部樣板代碼和配置。所以，基本上認爲本身就好像在烤蛋糕同樣，spring 就像作蛋糕所需的原料同樣， spring boot 就是完整的蛋糕。

Q18. Spring boot 的執行器是什麼？

Spring Boot 執行器提供 restful 服務，以訪問在生產環境中運行程序的當前狀態。在執行器的幫助下，你能夠檢查各類指標並監控本身的程序。

Q19. 什麼是 Spring Cloud？

根據 Spring Cloud 的官方網站，Spring Cloud 爲開發人員提供了一些快速構建分佈式系統常見模式的工具（例如配置管理、服務發現、斷路器、智能路由、領導選舉、分佈式會話、集羣狀態）。

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

在使用 Spring Boot 開發分佈式微服務時，咱們面臨的一些問題能夠由 Spring Cloud 解決。

與分佈式系統相關的複雜性 - 這包括網絡問題、延遲開銷、帶寬問題、安全問題。
處理服務發現的能力 - 服務發現容許羣集中的進程和服務找到彼此並進行通訊。
解決了冗餘問題 - 冗餘問題常常發生在分佈式系統中。
負載平衡 - 改進跨多種計算資源（如計算機集羣、網絡連接、中央處理單元）的工做負載分配。
減小性能問題 - 減小因各類操做開銷致使的性能問題。

Q21. 在 Spring MVC 中使用 WebMvcTest 註釋有什麼用？

WebMvcTest 註釋用於 Spring MVC 程序的單元測試，其目標是專一於Spring MVC組件。在上面顯示的快照中，咱們只想啓動 ToTestController。執行此單元測試時，將不會啓動全部其餘控制器和映射。

Q22. 你可否給出關於 Rest 和微服務的要點？

REST

雖然你能夠經過多種方式實現微服務，但 REST over HTTP 是實現微服務的一種方式。 REST 還用於其餘應用程序，如 Web 應用、API 設計和 MV C應用以提供業務數據。

微服務

微服務是一種體系結構，其中系統的全部組件都被放入單獨的組件中，這些組件能夠單獨構建、部署和擴展。微服務的某些原則和最佳實踐有助於構建彈性應用程序。

簡而言之，你能夠認爲 REST 是構建微服務的媒介。

Q23. 什麼是不一樣類型的微服務測試？

在使用微服務時，因爲有多個微服務協同工做，測試變得很是複雜。所以，測試分爲不一樣的級別。

在底層，咱們有面向技術的測試 —— 單元測試和性能測試。這些是徹底自動化的。
在中間層，咱們有探測性測試，如壓力測試和可用性測試。
在頂級，咱們有不多的驗收測試。這些驗收測試有助於利益相關者理解和驗證軟件功能。

Q24. 你對分佈式事務的理解？

分佈式事務是單個事件致使兩個或多個不能以原子方式提交的單獨數據源的突變的狀況。在微服務的世界中，它變得更加複雜，由於每一個服務都是一個工做單元，而且在大多數狀況下，多個服務必須協同工做才能使業務成功。

Q25. 什麼是冪等性（Idempotence）及用在那裏？

冪等性是可以以一樣的方式作兩次，而最終結果將保持不變，就好像它只作了一次的特性。

用法：在遠程服務或數據源中使用冪等性，以便當它屢次接收指令時，只處理一次。

Q26. 什麼是有界上下文？

有界上下文是領域驅動設計的核心模式。 DDD 戰略設計部門的重點是處理大型模型和團隊。 DDD 經過將大型模型劃分爲不一樣的有界上下文並明確其相互關係來處理大型模型。

Q27. 什麼是雙因素身份驗證？

雙因素身份驗證是在賬戶登陸過程當中啓用第二級身份驗證。

所以，若是用戶只須要輸入用戶名和密碼，那麼就被認爲是單因素身份驗證。

Q28. 雙因素身份驗證的憑據類型有哪些？

這三種憑證是：

你知道的東西——如：PIN、密碼或模式
你有的東西——如：ATM 卡、電話或 OTP
你是誰——如：生物特徵指紋或聲紋

Q29. 什麼是客戶端證書？

客戶端系統向遠程服務器發出通過身份驗證的請求所用的數字證書被稱爲客戶端證書。客戶端證書在許多相互認證設計中起着很是重要的做用，爲請求者的身份提供了強有力的保證。

Q30. PACT 在微服務架構中的用途是什麼？

PACT 是一個開源工具，容許測試服務提供者和消費者之間的交互，與契約隔離，從而提升微服務集成的可靠性。

在微服務中的用法：

用於在微服務中實現消費者驅動的契約。
測試微服務的消費者和生產者之間的消費者驅動的契約。

Q31. 什麼是OAuth？

OAuth 表明開放受權協議。這容許經過在 HTTP 服務上啓用客戶端應用（例如第三方提供商 Facebook，GitHub等）來訪問資源全部者的資源。所以，你能夠在不使用其憑據的狀況下與另外一個站點共享存儲在一個站點上的資源。

Q32. 什麼是康威定律？

「任何設計系統的組織（普遍定義）都將產生一種設計，其結構是組織通訊結構的副本。」 —— Mel Conway

該定律基本上試圖傳達這樣一個事實：即爲了使軟件模塊起做用，整個團隊應該進行良好的溝通。所以系統的結構反映了產生它的組織的社會邊界。

Q33. 契約測試（contract test）是什麼？

根據 Martin Flower 的說法，契約測試是在外部服務邊界進行的測試，用於驗證其是否符合消費者服務預期的契約。

此外，契約測試不會深刻測試服務的行爲。相反，它測試服務調用的輸入和輸出包含所需的屬性和響應延遲，吞吐量在容許的限制範圍內。

Q34. 什麼是端到端微服務測試？

端到端測試驗證了工做流中的每一個流程都正常運行。這可確保系統做爲一個總體協同工做並知足全部要求。

通俗地說，你能夠說端到端測試是一種測試，在特定時期後測試全部東西。

Q35. 容器在微服務中的用途是什麼？

容器是管理基於微服務的程序以便單獨開發和部署它們的好方法。你能夠將微服務封裝在容器鏡像及其依賴項中，而後能夠用它來滾動開發按需實例的微服務而無需任何額外的工做。

Q36. 微服務架構中的DRY是什麼？

DRY 表明不要重複本身。它基本上促進了重用代碼的概念。這致使開發並共享庫，可是反過來致使緊耦合。

Q37. 消費者驅動的契約（CDC）是什麼？

這基本上是用於開發微服務的模式，以便它們能夠被外部系統使用。當咱們處理微服務時，有一個特定的生產者者構建它，而且有一個或多個使用微服務的消費者。

一般，生產者程序在 XML 文檔中指定接口。但在消費者驅動的契約中，每一個服務的消費者都傳達了生產者指望的接口。

Q38. Web、RESTful API 在微服務中的做用是什麼？

微服務架構基於一個概念，爲了構建業務功能其中全部服務應該可以彼此交互。所以要實現這一點，每一個微服務必須具備接口。這使得 Web API 成爲微服務的一個很是重要的推進者。 RESTful API 基於 Web 的開放網絡原則，爲構建微服務架構的各個組件之間的接口提供了最合理的模型。

Q39. 你對微服務架構中的語義監控有何瞭解？

語義監控，也稱爲綜合監控，將自動化測試與監控程序相結合，以檢測業務失敗的因素。

Q40. 咱們如何進行跨功能測試？

跨功能測試是對非功能性需求的驗證，即那些不能像普通功能那樣實現的要求。

Q41. 如何在測試中消除不肯定性？

不肯定性測試（NDT）基本上是不可靠的測試。所以，它們有時可能會經過，顯然有時也可能會失敗。當它們失敗時，會從新運行以經過。

從測試中排除不肯定性的一些方法以下：

隔離
異步
遠程服務
分離
時間
資源泄漏

Q42. Mock 與 Stub 有什麼區別？

Stub

一個有助於運行測試的虛擬對象。
在某些能夠硬編碼的條件下提供固定的行爲。
從未測試stub的全部其餘行爲。

例如，對於空棧，你能夠建立一個對於 empty() 方法只返回 true 的 stub。所以這並不關心棧中是否存在元素。

模擬

一個虛擬對象，其中最初設置了某些屬性。
此對象的行爲取決於設置的屬性。
也能夠測試對象的行爲。

例如，對於 Customer 對象，你能夠經過設置姓名和年齡來模擬它。你能夠將年齡設置爲 12，而後測試isAdult()方法，該方法將在大於 18 歲時返回 true。所以你的 Mock Customer 對象適用於指定的條件。

Q43. 你對Mike Cohn的測試金字塔瞭解多少？

Mike Cohn 提供了一個名爲 測試金字塔 的模型。這描述了軟件開發所需的自動化測試類型。

圖16： Mike Cohn 的測試金字塔 - 微服務面試問題

根據金字塔，第一層的測試量應該最高。在服務層，測試次數應小於單元測試級別，但應大於端到端級別。

Q44. Docker 的用途是什麼？

Docker 提供了一個可用於託管任何應用程序的容器環境。將軟件應用程序和支持它的依賴項緊密打包在一塊兒。

這個打包的產品被稱爲容器，由於它是由 Docker 完成的，因此被稱爲 Docker 容器。

Q45. 什麼是金絲雀發佈（Canary Releasing）？

金絲雀發佈是一種下降在生產中引入新版本軟件風險的技術。經過在將更改傳遞給整個基礎架構以前將更改緩慢地推廣到一小部分用戶來完成的。

Q46. 什麼是持續集成（CI）？

持續集成（CI）是每次團隊成員提交版本控制更改時自動構建和測試代碼的過程。這鼓勵開發人員經過在每一個小任務完成後將更改合併到共享版本控制存儲庫來共享代碼和單元測試。

Q47. 什麼是持續監控？

持續監控深刻監控覆蓋範圍，從瀏覽器中的前端性能指標，到應用程序性能，再到主機虛擬化基礎架構指標。

Q48. 架構師在微服務架構中的角色是什麼？

微服務架構中的架構師扮演如下角色：

決定整個軟件系統的佈局。
有助於肯定組件的分區。所以，他們確保組件相互粘合，但不緊密耦合。
與開發人員一塊兒編寫代碼，瞭解平常面臨的挑戰。
爲開發微服務的團隊提供某些工具和技術的建議。
提供技術治理，以便技術開發團隊遵循微服務原則。

Q49. 能夠用微服務建立狀態機嗎？

咱們知道擁有本身數據庫的每一個微服務都是一個可獨立部署的程序單元，這反過來又讓咱們能夠建立一個狀態機。所以，咱們能夠爲特定的微服務指定不一樣的狀態和事件。

例如，咱們能夠定義 Order 微服務。訂單能夠具備不一樣的狀態。Order 狀態的轉換能夠是 Order 微服務中的獨立事件。

Q50. 微服務中的反應性擴展是什麼？

Reactive Extensions 也稱爲Rx。這是一種設計方法，咱們經過調用多個服務來收集結果，而後編譯組合響應。這些調用能夠是同步或異步，阻塞或非阻塞。 Rx 是分佈式系統中很是流行的工具，與傳統流程相反。

本文首發微信公衆號：前端先鋒

歡迎掃描二維碼關注公衆號，天天都給你推送新鮮的前端技術文章

歡迎繼續閱讀本專欄其它高贊文章：

更多文章...

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。