面試專區|【52道微服務架構高頻題整理(附答案背誦版)】

簡述什么是微服務？

微服務是一種軟件架構風格，它將應用程序拆分成一系列小型、獨立的服務，每個服務都運行在其自己的進程中，通過輕量級通信機制進行通信。每個服務都具有明確的業務能力，并且可以獨立開發、測試、部署和擴展。微服務架構的核心思想是將應用程序分解為多個小型服務，每個服務都具有獨立的功能和責任。每個服務都可以獨立地開發、測試、部署和擴展，從而提高了應用程序的可維護性、可擴展性和靈活性。

簡述微服務的優缺點？

微服務的優點主要包括：

獨立性：每個微服務都是獨立的、可獨立部署和擴展的。
輕量級通信：微服務之間通過輕量級通信機制進行通信，例如基于HTTP的RESTful API或者消息隊列等。
單一職責：每個微服務都專注于特定的業務能力，具有明確的職責和邊界。
松耦合：微服務之間的依賴關系盡量減少，每個微服務都可以獨立地運行和更新。
靈活性：微服務架構使得系統更加靈活，可以根據實際需求進行靈活的組合和使用，提高了系統的可維護性和可重用性。
每個服務可以獨立使用數據庫：每個服務可以使用自己的數據庫，這使得每個服務都可以根據其業務需求獨立地存儲和檢索數據。
開發體驗好：由于每個服務都是獨立的，開發人員只需要關注自己的業務領域，這使得開發更加快速和高效。
按需擴容：由于每個服務都可以獨立地進行部署和擴展，因此可以根據需求進行靈活的擴容。

微服務的缺點主要包括：

處理故障難度高：由于微服務是分布式系統，故障的處理可能會更加復雜。例如，當某個服務出現故障時，需要確定故障的原因并進行修復，這可能需要跨多個服務進行調試和排查。
部署工作量大：由于每個服務都需要進行獨立的部署，因此部署的工作量可能會比單體應用程序要大得多。
測試復雜度高：由于微服務之間存在復雜的依賴關系，因此測試的復雜度可能會比單體應用程序要高。
運營成本增加：由于每個服務都需要進行獨立的監控和管理，因此運營的成本可能會比單體應用程序要高。
發布風險高：由于每個服務都可能有自己的發布計劃和時間表，因此可能會出現不同服務的版本不一致的情況，這可能會導致一些潛在的風險。
分布性系統問題：由于微服務是分布式系統，因此可能會面臨一些分布式系統的常見問題，例如網絡延遲、服務調用失敗、系統容量規劃等。

簡述分布式和微服務的區別？

分布式和微服務雖然都是一種架構風格，但它們有著不同的設計和部署特點。

微服務架構是一種將應用程序拆分成多個小型、獨立的服務，每個服務都運行在其自己的進程中，具有明確的業務能力，并且可以獨立開發、測試、部署和擴展。微服務架構的核心思想是將應用程序分解為多個小型服務，每個服務都具有獨立的功能和責任。每個服務都可以獨立地開發、測試、部署和擴展，從而提高了應用程序的可維護性、可擴展性和靈活性。

分布式系統則是將若干獨立計算機的集合，這些計算機對用戶來說就像單個相關系統。分布式系統常用于處理大型應用程序，將應用程序的不同部分部署在不同的計算機上，并通過網絡通信進行數據交互。分布式系統可以處理大量的并發用戶請求，并且具有較高的可靠性和容錯性。

總的來說，分布式系統和微服務架構在設計和部署上存在明顯的差異。微服務架構更側重于服務的拆分和獨立部署，而分布式系統更側重于不同計算機的協作和共同工作。

簡述微服務的服務怎么劃分原則？

微服務的服務劃分原則主要包括以下幾點：

