一、50個微服務面試題前端
https://cloud.tencent.com/developer/article/1346868面試
根據Gartner的說法,微服務是雲開發的新應用平臺。微服務是獨立部署和管理的,一旦在容器內實現,它們與底層操做系統的交互不多。 所以,若是您計劃在微服務中開始您的職業生涯,那麼如今正是潛入技術處於新生狀態的時候。所以,爲了幫助您準備面試,我提出了微服務面試問題和答案博客。spring
在這個微服務面試問題博客中,我收集了面試官最常問的問題。這些問題是在諮詢微服務和相關技術領域的頂級行業專家後收集的。數據庫
若是您最近參加過任何微服務面試,請將這些面試問題粘貼到評論部分,咱們會盡快回答。若是您有任何疑問,也能夠在下面發表評論,這可能會在您的微服務面試中遇到。api
您能夠瀏覽微服務面試問題和答案的錄音,咱們的講師已經詳細解釋了這些主題,並提供了一些示例,可幫助您更好地理解這一律念。瀏覽器
微服務,又稱微服務 架構,是一種架構風格,它將應用程序構建爲以業務領域爲模型的小型自治服務集合 。安全
通俗地說,你必須看到蜜蜂如何經過對齊六角形蠟細胞來構建它們的蜂窩狀物。他們最初從使用各類材料的小部分開始,並繼續從中構建一個大型蜂箱。這些細胞造成圖案,產生堅固的結構,將蜂窩的特定部分固定在一塊兒。這裏,每一個細胞獨立於另外一個細胞,但它也與其餘細胞相關。這意味着對一個細胞的損害不會損害其餘細胞,所以,蜜蜂能夠在不影響完整蜂箱的狀況下重建這些細胞。服務器
圖1:微服務的蜂窩表示 – 微服務訪談問題restful
請參考上圖。這裏,每一個六邊形形狀表明單獨的服務組件。與蜜蜂的工做相似,每一個敏捷團隊都使用可用的框架和所選的技術堆棧構建單獨的服務組件。就像在蜂箱中同樣,每一個服務組件造成一個強大的微服務架構,以提供更好的可擴展性。此外,敏捷團隊能夠單獨處理每一個服務組件的問題,而對整個應用程序沒有影響或影響最小。網絡
圖2:微服務的 優勢 – 微服務訪談問題
圖3:微服務的 特色 – 微服務訪談問題
如下是設計微服務的最佳實踐:
圖4:設計微服務的最佳實踐 – 微服務訪談問題
微服務架構具備如下組件:
圖5:微服務 架構 – 微服務面試問題
微服務架構的優勢 |
微服務架構的缺點 |
---|---|
自由使用不一樣的技術 |
增長故障排除挑戰 |
每一個微服務都側重於單一功能 |
因爲遠程呼叫而增長延遲 |
支持單個可部署單元 |
增長了配置和其餘操做的工做量 |
容許常常發佈軟件 |
難以保持交易安全 |
確保每項服務的安全性 |
艱難地跨越各類邊界跟蹤數據 |
多個服務是並行開發和部署的 |
難以在服務之間進行編碼 |
圖6: 單片SOA和微服務之間的比較 – 微服務訪談問題
開發一些較小的微服務聽起來很容易,但開發它們時常常遇到的挑戰以下。
SOA和微服務之間的主要區別以下:
SOA |
微服務 |
---|---|
遵循「 儘量多的共享 」架構方法 |
遵循「 儘量少分享 」的架構方法 |
重要性在於 業務功能 重用 |
重要性在於「 有界背景 」 的概念 |
他們有 共同的 治理 和標準 |
他們專一於 人們的 合做 和其餘選擇的自由 |
使用 企業服務總線(ESB) 進行通訊 |
簡單的消息系統 |
它們支持 多種消息協議 |
他們使用 輕量級協議 ,如 HTTP / REST 等。 |
多線程, 有更多的開銷來處理I / O. |
單線程 一般使用Event Loop功能進行非鎖定I / O處理 |
最大化應用程序服務可重用性 |
專一於 解耦 |
傳統的關係數據庫 更經常使用 |
現代 關係數據庫 更經常使用 |
系統的變化須要修改總體 |
系統的變化是創造一種新的服務 |
DevOps / Continuous Delivery正在變得流行,但還不是主流 |
專一於DevOps /持續交付 |
您能夠列出微服務的特徵,以下所示:
圖7:微服務的特徵 – 微服務訪談問題
圖8: DDD原理 – 微服務面試問題
圖9:咱們須要DDD的因素 – 微服務面試問題
若是您必須定義泛在語言(UL),那麼它是特定域的開發人員和用戶使用的通用語言,經過該語言能夠輕鬆解釋域。
無處不在的語言必須很是清晰,以便它將全部團隊成員放在同一頁面上,並以機器能夠理解的方式進行翻譯。
模塊內部元素所屬的程度被認爲是凝聚力。
組件之間依賴關係強度的度量被認爲是耦合。一個好的設計老是被認爲具備高內聚力和低耦合性。
Representational State Transfer(REST)/ RESTful Web服務是一種幫助計算機系統經過Internet進行通訊的架構風格。這使得微服務更容易理解和實現。
微服務可使用或不使用RESTful API實現,但使用RESTful API構建鬆散耦合的微服務老是更容易。
事實上,隨着新功能的增長,彈簧變得愈來愈複雜。若是必須啓動新的spring項目,則必須添加構建路徑或添加maven依賴項,配置應用程序服務器,添加spring配置。因此一切都必須從頭開始。
Spring Boot是解決這個問題的方法。使用spring boot能夠避免全部樣板代碼和配置。所以,基本上認爲本身就好像你正在烘烤蛋糕同樣,春天就像製做蛋糕所需的成分同樣,彈簧靴就是你手中的完整蛋糕。
圖10: Spring Boot的因素 – 微服務面試問題
Spring Boot執行程序提供了restful Web服務,以訪問生產環境中運行應用程序的當前狀態。在執行器的幫助下,您能夠檢查各類指標並監控您的應用程序。
根據Spring Cloud的官方網站,Spring Cloud爲開發人員提供了快速構建分佈式系統中一些常見模式的工具(例如配置管理,服務發現,斷路器,智能路由,領導選舉,分佈式會話,集羣狀態)。
在使用Spring Boot開發分佈式微服務時,咱們面臨的問題不多由Spring Cloud解決。
在測試目標只關注Spring MVC組件的狀況下,WebMvcTest註釋用於單元測試Spring MVC應用程序。在上面顯示的快照中,咱們只想啓動ToTestController。執行此單元測試時,不會啓動全部其餘控制器和映射。
雖然您能夠經過多種方式實現微服務,但REST over HTTP是實現微服務的一種方式。REST還可用於其餘應用程序,如Web應用程序,API設計和MVC應用程序,以提供業務數據。
微服務是一種體系結構,其中系統的全部組件都被放入單獨的組件中,這些組件能夠單獨構建,部署和擴展。微服務的某些原則和最佳實踐有助於構建彈性應用程序。
簡而言之,您能夠說REST是構建微服務的媒介。
在使用微服務時,因爲有多個微服務協同工做,測試變得很是複雜。所以,測試分爲不一樣的級別。
分佈式事務是指單個事件致使兩個或多個不能以原子方式提交的單獨數據源的突變的任何狀況。在微服務的世界中,它變得更加複雜,由於每一個服務都是一個工做單元,而且大多數時候多個服務必須協同工做才能使業務成功。
冪等性是可以以這樣的方式作兩次事情的特性,即最終結果將保持不變,即好像它只作了一次。
用法:在遠程服務或數據源中使用 Idempotence,這樣當它屢次接收指令時,它只處理指令一次。
有界上下文是域驅動設計的核心模式。DDD戰略設計部門的重點是處理大型模型和團隊。DDD經過將大型模型劃分爲不一樣的有界上下文並明確其相互關係來處理大型模型。
雙因素身份驗證爲賬戶登陸過程啓用第二級身份驗證。
圖11: 雙因素認證的表示 – 微服務訪談問題
所以,假設用戶必須只輸入用戶名和密碼,那麼這被認爲是單因素身份驗證。
這三種憑證是:
圖12: 雙因素認證的證書類型 – 微服務面試問題
客戶端系統用於向遠程服務器發出通過身份驗證的請求的一種數字證書稱爲客戶端證書。客戶端證書在許多相互認證設計中起着很是重要的做用,爲請求者的身份提供了強有力的保證。
PACT是一個開源工具,容許測試服務提供者和消費者之間的交互,與合同隔離,從而提升微服務集成的可靠性。
OAuth 表明開放受權協議。這容許經過在HTTP服務上啓用客戶端應用程序(例如第三方提供商Facebook,GitHub等)來訪問資源全部者的資源。所以,您能夠在不使用其憑據的狀況下與另外一個站點共享存儲在一個站點上的資源。
「任何設計系統的組織(普遍定義)都將產生一種設計,其結構是組織通訊結構的副本。」 – Mel Conway
圖13: Conway定律的表示 – 微服務訪談問題
該法律基本上試圖傳達這樣一個事實:爲了使軟件模塊起做用,整個團隊應該進行良好的溝通。所以,系統的結構反映了產生它的組織的社會邊界。
根據Martin Flower的說法,合同測試是在外部服務邊界進行的測試,用於驗證其是否符合消費服務預期的合同。
此外,合同測試不會深刻測試服務的行爲。更確切地說,它測試該服務調用的輸入&輸出包含所需的屬性和所述響應延遲,吞吐量是容許的限度內。
端到端測試驗證了工做流中的每一個流程都正常運行。這可確保系統做爲一個總體協同工做並知足全部要求。
通俗地說,你能夠說端到端測試是一種測試,在特定時期後測試全部東西。
圖14:測試層次 – 微服務面試問題
容器是管理基於微服務的應用程序以便單獨開發和部署它們的好方法。您能夠將微服務封裝在容器映像及其依賴項中,而後可使用它來滾動按需實例的微服務,而無需任何額外的工做。
圖15: 容器的表示及其在微服務中的使用方式 – 微服務訪談問題
DRY表明不要重複本身。它基本上促進了重用代碼的概念。這致使開發和共享庫,這反過來致使緊密耦合。
這基本上是用於開發微服務的模式,以便它們能夠被外部系統使用。當咱們處理微服務時,有一個特定的提供者構建它,而且有一個或多個使用微服務的消費者。
一般,提供程序在XML文檔中指定接口。但在消費者驅動的合同中,每一個服務消費者都傳達了提供商指望的接口。
微服務架構基於一個概念,其中全部服務應該可以彼此交互以構建業務功能。所以,要實現這一點,每一個微服務必須具備接口。這使得Web API成爲微服務的一個很是重要的推進者。RESTful API基於Web的開放網絡原則,爲構建微服務架構的各個組件之間的接口提供了最合理的模型。
語義監控,也稱爲 綜合監控, 將自動化測試與監控應用程序相結合,以檢測業務失敗因素。
跨功能測試是對非功能性需求的驗證,即那些沒法像普通功能那樣實現的需求。
非肯定性測試(NDT)基本上是不可靠的測試。因此,有時可能會發生它們經過,顯然有時它們也可能會失敗。當它們失敗時,它們會從新運行經過。
從測試中刪除非肯定性的一些方法以下:
例如,對於空堆棧,您能夠建立一個只爲empty()方法返回true的存根。所以,這並不關心堆棧中是否存在元素。
例如,對於Customer對象,您能夠經過設置名稱和年齡來模擬它。您能夠將age設置爲12,而後測試isAdult()方法,該方法將在年齡大於18時返回true。所以,您的Mock Customer對象適用於指定的條件。
Mike Cohn 提供了一個名爲Test Pyramid的模型。這描述了軟件開發所需的自動化測試類型。
圖16: Mike Cohn的測試金字塔 – 微服務面試問題
根據金字塔,第一層的測試數量應該最高。在服務層,測試次數應小於單元測試級別,但應大於端到端級別。
Docker提供了一個可用於託管任何應用程序的容器環境。在此,軟件應用程序和支持它的依賴項緊密打包在一塊兒。
所以,這個打包的產品被稱爲Container,由於它是由Docker完成的,因此它被稱爲Docker容器!
Canary Releasing是一種下降在生產中引入新軟件版本的風險的技術。這是經過將變動緩慢地推廣到一小部分用戶,而後將其發佈到整個基礎架構,即將其提供給每一個人來完成的。
持續集成(CI)是每次團隊成員提交版本控制更改時自動構建和測試代碼的過程。這鼓勵開發人員經過在每一個小任務完成後將更改合併到共享版本控制存儲庫來共享代碼和單元測試。
持續監控深刻監控覆蓋範圍,從瀏覽器內前端性能指標,到應用程序性能,再到主機虛擬化基礎架構指標。
微服務架構中的架構師扮演如下角色:
咱們知道擁有本身的數據庫的每一個微服務都是一個可獨立部署的程序單元,這反過來又讓咱們能夠建立一個狀態機。所以,咱們能夠爲特定的微服務指定不一樣的狀態和事件。
例如,咱們能夠定義Order微服務。訂單能夠具備不一樣的狀態。Order狀態的轉換能夠是Order微服務中的獨立事件。
Reactive Extensions也稱爲Rx。這是一種設計方法,咱們經過調用多個服務來收集結果,而後編譯組合響應。這些調用能夠是同步或異步,阻塞或非阻塞。Rx是分佈式系統中很是流行的工具,與傳統流程相反。