👉🏻👉🏻👉🏻👉🏻上文：深造分布式 打敗面試官 招式一 小試牛刀
👉🏻👉🏻👉🏻👉🏻下文：深造分布式 打敗面試官 招式三 直搗黃龍
👉🏻👉🏻👉🏻👉🏻分布式系列訂閱：分布式系列
👏🏻👏🏻👏🏻👏🏻：可關注 評論 及時交流反饋 不斷努力 一起加油 可留下你的👣
👉🏻👉🏻👉🏻👉🏻個人主頁： 個人主頁
👉🏻👉🏻👉🏻👉🏻個人介紹：開發小趴菜 拒絕加班的程序員 為了不加班 只能加油。頹廢又積極的矛盾體 😬

實現分布式服務應該具備哪些核心技術組件？

• • 前言
  • 問題背景
  • • 問題分析
    • 技術體系
    • 遠程過程調用組件
    • • 網絡通信
      • 遠程調用
      • 負載均衡
      • 服務容錯
      • 服務降級
    • 微服務構建組件
    • • 注冊中心
      • 服務網關
    • 配置中心
    • • 消息通信
      • 鏈路跟蹤
    • 通用技術組件
    • • 動態代理
      • 應用緩存
      • 資源管理
      • 框架集成
      • 架構模式
  • 小提示
  • 小結
  • 結尾

前言

面試官: 用過微服務嗎?
我: 用過用過 嘿嘿
面試官: 看你寫的熟悉 那就問一些問題
面試官: 那你說一下 微服務的組件有哪些
我:這個我會 Nacos gateway … 😊
面試官:構建一個微服務 那些是必須的 哪些通用的?
我:🤔 注冊中心,服務網關 ,遠程調用,配置中心,鏈路跟蹤 呃 差不多是這些
面試官: 如果想實現一套遠程過程調用機制，你會重點設計哪幾個技術組件?
我:呃 都是架構師設計 我擰螺絲的 不太清楚
面試官:想要實現服務容錯，有哪些技術手段？
我:🤔 下一個
面試官: 好 的面試就這樣 我們三天內答復你
我:😒 內心os 理論還是很重要的 回去復習
在上一文中，我們系統分析了分布式系統和單體系統之間的區別。在互聯網應用程序開發過程中，構建分布式服務已經是開發人員所應該具備的最基本的技術能力之一。打開招聘網站，你會發現無論是針對普通開發人員、還是架構師，都會涉及到對分布式服務中各種技術組件的考查要求。

那么，實現分布式服務應該具備哪些核心技術組件呢？大概很多人都能說出一些 但是我相信大部分人其實很少去將這些組件進行連接 僅僅知道這些組件的作用 時而想起 時而忘記 實戰的基礎是理論 需要整理一下思路。

問題背景

分布式服務是構建分布式系統的基礎，可以認為，任何一個分布式系統都是有若干個獨立的服務所構成，這些服務通過網絡通信實現相互調用，從而完成復雜的業務處理流程。上一篇文章我們也知道 相對于單體項目 分布式是將模塊進行拆分 通過多模塊之間的協作進行工作如下圖所示：

雖然，上圖看起來并不復雜，但想要實現一套高性能、高可用、高擴展的分布式服務體系絕非易事。在日常開發過程中，我們在設計和實現分布式系統時需要系統梳理構建分布式服務的各個技術組件。而在實際的面試過程中這也是非常常見的一個面試問題。

問題分析

相信只要你開發過分布式系統，基本上都能對構建分布式服務所需要的技術組件說出個一二三來，比方說網絡通信、遠程調用。你可能也會提到負載均衡、集群容錯這些更為復雜的名詞。事實上，分布式服務的技術組件之間是有一定的邏輯關系的，有些組件能夠獨立運行，而有些組件則是構建在另一些組件的基礎之上。比較典型的例子就是：配置中心的運行往往需要注冊中心的支持，而服務容錯則依賴于負載均衡的實現。

另一方面，對于分布式服務而言，組件與組件之間的定位也有所區別。有些是必備組件，缺少了它們系統就無法運行。有些則是擴展性組件，比較典型的就是前面提到的配置中心，原則上我們不使用配置中心也照樣可以構建分布式系統。而還有一些則是通用型組件，這些組件并不局限于只能用于構建分布式服務，例如動態代理組件。

這道題的問法其實有很多種，常見的包括：

• 如果想實現一套遠程過程調用機制，你會重點設計哪幾個技術組件？
• 負載均衡機制是如何與集群容錯機制整合在一起的？
• 想要實現服務容錯，有哪些技術手段？
• 微服務架構中，配置中心是如何與注冊中心進行交互的？
• 為什么在分布式系統中，處處是代理？
• 在分布式服務構建過程中，經常用到的架構模式有哪些？

這些問題雖然問法各異，但考察人對分布式服務中核心組件的理解程度。通過這樣的分析，我們發現這一問題的難點在于我們要回答的概念有很多，而這些概念卻又比較零散。當我們面對這種發散型問題時，應對的方式絕對不能發散。單純做零散的概念性闡述，往往很難得到認可，因為會覺得你是剛接觸分布式服務，沒有自己的思考和體系。