單一職責原則：每個微服務應該只負責一個特定的業務功能。單一職責原則有助于保持服務的聚焦和簡單，便于獨立開發和維護。如果一個服務承擔了過多的職責，它可能會變得臃腫和復雜，從而影響到整個系統的健壯性和可維護性。
業務領域驅動劃分：根據應用程序的業務需求和領域知識來對服務進行劃分。這通常需要與業務專家和開發人員緊密合作，共同識別和定義各個領域的邊界。通過領域驅動的劃分，可以確保各個微服務的業務邏輯緊密聯系在一起，便于維護和拓展。
層次結構清晰：微服務要有層次結構，不能形成網狀，應該要有比較清晰的層次劃分，分為高、低層，每層可以有多個服務，高層單向調用低層，同一層級之間可互調。
獨立性：每個微服務都應該是獨立的、可獨立部署和擴展的。每個服務都應該具有自己的數據庫、通信機制和身份驗證等獨立的功能模塊。
可擴展性：每個微服務都應該能夠獨立地進行擴展，例如增加服務器、數據庫等資源，以滿足不斷增長的用戶需求。
松耦合：微服務之間的依賴關系應該盡量減少，每個微服務都可以獨立地運行和更新。這可以提高系統的容錯性和可維護性。
獨立部署和擴展：每個微服務都應該能夠獨立地進行部署和擴展，以滿足不同用戶的需求和服務質量要求。
服務間通信簡單：微服務之間的通信機制應該簡單、可靠和高效，例如使用RESTful API或者消息隊列等。
數據一致性：在分布式系統中，數據一致性是一個重要的問題。微服務架構需要處理不同服務之間的數據一致性問題，例如使用分布式事務或者基于消息的異步通信等。
日志和監控：每個微服務都應該具有獨立的日志和監控機制，以便及時發現和解決問題。

總之，微服務的服務劃分原則是確保每個微服務都具有清晰的責任和邊界，便于獨立開發、部署、擴展和維護。同時，要確保整個系統的松耦合和高內聚性，以提高系統的可靠性和可維護性。

請列舉微服務設計原則？

微服務設計原則主要包括以下幾點：

獨立性：每個微服務都應該是獨立的、可獨立部署和擴展的。這意味著每個微服務都應該具有自己的數據庫、通信機制和身份驗證等獨立的功能模塊。
單一職責原則：每個微服務應該只負責一個特定的業務功能。這有助于保持服務的聚焦和簡單，便于獨立開發和維護。
無狀態性：每個微服務不應該依賴于外部狀態，例如其他服務的狀態或者全局狀態。如果需要外部狀態，應該通過API調用其他服務或者使用緩存來獲取。
輕量級通信：微服務之間應該使用輕量級的通信機制進行通信，例如基于HTTP的RESTful API或者消息隊列等。這可以提高通信的靈活性和可擴展性。
邊界明確：每個微服務的邊界應該明確，具有清晰的職責和范圍。這有助于確保服務的獨立性和可維護性。
高內聚性：每個微服務的內部功能應該緊密聯系在一起，共同實現一個特定的業務功能。這有助于保持服務的內聚性和可維護性。
松耦合：微服務之間的依賴關系應該盡量減少，每個微服務都可以獨立地運行和更新。這可以提高系統的容錯性和可維護性。
獨立部署和擴展：每個微服務都應該能夠獨立地進行部署和擴展，以滿足不同用戶的需求和服務質量要求。
高度可配置性：每個微服務都應該具有高度可配置性，以便根據實際需求進行靈活的配置和調整。
安全性：每個微服務都應該具有必要的安全措施，例如身份驗證、授權、數據加密等，以確保數據的安全性和隱私保護。

總之，微服務設計原則是確保每個微服務都具有清晰的責任和邊界，便于獨立開發、部署、擴展和維護。同時，要確保整個系統的松耦合和高內聚性，以提高系統的可靠性和可維護性。

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

微服務之間可以通過不同的通信方式進行通信，包括同步通信和異步通信。

同步通信是指微服務之間通過請求-響應的方式進行通信，例如RESTful API和RPC。在同步通信中，請求方需要等待響應方的返回結果，因此可靠性較高，但可能會出現請求排隊、線程阻塞等問題，從而影響系統的響應速度和并發性能。

異步通信是指微服務之間通過消息隊列進行異步通信，例如Kafka和RabbitMQ。在異步通信中，發送方向消息隊列發送消息，接收方從消息隊列中消費消息，消息傳輸以異步的方式進行，不需要等待接收方的響應。由于解耦性高，消息隊列還可以支持發布-訂閱模式，消息得以廣播到多個服務中，助于構建高可伸縮的系統。不過異步通信也可能導致延遲較高，以及可靠性和容錯性較差等問題。

在微服務架構中，通常會根據實際需求選擇合適的通信方式。

簡述微服務通信協議選擇的方式以及考慮因素？

微服務通信協議的選擇方式以及考慮因素主要包括以下幾點：

