根據 Gartner 的說法，微服務是雲開發的新應用平臺。微服務是獨立部署和管理的，一旦應用實現在容器內，它們與底層操作系統的交互很少。因此，如果你希望把微服務添加到自己的技術棧中，並想要了解與之相關的技能，那麼現在正是潛心研究的時候。

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

微服務面試題與答案

  說說微服務架構的優勢

獨立開發  ：所有微服務都可以根據各自的功能輕鬆開發 

獨立部署 ：根據他們所提供的服務，可以在任何應用中單獨部署 

故障隔離 ：即使應用中的一個服務不起作用，系統仍然繼續運行 

混合技術棧： 可以用不同的語言和技術來構建同一應用程序的不同服務

粒度縮放 ：各個組件可根據需要進行擴展，無需將所有組件融合到一起 

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

• 微服務 ，又名 微服務架構 ，是一種架構風格，它將應用構建爲一個小型自治服務的集合，以 業務領域爲模型。

• 通俗地說，就像蜜蜂通過對蠟制的等邊六角形單元來構建它們的蜂巢。

• 他們最初從使用各種材料的小單元開始，一點點的搭建出一個大型蜂巢。

• 這些小單元組成堅固的結構，將蜂窩的特定部分固定在一起。

• 這裏，每個小單元都獨立於另一個，但它也與其他小單元相關。

• 這意味着對一個小單元的損害不會損害其他的單元，因此，蜜蜂可以在不影響完整蜂巢的情況下重建這些單元。

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

微服務有哪些特點？

• 解耦（Decoupling） - 系統內的服務很大程度上是分離的。因此整個應用可以被輕鬆構建、修改和擴展

• 組件化（Componentization） - 微服務被視爲可以被輕鬆替換和升級的獨立組件

• 業務能力（Business Capabilities） - 微服務非常簡單，專注於單一功能

• 自治（Autonomy） - 開發人員和團隊可以相互獨立工作，從而提高效率

• 持續交付（ContinousDelivery） - 允許頻繁發版，通過系統自動化完成對軟件的創建、測試和審覈，

• 責任（Responsibility） - 微服務不把程序作爲項目去關注。相反，他們將程序視爲自己負責的產品

• 分散治理（Decentralized Governance） - 重點是用正確的工具去做正確的事。這意味着沒有任何標準化模式或技術模式。開發人員可以自由選擇最合適的工具來解決自己的問題

• 敏捷性（Agility） - 微服務支持敏捷開發。任何新功能都可以快速開發並被再次丟棄

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

1. 爲每個微服務分開數據存儲

2. 將代碼保持在類似的成熟度等級上

3. 爲每個微服務進行單獨的構建

4. 部署到容器中

5. 將服務器視爲無狀態的

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

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

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

• 單體應用 類似於一個大容器，其中程序的所有組件都被組裝在一起並緊密包裝。

• SOA 是一組相互通信的服務。通信可以涉及簡單的數據傳送，也可以涉及兩個或多個協調某些活動的服務。

• 微服務架構 是一種架構風格，它將應用程序構建爲以業務域爲模型的小型自治服務集合。

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

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

• 自動化組件 ：難以自動化，因爲有許多較小的組件。對於每個組件，都必須採取構建、發佈和監控的步驟。

• 可感知性 ：將大量組件維持在一起會帶來難以部署、維護、監控和識別的問題。它需要在所有組件周圍具有很好的感知能力。

• 配置管理 ：有時在各種環境中維護組件的配置會很困難。

• 調試 ：很難找到與產生的錯誤相關的每一項服務。維護一個集中式的日誌和控制面板對調試問題至關重要。

什麼是通用語言（UL）？

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

通用語言必須非常清晰，以便將所有團隊成員處於同一水平線上，並以機器可以理解的方式進行翻譯。

什麼是內聚？

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

什麼是耦合？

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

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

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

微服務可以用 RESTful API 來實現，當然也可以不用，但是用 RESTful API 去構建鬆散耦合的微服務總是更容易些。

你怎麼理解 Spring Boot？

隨着新功能的增加，spring 變得越來越複雜。如果必須啓動新的 spring 項目，必須添加構建路徑或添加 maven 依賴項，配置服務器，添加 spring 配置。所以一切都必須從頭開始。

Spring Boot 是解決這個問題的方法。使用 spring boot 可以避免所有樣板代碼和配置。因此，基本上認爲自己就好像在烤蛋糕一樣，spring 就像做蛋糕所需的原料一樣， spring boot 就是完整的蛋糕。

Spring boot 的執行器是什麼？

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

什麼是 Spring Cloud？

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

我們如何進行跨功能測試？

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

如何在測試中消除不確定性？

不確定性測試 （NDT）基本上是不可靠的測試。因此，它們有時可能會通過，顯然有時也可能會失敗。當它們失敗時，會重新運行以通過。

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

1. 隔離

2. 異步

3. 遠程服務

4. 分離

5. 時間

6. 資源泄漏

Mock 與 Stub 有什麼區別？

Stub

• 一個有助於運行測試的虛擬對象。

• 在某些可以硬編碼的條件下提供固定的行爲。

• 從未測試stub的所有其他行爲。

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

模擬

• 一個虛擬對象，其中最初設置了某些屬性。

• 此對象的行爲取決於設置的屬性。

• 也可以測試對象的行爲。

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

微服務之間是如何通訊的？

第一種：遠程過程調用（Remote Procedure Invocation）

直接通過遠程過程調用來訪問別的service。

示例：REST、gRPC、Apache、Thrift

優點：簡單，常見。因爲沒有中間件代理，系統更簡單

缺點：只支持請求/響應的模式，不支持別的，比如通知、請求/異步響應、發佈/訂閱、發佈/異步響應

降低了可用性，因爲客戶端和服務端在請求過程中必須都是可用的

第二種 ：消息

使用異步消息來做服務間通信。服務間通過消息管道來交換消息，從而通信。

示例：Apache Kafka、RabbitMQ

優點:

• 把客戶端和服務端解耦，更松耦合 提高可用性，因爲消息中間件緩存了消息，直到消費者可以消費

• 支持很多通信機制比如通知、請求/異步響應、發佈/訂閱、發佈/異步響應

缺點：消息中間件有額外的複雜性

springcloud 與dubbo有哪些區別？

相同點：SpringCloud 和Dubbo可以實現RPC遠程調用框架，可以實現服務治理。

不同點：SpringCloud是一套目前比較網站微服務框架了，整合了分佈式常用解決方案遇到了問題註冊中心Eureka、負載均衡器Ribbon ，客戶端調用工具Rest和Feign，分佈式配置中心Config，服務保護Hystrix，網關Zuul Gateway ，服務鏈路Zipkin，消息總線Bus等。

Dubbo內部實現功能沒有SpringCloud強大（全家桶），只是實現服務治理，缺少分佈式配置中心、網關、鏈路、總線等，如果需要用到這些組件，需要整合其他框架。