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

實(shí)現(xiàn)分布式服務(wù)應(yīng)該具備哪些核心技術(shù)組件？

• • 前言
  • 問題背景
  • • 問題分析
    • 技術(shù)體系
    • 遠(yuǎn)程過程調(diào)用組件
    • • 網(wǎng)絡(luò)通信
      • 遠(yuǎn)程調(diào)用
      • 負(fù)載均衡
      • 服務(wù)容錯(cuò)
      • 服務(wù)降級(jí)
    • 微服務(wù)構(gòu)建組件
    • • 注冊(cè)中心
      • 服務(wù)網(wǎng)關(guān)
    • 配置中心
    • • 消息通信
      • 鏈路跟蹤
    • 通用技術(shù)組件
    • • 動(dòng)態(tài)代理
      • 應(yīng)用緩存
      • 資源管理
      • 框架集成
      • 架構(gòu)模式
  • 小提示
  • 小結(jié)
  • 結(jié)尾

前言

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

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

問題背景

分布式服務(wù)是構(gòu)建分布式系統(tǒng)的基礎(chǔ)，可以認(rèn)為，任何一個(gè)分布式系統(tǒng)都是有若干個(gè)獨(dú)立的服務(wù)所構(gòu)成，這些服務(wù)通過網(wǎng)絡(luò)通信實(shí)現(xiàn)相互調(diào)用，從而完成復(fù)雜的業(yè)務(wù)處理流程。上一篇文章我們也知道 相對(duì)于單體項(xiàng)目 分布式是將模塊進(jìn)行拆分 通過多模塊之間的協(xié)作進(jìn)行工作如下圖所示：

雖然，上圖看起來并不復(fù)雜，但想要實(shí)現(xiàn)一套高性能、高可用、高擴(kuò)展的分布式服務(wù)體系絕非易事。在日常開發(fā)過程中，我們?cè)谠O(shè)計(jì)和實(shí)現(xiàn)分布式系統(tǒng)時(shí)需要系統(tǒng)梳理構(gòu)建分布式服務(wù)的各個(gè)技術(shù)組件。而在實(shí)際的面試過程中這也是非常常見的一個(gè)面試問題。

問題分析

相信只要你開發(fā)過分布式系統(tǒng)，基本上都能對(duì)構(gòu)建分布式服務(wù)所需要的技術(shù)組件說出個(gè)一二三來，比方說網(wǎng)絡(luò)通信、遠(yuǎn)程調(diào)用。你可能也會(huì)提到負(fù)載均衡、集群容錯(cuò)這些更為復(fù)雜的名詞。事實(shí)上，分布式服務(wù)的技術(shù)組件之間是有一定的邏輯關(guān)系的，有些組件能夠獨(dú)立運(yùn)行，而有些組件則是構(gòu)建在另一些組件的基礎(chǔ)之上。比較典型的例子就是：配置中心的運(yùn)行往往需要注冊(cè)中心的支持，而服務(wù)容錯(cuò)則依賴于負(fù)載均衡的實(shí)現(xiàn)。

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

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

• 如果想實(shí)現(xiàn)一套遠(yuǎn)程過程調(diào)用機(jī)制，你會(huì)重點(diǎn)設(shè)計(jì)哪幾個(gè)技術(shù)組件？
• 負(fù)載均衡機(jī)制是如何與集群容錯(cuò)機(jī)制整合在一起的？
• 想要實(shí)現(xiàn)服務(wù)容錯(cuò)，有哪些技術(shù)手段？
• 微服務(wù)架構(gòu)中，配置中心是如何與注冊(cè)中心進(jìn)行交互的？
• 為什么在分布式系統(tǒng)中，處處是代理？
• 在分布式服務(wù)構(gòu)建過程中，經(jīng)常用到的架構(gòu)模式有哪些？

這些問題雖然問法各異，但考察人對(duì)分布式服務(wù)中核心組件的理解程度。通過這樣的分析，我們發(fā)現(xiàn)這一問題的難點(diǎn)在于我們要回答的概念有很多，而這些概念卻又比較零散。當(dāng)我們面對(duì)這種發(fā)散型問題時(shí)，應(yīng)對(duì)的方式絕對(duì)不能發(fā)散。單純做零散的概念性闡述，往往很難得到認(rèn)可，因?yàn)闀?huì)覺得你是剛接觸分布式服務(wù)，沒有自己的思考和體系。

應(yīng)對(duì)這一問題的基本思路是要具備完整的技術(shù)認(rèn)知，然后能夠用自己的語言對(duì)各個(gè)組件的組成結(jié)構(gòu)和基本原理做一定的展開，這樣的話這道題應(yīng)對(duì)起來就會(huì)比較自如。