性能：性能是服務間通信協議最重要的衡量標準之一。在分布式環境下，服務間通信協議的性能直接影響著系統的整體性能。一些常見的性能指標包括延遲、吞吐量和并發性。因此，在選擇通信協議時，需要充分考慮這些性能指標，選擇能夠滿足系統需求的通信協議。
可靠性：可靠性是指通信協議在傳輸數據時的可靠性。在微服務架構中，由于服務之間是相互獨立的，因此需要保證通信協議的可靠性，以確保數據傳輸的完整性和準確性。一些常見的可靠性措施包括數據校驗、重試機制和容錯處理等。
易用性：易用性是指通信協議的易用程度，包括開發難度、調試和維護的便利性等。在選擇通信協議時，需要考慮開發人員的技術水平和經驗，選擇易于理解和使用的通信協議。
可擴展性：可擴展性是指通信協議的可擴展性，包括對不同服務之間通信需求的適應能力、對未來技術發展的適應性等。在選擇通信協議時，需要考慮系統的擴展需求，選擇具有可擴展性的通信協議。
安全性：安全性是指通信協議的安全性，包括數據傳輸的加密、身份驗證和授權等。在選擇通信協議時，需要考慮系統的安全性需求，選擇具有安全性的通信協議，以保護數據的安全性和隱私性。

綜上所述，微服務通信協議的選擇需要結合實際需求和系統特點，綜合考慮性能、可靠性、易用性、可擴展性和安全性等因素，以選擇最適合的通信協議。

請簡述微服務中各組件的作用？

微服務中的各組件及其作用如下：

服務注冊中心：這是微服務架構的核心組件，它負責服務的注冊和狀態維護。通常采用心跳機制，以確保其持有的服務節點列表都是可用的。
負載均衡器：這個組件通過服務名在注冊中心查詢該服務擁有哪些可用節點，然后注冊中心返回可用節點列表給服務調用者。服務調用者內置負載均衡器，根據負載均衡策略，選擇可用節點列表中的服務進行服務調用。
服務通信組件：這些組件負責實現服務間的調用。它們通常采用輕量級通信協議，如HTTP RESTful風格，并且可以使用Feign和Restemplate等API進行實現。
服務網關：這是微服務架構中的對外統一調用地址，對內部進行封裝。它提供對外的統一調用地址，對內部進行封裝，并具有API網關的作用。它還可以提供用戶認證與授權、限流和熔斷等功能。
統一配置組件：這是一種基礎設施，用于全局的配置，統一管理不同服務的配置。

簡述什么是服務注冊與發現？

服務注冊與發現是微服務架構中的重要概念，它們幫助實現服務的動態發現和調用。

服務注冊是指將服務實例的信息注冊到服務注冊中心。在微服務架構中，每個服務都是獨立運行的，并通過服務注冊中心來管理和調用。當一個服務實例啟動時，它會向服務注冊中心注冊自己的信息，包括服務名稱、IP地址、端口號等。

服務發現是指客戶端應用進程向注冊中心發起查詢，來獲取服務的位置。服務發現的一個重要作用就是提供一個可用的服務列表。客戶端可以通過查詢服務注冊表來獲取需要調用的服務的相關信息，從而實現服務之間的通信。

服務注冊與發現的作用是解耦了服務之間的直接依賴關系，使得服務之間可以動態地發現和調用。通過服務注冊，可以實現服務的高可用性和負載均衡，當某個服務實例不可用時，可以自動剔除或替換，從而保證整個系統的穩定性和可靠性。同時，服務注冊還能提供服務的版本管理、動態擴縮容等功能，為微服務架構帶來更大的靈活性和可擴展性。

在微服務架構中，常見的服務注冊與發現機制包括Eureka、Consul和Zookeeper等。其中，Eureka是Spring Cloud的默認選擇，每個服務實例在啟動時都會向Eureka服務器注冊自己的信息，Eureka服務器會維護一個服務注冊表，用于保存所有已注冊的服務實例信息。其他服務可以通過查詢這個注冊表來獲取需要調用的服務的相關信息。

請列舉常用的服務注冊發現的組件？

常用的服務注冊發現組件包括：