應對這一問題的基本思路是要具備完整的技術認知，然后能夠用自己的語言對各個組件的組成結構和基本原理做一定的展開，這樣的話這道題應對起來就會比較自如。

因此，接下來我們就一起系統梳理該問題背后的技術體系。

技術體系

在分布式服務的開發過程中，開發人員需要應用到一批技術組件。按照這些技術組件的不同定位，在本講中，我們把它們分成三大類，即遠程過程調用組件、微服務構建組件和通用技術組件，如下圖所示：

接下來，我們將對上圖中的每一個技術組件做展開，這個是學習分布式的基礎。

遠程過程調用組件

遠程過程調用是分布式服務最基礎的實現技術，開發人員需要從網絡通信、遠程調用、負載均衡、服務容錯以及服務降級這五個維度來進行系統的理解。

網絡通信

第一個，網絡通信。 網絡通信是一切分布式操作的基礎。當客戶端和服務器端建立網絡連接之后就可以相互發送消息。但圍繞網絡通信整個過程，事情并沒有那么簡單。我們需要考慮網絡通信的性能、可靠性以及在通信過程中實現數據傳輸的方式，這就涉及到 IO 模型、可靠性設計以及序列化方式等一系列技術主題。

遠程調用

第二個，遠程調用。 遠程調用解決的問題是如何發布遠程服務以及如何引用遠程服務。一旦服務發布成功，就相當于構建了一個有效的網絡連接，并通過啟動監聽端口來對外暴露服務訪問的入口；而服務引用則是一個向目標監聽端點發起請求并獲取響應結果的執行過程，如下圖所示：

在服務調用過程中，遠程調用本地化是基本要求，即遠程調用過程的實現對于開發人員而言應該是透明化的。同時，我們也需要考慮同步調用、異步調用以及同步轉異步調用等一系列具體的調用實現策略。

負載均衡

第三個，負載均衡。 所謂負載均衡，簡單講就是將請求按照一定的策略分攤到多個服務實例上進行執行，基本結構如下圖所示：

負載均衡在實現上可以使用硬件、軟件或者兩者兼有。而針對軟件負載均衡，也可以分成服務器端負載均衡和客戶端負載均衡兩大類。在分布式服務構建過程中，我們主要的討論對象是基于軟件的客戶端負載均衡機制。例如，目前主流的微服務架構實現框架 Spring Cloud、Dubbo 等都內置了完整的客戶端負載均衡模塊。

另一方面，負載均衡算法決定了對請求進行分發的效果。負載均衡算法有很多，可以分成靜態和動態兩個大類，它們之間的區別在于動態算法依賴于當前服務的運行時狀態，這些狀態信息通常包括服務過去一段時間的平均調用時延和所承接的連接數等。

服務容錯

第四個，服務容錯。 在分布式環境中，服務訪問出錯了該怎么辦？這就涉及到服務可靠性問題。服務可靠性是分布式服務構建過程中的一項關鍵要素，我們需要引入容錯思想和機制。常見的服務容錯技術包括集群容錯、服務熔斷（Circuit Breaker）和服務回退（Fallback）等。下圖展示的是添加了服務容錯機制的系統架構演進過程：

服務降級

第五個，服務降級。 從概念上講，任何一個服務都是可以分等級的。具體的服務分級方法因業務場景和需求而定。一旦我們實現了對服務的針對性分級，那么就可以對那些處于業務鏈路最外圍、等級最低的服務開始執行降級。至于如何對服務進行分級，可以按照需求采取一定的策略，例如常見的三級分類策略，如下圖所示：

在上圖中，一級服務屬于核心服務，需要確保高可用，不能執行降級操作；二級服務通常采用的是異步交互方式，容忍暫時的數據不一致性；而三級服務則可以按需對整個服務實行降級操作。

微服務構建組件

在遠程過程調用組件的基礎上，我們繼續討論微服務構建組件，包括注冊中心、服務網關、配置中心、消息通信和鏈路跟蹤。這些組件擴展了分布式技術能力，為構建大規模分布式系統提供了技術保障。

注冊中心

第一個，注冊中心。 在分布式服務構建過程中，服務與服務之間通過遠程調用完成業務鏈路的構建。而在服務調用之前，我們首先需要發現服務，即解決在分布式集群環境下如何找到目標服務實例這一問題。服務發現和調用構成了服務交互的基礎，整體流程下圖所示，其中實線部分代表服務調用流程，而虛線部分則包含了服務的注冊（Registration）和發現（Discovery）過程。

可以看到，圖中的這三個服務都需要注冊到注冊中心以確保負載均衡器能夠從注冊中心獲取各個服務的定義信息。

服務網關

第二個，服務網關。 在分布式系統中，API 網關（Gateway）或服務網關（Service Gateway）的出現有其必然性。我們可以根據需要在服務提供者和消費者之間架設這層服務網關。在注冊中心和負載均衡的基礎上，添加了服務網關之后的系統架構如下圖所示：