因此，接下來我們就一起系統(tǒng)梳理該問題背后的技術(shù)體系。

技術(shù)體系

在分布式服務(wù)的開發(fā)過程中，開發(fā)人員需要應(yīng)用到一批技術(shù)組件。按照這些技術(shù)組件的不同定位，在本講中，我們把它們分成三大類，即遠(yuǎn)程過程調(diào)用組件、微服務(wù)構(gòu)建組件和通用技術(shù)組件，如下圖所示：

接下來，我們將對(duì)上圖中的每一個(gè)技術(shù)組件做展開，這個(gè)是學(xué)習(xí)分布式的基礎(chǔ)。

遠(yuǎn)程過程調(diào)用組件

遠(yuǎn)程過程調(diào)用是分布式服務(wù)最基礎(chǔ)的實(shí)現(xiàn)技術(shù)，開發(fā)人員需要從網(wǎng)絡(luò)通信、遠(yuǎn)程調(diào)用、負(fù)載均衡、服務(wù)容錯(cuò)以及服務(wù)降級(jí)這五個(gè)維度來進(jìn)行系統(tǒng)的理解。

網(wǎng)絡(luò)通信

第一個(gè)，網(wǎng)絡(luò)通信。 網(wǎng)絡(luò)通信是一切分布式操作的基礎(chǔ)。當(dāng)客戶端和服務(wù)器端建立網(wǎng)絡(luò)連接之后就可以相互發(fā)送消息。但圍繞網(wǎng)絡(luò)通信整個(gè)過程，事情并沒有那么簡(jiǎn)單。我們需要考慮網(wǎng)絡(luò)通信的性能、可靠性以及在通信過程中實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)姆绞?#xff0c;這就涉及到 IO 模型、可靠性設(shè)計(jì)以及序列化方式等一系列技術(shù)主題。

遠(yuǎn)程調(diào)用

第二個(gè)，遠(yuǎn)程調(diào)用。 遠(yuǎn)程調(diào)用解決的問題是如何發(fā)布遠(yuǎn)程服務(wù)以及如何引用遠(yuǎn)程服務(wù)。一旦服務(wù)發(fā)布成功，就相當(dāng)于構(gòu)建了一個(gè)有效的網(wǎng)絡(luò)連接，并通過啟動(dòng)監(jiān)聽端口來對(duì)外暴露服務(wù)訪問的入口；而服務(wù)引用則是一個(gè)向目標(biāo)監(jiān)聽端點(diǎn)發(fā)起請(qǐng)求并獲取響應(yīng)結(jié)果的執(zhí)行過程，如下圖所示：

在服務(wù)調(diào)用過程中，遠(yuǎn)程調(diào)用本地化是基本要求，即遠(yuǎn)程調(diào)用過程的實(shí)現(xiàn)對(duì)于開發(fā)人員而言應(yīng)該是透明化的。同時(shí)，我們也需要考慮同步調(diào)用、異步調(diào)用以及同步轉(zhuǎn)異步調(diào)用等一系列具體的調(diào)用實(shí)現(xiàn)策略。

負(fù)載均衡

第三個(gè)，負(fù)載均衡。 所謂負(fù)載均衡，簡(jiǎn)單講就是將請(qǐng)求按照一定的策略分?jǐn)偟蕉鄠€(gè)服務(wù)實(shí)例上進(jìn)行執(zhí)行，基本結(jié)構(gòu)如下圖所示：

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

另一方面，負(fù)載均衡算法決定了對(duì)請(qǐng)求進(jìn)行分發(fā)的效果。負(fù)載均衡算法有很多，可以分成靜態(tài)和動(dòng)態(tài)兩個(gè)大類，它們之間的區(qū)別在于動(dòng)態(tài)算法依賴于當(dāng)前服務(wù)的運(yùn)行時(shí)狀態(tài)，這些狀態(tài)信息通常包括服務(wù)過去一段時(shí)間的平均調(diào)用時(shí)延和所承接的連接數(shù)等。

服務(wù)容錯(cuò)

第四個(gè)，服務(wù)容錯(cuò)。 在分布式環(huán)境中，服務(wù)訪問出錯(cuò)了該怎么辦？這就涉及到服務(wù)可靠性問題。服務(wù)可靠性是分布式服務(wù)構(gòu)建過程中的一項(xiàng)關(guān)鍵要素，我們需要引入容錯(cuò)思想和機(jī)制。常見的服務(wù)容錯(cuò)技術(shù)包括集群容錯(cuò)、服務(wù)熔斷（Circuit Breaker）和服務(wù)回退（Fallback）等。下圖展示的是添加了服務(wù)容錯(cuò)機(jī)制的系統(tǒng)架構(gòu)演進(jìn)過程：