Consul：Consul是一個開源的服務網絡解決方案，提供了完整的服務發現、配置和分段功能。它是一個輕量級的解決方案，可以跨平臺和跨云使用。
Eureka：Eureka是Netflix開源的一個服務注冊和發現框架，用于在分布式系統中管理和發現微服務。Eureka采用了基于HTTP的RESTful API的設計，使得它很容易集成到Spring Cloud生態系統中。
ZooKeeper：ZooKeeper是一個分布式協調服務，提供了基于名稱的注冊和發現服務。它可以幫助開發人員構建分布式系統中的服務注冊和發現解決方案。
etcd：etcd是一個高可用的鍵值存儲系統，用于在分布式系統中管理和發現微服務。etcd提供了基于HTTP的RESTful API，并采用了Raft協議來保證系統的可靠性和一致性。
Nacos：Nacos是阿里巴巴開源的一個更易于構建云原生應用的動態服務發現、配置管理和服務管理平臺。它提供了一站式的服務發現和配置管理功能，支持配置管理和服務發現。

這些服務注冊發現組件可以幫助開發人員構建高可用、可擴展的微服務架構。不同的組件具有不同的特性和適用場景，開發人員可以根據具體需求選擇合適的組件。

簡述什么是服務調用？

服務調用是指一個軟件組件通過調用另一個軟件組件提供的服務來實現某種功能。在分布式系統中，服務調用是一種重要的通信方式，它通過網絡請求實現組件之間的互相調用。在服務調用的過程中，客戶端發起請求，服務端接收請求并處理，然后將處理結果返回給客戶端。通過合理的設計和實現，服務調用可以提高系統的可用性、擴展性和靈活性。在使用服務調用時，需要注意網絡通信、安全性、異常處理和服務注冊與發現等問題，以保證系統的穩定性和可靠性。

請列舉常用的服務調用組件？

常用的服務調用組件包括：

RestTemplate：在Spring Cloud中，RestTemplate是用于進行HTTP請求的模板類，可以用來調用RESTful風格的Web服務。
Feign：Feign是一個聲明式的Web Service客戶端，它使得編寫HTTP客戶端變得更簡單。Feign會自動根據接口定義來生成HTTP請求代碼。
OpenFeign：OpenFeign是Feign的繼任者，它提供了更強大的功能，例如負載均衡和服務發現等。
Dubbo：Dubbo是一個高性能、輕量級的開源Java RPC框架，它提供了遠程過程調用（RPC）功能。Dubbo可以用來調用其他服務，并提供了負載均衡、容錯和路由等功能。
gRPC：gRPC是一個高性能、開源的RPC框架，它提供了面向接口的通信、雙向流式傳輸和頭部壓縮等功能。gRPC支持多種語言，包括Java、Go和C++等。

這些服務調用組件可以幫助開發人員實現分布式系統中的服務間通信和調用。不同的組件具有不同的特性和適用場景，開發人員可以根據具體需求選擇合適的組件。

簡述什么服務降級？

服務降級是指在面對系統負載過高、資源不足或外部依賴故障等異常情況下，通過臨時屏蔽某些功能或改變服務行為，以保證核心功能的可用性和性能穩定性的一種策略。服務降級的目的是在極端或異常情況下提供有限但可靠的服務，而不是完全失敗或導致系統崩潰。服務降級可以在多個層面進行，包括前端、業務邏輯和數據訪問層。前端降級主要通過控制用戶界面上的展示和交互來減少對后端服務的請求，例如在高負載時暫時去除某些耗時的圖表或功能按鈕，只展示核心內容，以提高用戶體驗。業務邏輯降級則是在服務層面進行降級，即在業務邏輯中根據當前系統狀態或用戶需求進行判斷，決定是否執行某些非關鍵的功能或采取替代性方案，例如可以減少搜索的結果數目、緩存數據、限制操作頻率等。數據訪問降級則是在數據庫或其他外部依賴出現故障或性能問題時，使用緩存、降低查詢精確度或返回默認值等方式進行數據訪問降級，以保證系統的可用性，盡管可能犧牲了一些實時性或準確性。

簡述什么熔斷機制？

熔斷機制是一種在分布式系統中常用的容錯措施，它能夠自動發現故障并隔離故障服務，以保證系統可用性。當某個服務單元發生故障時，該服務單元會向熔斷器發出警報，熔斷器判斷出故障服務，并且立即將故障服務與其他服務隔離，從而防止故障服務影響到整個系統。熔斷機制的具體實現方式因系統而異，但通常包括設置一個熔斷價格，使合約買賣報價在一段時間內只能在這一價格范圍內交易，或者通過輕量級通信機制實現服務之間的調用。在2020年3月9日的紐約股市暴跌事件中，熔斷機制被觸發并恢復交易后，股市跌幅一度有所收窄。