當然，并不是所有的服務調用鏈路上都需要添加這層網關，我們也可以根據具體場景直接通過負載均衡器進行服務訪問。在實際應用過程中，這種混合式的服務調用管理方式也是一種常見的做法。

配置中心

第三個，配置中心。 面對不斷增長的服務實例數量，傳統的配置信息管理方式就顯得無能為力。為此，在分布式服務構建過程中，一般都需要引入配置中心（Configuration Center）的設計思想和相關工具。下圖展示了在前面各個組件的基礎上添加配置中心之后的系統架構圖，分布式系統中的各個服務都可能會依賴配置中心，從而完成配置信息的統一管理。

消息通信

第四個，消息通信。 降低服務與服務之間的耦合度是分布式系統設計的一大目標，為此，我們可以引入事件驅動架構，基本組成如下圖所示：

基于事件驅動架構，每一個服務既可以作為事件的發布者也可以作為事件的消費者，或者兩者兼之。而事件也可以在不同的服務之間進行傳播，從而滿足各種特定的應用場景。

鏈路跟蹤

第五個，鏈路跟蹤。 服務之間的調用不可避免會出現各種問題，這時候就需要引入分布式鏈路跟蹤體系來定位和解決這些問題。基于每一次分布式請求，我們都可以捕獲該請求的一系列跟蹤數據，下圖展示了基于 TraceId 和 SpanId 所構建的一次服務調用的完整鏈路。

服務調用鏈路跟蹤是分布式系統的基礎需求之一，業界關于分布式鏈路跟蹤也有統一的規范以及代表性的實現框架。

通用技術組件

在分布式服務構建過程中，也需要引入一組通用型的技術組件，這些技術組件在多個場景中（不僅限于分布式系統）都能發揮作用。本文梳理了五種通用技術組件，包括動態代理、應用緩存、資源管理、框架集成以及架構模式。這種技術組件有些關注于具體某一個技術實現要點，有些則關注于框架的應用以及架構設計的方法和實踐。

動態代理

第一個，動態代理。 在日常開發過程中，動態代理可以說是一種通用性非常高的實現機制，它是面向切面編程的基礎，也在主流的分布式服務開源框架中得到了廣泛的應用。通過代理機制，一個對象就可以在承接另一個對象功能的同時添加新的功能。相比直接在原有對象中嵌入代碼，代理機制為我們提供了更為優雅的解決方案。

應用緩存

第二個，應用緩存。 對于分布式服務而言，緩存應用非常廣泛，開發人員可以使用位于應用程序內部的本地緩存，也可以使用位于獨立服務器上的分布式緩存。在日常開發中，緩存的應用通常都是分層級的，我們會綜合使用多級緩存來提高目標對象訪問的效率和性能。

資源管理

第三個，資源管理。 相信你對線程池、數據庫連接池等技術并不陌生。這里的池（Pool）是一種對資源的抽象方法，代表一組可以隨時使用的資源，但這些資源的創建和釋放過程則基于一定的管理策略。資源池的應用非常廣泛，存在多種具體的池化組件。

框架集成

第四個，框架集成。 這里所說的框架集成，指的是 Dubbo、MyBatis、Spring Cloud 等主流的分布式開發框架與 Spring 框架之間的集成。我們可以基于命名空間以及自定義 starter 等機制完成與 Spring 之間的有效集成。理解框架集成的實現過程有利于掌握主流的分布式服務框架的運行原理。

架構模式

第五個，架構模式。 架構模式描述某一特定應用領域中系統組織和表現的慣用方式。對軟件體系架構模式的研究和實踐促進了對軟件設計的重用。在分布式系統開發過程中，也大量應用了諸如微內核架構、管道-過濾器架構等架構模式，這些模式能夠為開發人員提供具有高度擴展性的技術組件。

小提示

通過對技術體系的系統分析，我們明白了構建一個分布式服務系統所需要的各個技術組件。這里涉及了一大批專用名詞。但是，光列舉這些名稱就夠了嗎？答案顯然是否定的。
我們在解釋這些名詞時需要做一些擴展，多提及技術組件的關聯關系，從而確保回答過程具備較好的邏輯性。這是解答這個問題的第一點思路。例如，我們在介紹注冊中心時，需要提到該組件與負載均衡之間的集成關系。
針對該問題的第二點解答思路在于回歸現實中的實踐。本文中介紹的技術組件都是很常見和很通用的，一般的分布式系統構建過程中都會使用到。你完全可以基于自己在日常開發過程中的應用情況來對這些組件做一定的展開。因為這是一道偏概念闡述的問題。

小結

分布式服務的相關組件雖然比較多，但并不難梳理和串聯。正如我們在前面所討論到的，很多技術組件的出現是必然的，而有些組件之間具備一定的相互關聯關系。在本文內容中，我們從遠程調用、微服務以及通用技術組件這三大維度出發來對這些組件進行了分類，并針對每個類別梳理了五大技術組件，以幫助你能夠更好地理解和把握，從而形成自己的知識體系

結尾

后續持續更新 建議一鍵三連 但是你也可以不接受我的建議
下文：直搗黃龍

總結

以上是生活随笔為你收集整理的深造分布式 打败面试官 招式二 新手上路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。