服務(wù)降級(jí)

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

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

微服務(wù)構(gòu)建組件

在遠(yuǎn)程過程調(diào)用組件的基礎(chǔ)上，我們繼續(xù)討論微服務(wù)構(gòu)建組件，包括注冊(cè)中心、服務(wù)網(wǎng)關(guān)、配置中心、消息通信和鏈路跟蹤。這些組件擴(kuò)展了分布式技術(shù)能力，為構(gòu)建大規(guī)模分布式系統(tǒng)提供了技術(shù)保障。

注冊(cè)中心

第一個(gè)，注冊(cè)中心。 在分布式服務(wù)構(gòu)建過程中，服務(wù)與服務(wù)之間通過遠(yuǎn)程調(diào)用完成業(yè)務(wù)鏈路的構(gòu)建。而在服務(wù)調(diào)用之前，我們首先需要發(fā)現(xiàn)服務(wù)，即解決在分布式集群環(huán)境下如何找到目標(biāo)服務(wù)實(shí)例這一問題。服務(wù)發(fā)現(xiàn)和調(diào)用構(gòu)成了服務(wù)交互的基礎(chǔ)，整體流程下圖所示，其中實(shí)線部分代表服務(wù)調(diào)用流程，而虛線部分則包含了服務(wù)的注冊(cè)（Registration）和發(fā)現(xiàn)（Discovery）過程。

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

服務(wù)網(wǎng)關(guān)

第二個(gè)，服務(wù)網(wǎng)關(guān)。 在分布式系統(tǒng)中，API 網(wǎng)關(guān)（Gateway）或服務(wù)網(wǎng)關(guān)（Service Gateway）的出現(xiàn)有其必然性。我們可以根據(jù)需要在服務(wù)提供者和消費(fèi)者之間架設(shè)這層服務(wù)網(wǎng)關(guān)。在注冊(cè)中心和負(fù)載均衡的基礎(chǔ)上，添加了服務(wù)網(wǎng)關(guān)之后的系統(tǒng)架構(gòu)如下圖所示：

當(dāng)然，并不是所有的服務(wù)調(diào)用鏈路上都需要添加這層網(wǎng)關(guān)，我們也可以根據(jù)具體場(chǎng)景直接通過負(fù)載均衡器進(jìn)行服務(wù)訪問。在實(shí)際應(yīng)用過程中，這種混合式的服務(wù)調(diào)用管理方式也是一種常見的做法。

配置中心

第三個(gè)，配置中心。 面對(duì)不斷增長(zhǎng)的服務(wù)實(shí)例數(shù)量，傳統(tǒng)的配置信息管理方式就顯得無能為力。為此，在分布式服務(wù)構(gòu)建過程中，一般都需要引入配置中心（Configuration Center）的設(shè)計(jì)思想和相關(guān)工具。下圖展示了在前面各個(gè)組件的基礎(chǔ)上添加配置中心之后的系統(tǒng)架構(gòu)圖，分布式系統(tǒng)中的各個(gè)服務(wù)都可能會(huì)依賴配置中心，從而完成配置信息的統(tǒng)一管理。

消息通信

第四個(gè)，消息通信。 降低服務(wù)與服務(wù)之間的耦合度是分布式系統(tǒng)設(shè)計(jì)的一大目標(biāo)，為此，我們可以引入事件驅(qū)動(dòng)架構(gòu)，基本組成如下圖所示：

基于事件驅(qū)動(dòng)架構(gòu)，每一個(gè)服務(wù)既可以作為事件的發(fā)布者也可以作為事件的消費(fèi)者，或者兩者兼之。而事件也可以在不同的服務(wù)之間進(jìn)行傳播，從而滿足各種特定的應(yīng)用場(chǎng)景。

鏈路跟蹤

第五個(gè)，鏈路跟蹤。 服務(wù)之間的調(diào)用不可避免會(huì)出現(xiàn)各種問題，這時(shí)候就需要引入分布式鏈路跟蹤體系來定位和解決這些問題?；诿恳淮畏植际秸?qǐng)求，我們都可以捕獲該請(qǐng)求的一系列跟蹤數(shù)據(jù)，下圖展示了基于 TraceId 和 SpanId 所構(gòu)建的一次服務(wù)調(diào)用的完整鏈路。

服務(wù)調(diào)用鏈路跟蹤是分布式系統(tǒng)的基礎(chǔ)需求之一，業(yè)界關(guān)于分布式鏈路跟蹤也有統(tǒng)一的規(guī)范以及代表性的實(shí)現(xiàn)框架。

