微服務面試集合

一、50個微服務面試題前端

https://cloud.tencent.com/developer/article/1346868面試

頂級微服務面試問題

根據Gartner的說法,微服務是雲開發的新應用平臺。微服務是獨立部署和管理的,一旦在容器內實現,它們與底層操做系統的交互不多。 所以,若是您計劃在微服務中開始您的職業生涯,那麼如今正是潛入技術處於新生狀態的時候。所以,爲了幫助您準備面試,我提出了微服務面試問題和答案博客。spring

在這個微服務面試問題博客中,我收集了面試官最常問的問題。這些問題是在諮詢微服務和相關技術領域的頂級行業專家後收集的。數據庫

若是您最近參加過任何微服務面試,請將這些面試問題粘貼到評論部分,咱們會盡快回答。若是您有任何疑問,也能夠在下面發表評論,這可能會在您的微服務面試中遇到。api

您能夠瀏覽微服務面試問題和答案的錄音,咱們的講師已經詳細解釋了這些主題,並提供了一些示例,可幫助您更好地理解這一律念。瀏覽器

Q1。您對微服務有何瞭解?

微服務,又稱微服務  架構,是一種架構風格,它將應用程序構建爲以業務領域爲模型的小型自治服務集合  安全

通俗地說,你必須看到蜜蜂如何經過對齊六角形蠟細胞來構建它們的蜂窩狀物。他們最初從使用各類材料的小部分開始,並繼續從中構建一個大型蜂箱。這些細胞造成圖案,產生堅固的結構,將蜂窩的特定部分固定在一塊兒。這裏,每一個細胞獨立於另外一個細胞,但它也與其餘細胞相關。這意味着對一個細胞的損害不會損害其餘細胞,所以,蜜蜂能夠在不影響完整蜂箱的狀況下重建這些細胞。服務器

圖1:微服務的蜂窩表示 – 微服務訪談問題restful

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

Q2。微服務架構有哪些優點?

圖2:微服務的 優勢 – 微服務訪談問題

  • 獨立開發  – 全部微服務均可以根據各自的功能輕鬆開發
  • 獨立部署  – 基於其服務,能夠在任何應用程序中單獨部署它們
  • 故障隔離  – 即便應用程序的一項服務不起做用,系統仍可繼續運行
  • 混合技術堆棧  – 可使用不一樣的語言和技術來構建同一應用程序的不一樣服務
  • 粒度縮放  – 單個組件可根據須要進行縮放,無需將全部組件縮放在一塊兒

Q3。微服務有哪些特色?

圖3:微服務的 特色 – 微服務訪談問題

  • 解耦  – 系統內的服務很大程度上是分離的。所以,整個應用程序能夠輕鬆構建,更改和擴展
  • 組件化  – 微服務被視爲能夠輕鬆更換和升級的獨立組件
  • 業務能力  – 微服務很是簡單,專一於單一功能
  • 自治  – 開發人員和團隊能夠彼此獨立工做,從而提升速度
  • 持續交付  – 經過軟件建立,測試和批准的系統自動化,容許頻繁發佈軟件
  • 責任  – 微服務不關注應用程序做爲項目。相反,他們將應用程序視爲他們負責的產品
  • 分散治理  – 重點是使用正確的工具來作正確的工做。這意味着沒有標準化模式或任何技術模式。開發人員能夠自由選擇最有用的工具來解決他們的問題
  • 敏捷  – 微服務支持敏捷開發。任何新功能均可以快速開發並再次丟棄

Q4。設計微服務的最佳實踐是什麼?

如下是設計微服務的最佳實踐:

圖4:設計微服務的最佳實踐 – 微服務訪談問題

Q5。微服務架構如何運做?

微服務架構具備如下組件:

圖5:微服務 架構 – 微服務面試問題

  • 客戶端  – 來自不一樣設備的不一樣用戶發送請求。
  • 身份提供商  – 驗證用戶或客戶身份並頒發安全令牌。
  • API網關  – 處理客戶端請求。
  • 靜態內容  – 容納系統的全部內容。
  • 管理  – 在節點上平衡服務並識別故障。
  • 服務發現  – 查找微服務之間通訊路徑的指南。
  • 內容交付網絡  – 代理服務器及其數據中心的分佈式網絡。
  • 遠程服務  – 啓用駐留在IT設備網絡上的遠程訪問信息。

Q6。微服務架構的優缺點是什麼?

微服務架構的優勢

微服務架構的缺點

自由使用不一樣的技術

增長故障排除挑戰

每一個微服務都側重於單一功能

因爲遠程呼叫而增長延遲

支持單個可部署單元

增長了配置和其餘操做的工做量

容許常常發佈軟件

難以保持交易安全

確保每項服務的安全性

艱難地跨越各類邊界跟蹤數據

多個服務是並行開發和部署的

難以在服務之間進行編碼

Q7。單片,SOA和微服務架構有什麼區別?

圖6: 單片SOA和微服務之間的比較 – 微服務訪談問題

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

Q8。在使用微服務架構時,您面臨哪些挑戰?

開發一些較小的微服務聽起來很容易,但開發它們時常常遇到的挑戰以下。

  • 自動化組件:難以自動化,由於有許多較小的組件。所以,對於每一個組件,咱們必須遵循Build,Deploy和Monitor的各個階段。
  • 易感性:將大量組件維護在一塊兒變得難以部署,維護,監控和識別問題。它須要在全部組件周圍具備很好的感知能力。
  • 配置管理:有時在各類環境中維護組件的配置變得困難。
  • 調試:很難找到錯誤的每一項服務。維護集中式日誌記錄和儀表板以調試問題相當重要。

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

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)基本上是不可靠的測試。因此,有時可能會發生它們經過,顯然有時它們也可能會失敗。當它們失敗時,它們會從新運行經過。

從測試中刪除非肯定性的一些方法以下:

  1. 隔離
  2. 異步
  3. 遠程服務
  4. 隔離
  5. 時間
  6. 資源泄漏

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。架構師在微服務架構中的角色是什麼?

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

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

Q49。咱們能夠用微服務建立狀態機嗎?

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

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

Q50。什麼是微服務中的反應性擴展?

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

相關文章
相關標籤/搜索