通用技術(shù)組件

在分布式服務(wù)構(gòu)建過程中，也需要引入一組通用型的技術(shù)組件，這些技術(shù)組件在多個(gè)場(chǎng)景中（不僅限于分布式系統(tǒng)）都能發(fā)揮作用。本文梳理了五種通用技術(shù)組件，包括動(dòng)態(tài)代理、應(yīng)用緩存、資源管理、框架集成以及架構(gòu)模式。這種技術(shù)組件有些關(guān)注于具體某一個(gè)技術(shù)實(shí)現(xiàn)要點(diǎn)，有些則關(guān)注于框架的應(yīng)用以及架構(gòu)設(shè)計(jì)的方法和實(shí)踐。

動(dòng)態(tài)代理

第一個(gè)，動(dòng)態(tài)代理。 在日常開發(fā)過程中，動(dòng)態(tài)代理可以說是一種通用性非常高的實(shí)現(xiàn)機(jī)制，它是面向切面編程的基礎(chǔ)，也在主流的分布式服務(wù)開源框架中得到了廣泛的應(yīng)用。通過代理機(jī)制，一個(gè)對(duì)象就可以在承接另一個(gè)對(duì)象功能的同時(shí)添加新的功能。相比直接在原有對(duì)象中嵌入代碼，代理機(jī)制為我們提供了更為優(yōu)雅的解決方案。

應(yīng)用緩存

第二個(gè)，應(yīng)用緩存。 對(duì)于分布式服務(wù)而言，緩存應(yīng)用非常廣泛，開發(fā)人員可以使用位于應(yīng)用程序內(nèi)部的本地緩存，也可以使用位于獨(dú)立服務(wù)器上的分布式緩存。在日常開發(fā)中，緩存的應(yīng)用通常都是分層級(jí)的，我們會(huì)綜合使用多級(jí)緩存來提高目標(biāo)對(duì)象訪問的效率和性能。

資源管理

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

框架集成

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

架構(gòu)模式

第五個(gè)，架構(gòu)模式。 架構(gòu)模式描述某一特定應(yīng)用領(lǐng)域中系統(tǒng)組織和表現(xiàn)的慣用方式。對(duì)軟件體系架構(gòu)模式的研究和實(shí)踐促進(jìn)了對(duì)軟件設(shè)計(jì)的重用。在分布式系統(tǒng)開發(fā)過程中，也大量應(yīng)用了諸如微內(nèi)核架構(gòu)、管道-過濾器架構(gòu)等架構(gòu)模式，這些模式能夠?yàn)殚_發(fā)人員提供具有高度擴(kuò)展性的技術(shù)組件。

小提示

通過對(duì)技術(shù)體系的系統(tǒng)分析，我們明白了構(gòu)建一個(gè)分布式服務(wù)系統(tǒng)所需要的各個(gè)技術(shù)組件。這里涉及了一大批專用名詞。但是，光列舉這些名稱就夠了嗎？答案顯然是否定的。
我們?cè)诮忉屵@些名詞時(shí)需要做一些擴(kuò)展，多提及技術(shù)組件的關(guān)聯(lián)關(guān)系，從而確?；卮疬^程具備較好的邏輯性。這是解答這個(gè)問題的第一點(diǎn)思路。例如，我們?cè)诮榻B注冊(cè)中心時(shí)，需要提到該組件與負(fù)載均衡之間的集成關(guān)系。
針對(duì)該問題的第二點(diǎn)解答思路在于回歸現(xiàn)實(shí)中的實(shí)踐。本文中介紹的技術(shù)組件都是很常見和很通用的，一般的分布式系統(tǒng)構(gòu)建過程中都會(huì)使用到。你完全可以基于自己在日常開發(fā)過程中的應(yīng)用情況來對(duì)這些組件做一定的展開。因?yàn)檫@是一道偏概念闡述的問題。

小結(jié)

分布式服務(wù)的相關(guān)組件雖然比較多，但并不難梳理和串聯(lián)。正如我們?cè)谇懊嫠懻摰降?#xff0c;很多技術(shù)組件的出現(xiàn)是必然的，而有些組件之間具備一定的相互關(guān)聯(lián)關(guān)系。在本文內(nèi)容中，我們從遠(yuǎn)程調(diào)用、微服務(wù)以及通用技術(shù)組件這三大維度出發(fā)來對(duì)這些組件進(jìn)行了分類，并針對(duì)每個(gè)類別梳理了五大技術(shù)組件，以幫助你能夠更好地理解和把握，從而形成自己的知識(shí)體系

結(jié)尾

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。