一文讀懂分布式架構知識體系（内含超全核心知識大圖）

點選圖檔或戳我檢視詳情和投履歷

作者 | 曉土  阿裡巴巴進階工程師

姊妹篇閱讀推薦：《

雲原生時代，分布式系統設計必備知識圖譜（内含22個知識點）

》

導讀：本文力求從分布式基礎理論、架構設計模式、工程應用、部署運維、業界方案這幾大方面，介紹基于 MSA（微服務架構）的分布式知識體系大綱，進而對 SOA 到 MSA 進化有着立體的認識；從概念上和工具應用上更近一步了解微服務分布式的本質，身臨其境的感受如何搭建全套微服務架構的過程。

關注“阿裡巴巴雲原生”公衆号，回複“分布”，即可下載下傳分布式系統及其知識體系清晰大圖！

随着移動網際網路的發展和智能終端的普及，計算機系統早就從單機獨立工作過渡到多機器協作，叢集按照分布式理論建構出龐大複雜的應用服務，在分布式的基礎上正進行一場雲原生的技術革命，徹底打破傳統的開發方式，解放了新一代的生産力。

分布式系統知識體系大圖

基礎理論

SOA 到 MSA 的進化

SOA 面向服務架構

由于業務發展到一定程度後，需要對服務進行解耦，進而把一個單一的大系統按邏輯拆分成不同的子系統，通過服務接口來通訊。面向服務的設計模式，最終需要總線內建服務，而且大部分時候還共享資料庫，出現單點故障時會導緻總線層面的故障，更進一步可能會把資料庫拖垮，是以才有了更加獨立的設計方案的出現。

MSA 微服務架構

微服務是真正意義上的獨立服務，從服務入口到資料持久層，邏輯上都是獨立隔離的，無需服務總線來接入，但同時也增加了整個分布式系統的搭建和管理難度，需要對服務進行編排和管理，是以伴随着微服務的興起，微服務生态的整套技術棧也需要無縫接入，才能支撐起微服務的治理理念。

節點與網絡

節點

傳統的節點也就是一台單體的實體機，所有的服務都揉進去包括服務和資料庫；随着虛拟化的發展，單台實體機往往可以分成多台虛拟機，實作資源利用的最大化，節點的概念也變成單台虛拟機上面服務；近幾年容器技術逐漸成熟後，服務已經徹底容器化，也就是節點隻是輕量級的容器服務。總體來說，節點就是能提供機關服務的邏輯計算資源的集合。

網絡

分布式架構的根基就是網絡，不管是區域網路還是公網，沒有網絡就無法把計算機聯合在一起工作，但是網絡也帶來了一系列的問題。網絡消息的傳播有先後，消息丢失和延遲是經常發生的事情，我們定義了三種網絡工作模式：

• 同步網絡
  • 節點同步執行
  • 消息延遲有限
  • 高效全局鎖
• 半同步網絡
  • 鎖範圍放寬
• 異步網絡
  • 節點獨立執行
  • 消息延遲無上限
  • 無全局鎖
  • 部分算法不可行

常用網絡傳輸層有兩大協定的特點簡介：

• TCP 協定
  • 首先 tcp 協定傳輸可靠，盡管其他的協定可以更快傳輸
  • tcp 解決重複和亂序問題
• UDP 協定
  • 常量資料流
  • 丢包不緻命

時間與順序

時間

慢速實體時空中，時間獨自在流淌着，對于串行的事務來說，很簡單的就是跟着時間的腳步走就可以，先來後到的發生。而後我們發明了時鐘來刻畫以往發生的時間點，時鐘讓這個世界井然有序。但是對于分布式世界來說，跟時間打交道着實是一件痛苦的事情。

分布式世界裡面，我們要協調不同節點之間的先來後到關系，不同節點本身承認的時間又各執己見，于是我們創造了網絡時間協定（NTP）試圖來解決不同節點之間的标準時間，但是 NTP 本身表現并不盡如人意，是以我們又構造出了邏輯時鐘，最後改進為向量時鐘：

• NTP 的一些缺點，無法完全滿足分布式下并發任務的協調問題
  • 節點間時間不同步
  • 硬體時鐘漂移
  • 線程可能休眠
  • 作業系統休眠
  • 硬體休眠

• 邏輯時鐘
  • 定義事件先來後到
  • t' = max(t, t_msg + 1)

• 向量時鐘
  • t_i' = max(t_i, t_msg_i)
• 原子鐘

順序

有了衡量時間的工具，解決順序問題自然就是水到渠成了。因為整個分布式的理論基礎就是如何協商不同節點的一緻性問題，而順序則是一緻性理論的基本概念，是以前文我們才需要花時間介紹衡量時間的刻度和工具。

一緻性理論

說到一緻性理論，我們必須看一張關于一緻性強弱對系統建設影響的對比圖：

該圖對比了不同一緻性算法下的事務、性能、錯誤、延遲的平衡。

強一緻性 ACID

單機環境下我們對傳統關系型資料庫有苛刻的要求，由于存在網絡的延遲和消息丢失，ACID 便是保證事務的原則，這四大原則甚至我們都不需要解釋出來就耳熟能詳了：

• Atomicity：原子性，一個事務中的所有操作，要麼全部完成，要麼全部不完成，不會結束在中間某個環節；
• Consistency：一緻性，在事務開始之前和事務結束以後，資料庫的完整性沒有被破壞；
• Isolation：隔離性，資料庫允許多個并發事務同時對其資料進行讀寫和修改的能力，隔離性可以防止多個事務并發執行時，由于交叉執行而導緻資料的不一緻；
• Durabilit：事務處理結束後，對資料的修改就是永久的，即便系統故障也不會丢失。

分布式一緻性 CAP

分布式環境下，我們無法保證網絡的正常連接配接和資訊的傳送，于是發展出了 CAP/FLP/DLS 這三個重要的理論：

• CAP：分布式計算系統不可能同時確定一緻性（Consistency）、可用性（Availablity）和分區容忍性（Partition）；
• FLP：在異步環境中，如果節點間的網絡延遲沒有上限，隻要有一個惡意的節點存在，就沒有算法能在有限的時間内達成共識；
• DLS：
  • 在一個部分同步網絡的模型（也就是說：網絡延時有界限但是我們并不知道在哪裡）下運作的協定可以容忍 1/3 任意（換句話說，拜占庭）錯誤；
  • 在一個異步模型中的确定性的協定（沒有網絡延時上限）不能容錯（不過這個論文沒有提起随機化算法可以容忍 1/3 的錯誤）；
  • 同步模型中的協定（網絡延時可以保證小于已知 d 時間），可以令人吃驚的達到 100% 容錯，雖然對 1/2 的節點出錯可以發生的情況有所限制。

弱一緻性 BASE

多數情況下，其實我們也并非一定要求強一緻性，部分業務可以容忍一定程度的延遲一緻，是以為了兼顧效率，發展出來了最終一緻性理論 BASE。BASE 是指基本可用（Basically Available）、軟狀态（ Soft State）、最終一緻性（ Eventual Consistency）：

• 基本可用（Basically Available）：基本可用是指分布式系統在出現故障的時候，允許損失部分可用性，即保證核心可用；
• 軟狀态（Soft State）：軟狀态是指允許系統存在中間狀态，而該中間狀态不會影響系統整體可用性。分布式存儲中一般一份資料至少會有三個副本，允許不同節點間副本同步的延時就是軟狀态的展現；
• 最終一緻性（Eventual Consistency）：最終一緻性是指系統中的所有資料副本經過一定時間後，最終能夠達到一緻的狀态。弱一緻性和強一緻性相反，最終一緻性是弱一緻性的一種特殊情況。

一緻性算法

分布式架構的核心就在于一緻性的實作和妥協，那麼如何設計一套算法來保證不同節點之間的通信和資料達到無限趨向一緻性，就非常重要了。保證不同節點在充滿不确定性網絡環境下能達成相同副本的一緻性是非常困難的，業界對該課題也做了大量的研究。

首先我們要了解一緻性的大前提原則 (CALM):

CALM 原則的全稱是 Consistency and Logical Monotonicity ，主要描述的是分布式系統中單調邏輯與一緻性的關系，它的内容如下，參考 

consistency as logical monotonicity

。

• 在分布式系統中，單調的邏輯都能保證 “最終一緻性”，這個過程中不需要依賴中心節點的排程；
• 任意分布式系統，如果所有的非單調邏輯都有中心節點排程，那麼這個分布式系統就可以實作最終“一緻性”。

然後再關注分布式系統的資料結構 CRDT(Conflict-Free Replicated Data Types)：

我們了解到分布式一些規律原則之後，就要着手考慮如何來實作解決方案，一緻性算法的前提是資料結構，或者說一切算法的根基都是資料結構，設計良好的資料結構加上精妙的算法可以高效的解決現實的問題。經過前人不斷的探索，我們得知分布式系統被廣泛采用的資料結構 CRDT。

參考

《談談 CRDT》

,

A comprehensive study of Convergent and Commutative Replicated Data Types

• 基于狀态（state-based）：即将各個節點之間的 CRDT 資料直接進行合并，所有節點都能最終合并到同一個狀态，資料合并的順序不會影響到最終的結果；
• 基于操作（operation-based）：将每一次對資料的操作通知給其他節點。隻要節點知道了對資料的所有操作（收到操作的順序可以是任意的），就能合并到同一個狀态。

了解資料結構後，我們需要來關注一下分布式系統的一些重要的協定HATs(Highly Available Transactions)，ZAB(Zookeeper Atomic Broadcast)：

《高可用事務》

，

《ZAB 協定分析》

最後要學習的是業界主流的一緻性算法 ：

說實話具體的算法我也還沒完全搞懂，一緻性算法是分布式系統最核心本質的内容，這部分的發展也會影響架構的革新，不同場景的應用也催生不同的算法。

• Paxos： 《優雅的Paxos算法》
• Raft ： 《Raft 一緻性算法》
• Gossip： 《Gossip Visualization》

這一節我們說完分布式系統裡面核心理論基礎，如何達成不同節點之間的資料一緻性，下面我們将會講到目前都有哪些主流的分布式系統。

場景分類

檔案系統

單台計算機的存儲始終有上限，随着網絡的出現，多台計算機協作存儲檔案的方案也相繼被提出來。最早的分布式檔案系統其實也稱為網絡檔案系統，第一個檔案伺服器在 1970 年代被發展出來。在 1976 年迪吉多公司設計出 File Access Listener（FAL），而現代分布式檔案系統則出自赫赫有名的 Google 的論文，

《The Google File System》

奠定了分布式檔案系統的基礎。現代主流分布式檔案系統參考

《分布式檔案系統對比》

,下面列舉幾個常用的檔案系統：

• HDFS
• FastDFS
• Ceph
• mooseFS

資料庫

資料庫當然也屬于檔案系統，主資料增加了事務、檢索、擦除等進階特性，是以複雜度又增加了，既要考慮資料一緻性也得保證足夠的性能。傳統關系型資料庫為了兼顧事務和性能的特性，在分布式方面的發展有限，非關系型資料庫擺脫了事務的強一緻性束縛，達到了最終一緻性的效果，進而有了飛躍的發展，NoSql(Not Only Sql) 也産生了多個架構的資料庫類型，包括 KV、列式存儲、文檔類型等。

• 列式存儲：Hbase
• 文檔存儲：Elasticsearch，MongoDB
• KV 類型：Redis
• 關系型：Spanner

計算

分布式計算系統建構在分布式存儲的基礎上，充分發揮分布式系統的資料備援災備，多副本高效擷取資料的特性，進而并行計算，把原本需要長時間計算的任務拆分成多個任務并行處理，進而提高了計算效率。分布式計算系統在場景上分為離線計算、實時計算和流式計算。

• 離線：Hadoop
• 實時：Spark
• 流式：Storm，Flink/Blink

緩存

緩存作為提升性能的利器無處不在，小到 CPU 緩存架構，大到分布式應用存儲。分布式緩存系統提供了熱點資料的随機通路機制，大大了提升了通路時間，但是帶來的問題是如何保證資料的一緻性，引入分布式鎖來解決這個問題，主流的分布式存儲系統基本就是 Redis 了。

• 持久化：Redis
• 非持久化：Memcache

消息

分布式消息隊列系統是消除異步帶來的一系列複雜步驟的一大利器，在多線程高并發場景下，我們常常需要謹慎設計業務代碼，來保證多線程并發情況下不出現資源競争導緻的死鎖問題。而消息隊列以一種延遲消費的模式将異步任務都存到隊列，然後再逐個消化。

• Kafka
• RabbitMQ
• RocketMQ
• ActiveMQ

監控

分布式系統從單機到叢集的形态發展，複雜度也大大提高，是以對整個系統的監控也是必不可少。

• Zookeeper

應用

分布式系統的核心子產品就是在應用如何處理業務邏輯，應用直接的調用依賴于特定的協定來通信，有基于 RPC 協定的，也有基于通用的 HTTP 協定。

• HSF
• Dubbo

日志

錯誤對應分布式系統是家常便飯，而且我們設計系統的時候，本身就需要把容錯作為普遍存在的現象來考慮。那麼當出現故障的時候，快速恢複和排查故障就顯得非常重要了。分布式日志采集存儲和檢索則可以給我們提供有力的工具來定位請求鍊路中出現問題的環節。

• 日志采集：flume
• 日志存儲：ElasticSearch/Solr，SLS
• 日志定位：Zipkin

賬本

前文我們提到所謂分布式系統，是迫于單機的性能有限，而堆硬體卻又無法無休止的增加，單機堆硬體最終也會遇到性能增長曲線的瓶頸。于是我們才采用了多台計算機來幹同樣的活，但是這樣的分布式系統始終需要中心化的節點來監控或者排程系統的資源，即使該中心節點也可能是多節點組成。區塊鍊則是真正的區中心化分布式系統，系統裡面隻有 P2P 網絡協定各自通信，沒有真正意義的中心節點，彼此按照區塊鍊節點的算力、權益等機制來協調新區塊的産生。

• 比特币
• 以太坊

設計模式

上節我們列舉了不同場景下不同分布式系統架構扮演的角色和實作的功能，本節我們更進一步歸納分布式系統設計的時候是如何考慮架構設計的、不同設計方案直接的差別和側重點、不同場景需要選擇合作設計模式，來減少試錯的成本，設計分布式系統需要考慮以下的問題。

可用性

可用性是系統運作和工作的時間比例，通常以正常運作時間的百分比來衡量。它可能受系統錯誤、基礎架構問題、惡意攻擊和系統負載的影響。分布式系統通常為使用者提供服務級别協定（SLA），是以應用程式必須設計為最大化可用性。

• 健康檢查：系統實作全鍊路功能檢查，外部工具定期通過公開端點通路系統
• 負載均衡：使用隊列起到削峰作用，作為請求和服務之間的緩沖區，以平滑間歇性的重負載
• 節流：限制應用級别、租戶或整個服務所消耗資源的範圍

資料管理

資料管理是分布式系統的關鍵要素，并影響大多數品質的屬性。由于性能，可擴充性或可用性等原因，資料通常托管在不同位置和多個伺服器上，這可能帶來一系列挑戰。例如，必須維護資料一緻性，并且通常需要跨不同位置同步資料。

• 緩存：根據需要将資料從資料存儲層加載到緩存
• CQRS(Command Query Responsibility Segregation)： 指令查詢職責分離
• 事件溯源：僅使用追加方式記錄域中完整的系列事件
• 索引表：在經常查詢引用的字段上建立索引
• 物化視圖：生成一個或多個資料預填充視圖
• 拆分：将資料拆分為水準的分區或分片

設計與實作

良好的設計包括諸如元件設計和部署的一緻性、簡化管理和開發的可維護性、以及允許元件和子系統用于其他應用程式和其他方案的可重用性等因素。在設計和實施階段做出的決策對分布式系統和服務品質和總體擁有成本産生巨大影響。

• 代理：反向代理
• 擴充卡： 在現代應用程式和遺留系統之間實作擴充卡層
• 前後端分離： 後端服務提供接口供前端應用程式調用
• 計算資源整合：将多個相關任務或操作合并到一個計算單元中
• 配置分離：将配置資訊從應用程式部署包中移出到配置中心
• 網關聚合：使用網關将多個單獨的請求聚合到一個請求中
• 網關解除安裝：将共享或專用服務功能解除安裝到網關代理
• 網關路由：使用單個端點将請求路由到多個服務
• 上司人選舉：通過選擇一個執行個體作為負責管理其他執行個體管理者，協調分布式系統的雲
• 管道和過濾器：将複雜的任務分解為一系列可以重複使用的單獨元件
• 邊車：将應用的監控元件部署到單獨的程序或容器中，以提供隔離和封裝
• 靜态内容托管：将靜态内容部署到 CDN，加速通路效率

分布式系統需要一個連接配接元件和服務的消息傳遞中間件，理想情況是以松散耦合的方式，以便最大限度地提高可伸縮性。異步消息傳遞被廣泛使用，并提供許多好處，但也帶來了諸如消息排序，幂等性等挑戰

• 競争消費者：多線程并發消費
• 優先級隊列： 消息隊列分優先級，優先級高的先被消費

管理與監控

分布式系統在遠端資料中心運作，無法完全控制基礎結構，這使管理和監視比單機部署更困難。應用必須公開運作時資訊，管理者可以使用這些資訊來管理和監視系統，以及支援不斷變化的業務需求和自定義，而無需停止或重新部署應用。

性能與擴充

性能表示系統在給定時間間隔内執行任何操作的響應性，而可伸縮性是系統處理負載增加而不影響性能或容易增加可用資源的能力。分布式系統通常會遇到變化的負載和活動高峰，特别是在多租戶場景中，幾乎是不可能預測的。相反，應用應該能夠在限制範圍内擴充以滿足需求高峰，并在需求減少時進行擴充。可伸縮性不僅涉及計算執行個體，還涉及其他元素，如資料存儲、消息隊列等。

彈性

彈性是指系統能夠優雅地處理故障并從故障中恢複。分布式系統通常是多租戶，使用共享平台服務、競争資源和帶寬，通過 Internet 進行通信，以及在商用硬體上運作，意味着出現瞬态和更永久性故障的可能性增加。為了保持彈性，必須快速有效地檢測故障并進行恢複。

• 隔離：将應用程式的元素隔離到池中，以便在其中一個失敗時，其他元素将繼續運作
• 斷路器：處理連接配接到遠端服務或資源時可能需要不同時間修複的故障
• 補償交易：撤消一系列步驟執行的工作，這些步驟共同定義最終一緻的操作
• 重試：通過透明地重試先前失敗的操作，使應用程式在嘗試連接配接到服務或網絡資源時處理預期的臨時故障

安全

安全性是系統能夠防止在設計使用之外的惡意或意外行為，并防止洩露或丢失資訊。分布式系統在受信任的本地邊界之外的 Internet 上運作，通常向公衆開放，并且可以為不受信任的使用者提供服務。必須以保護應用程式免受惡意攻擊，限制僅允許對已準許使用者的通路，并保護敏感資料。

• 聯合身份：将身份驗證委派給外部身份提供商
• 看門人： 通過使用專用主機執行個體來保護應用程式和服務，該執行個體充當用戶端與應用程式或服務之間的代理，驗證和清理請求，并在它們之間傳遞請求和資料
• 代客鑰匙：使用為用戶端提供對特定資源或服務的受限直接通路的令牌或密鑰

工程應用

前文我們介紹了分布式系統的核心理論，面臨的一些難題和解決問題的折中思路，羅列了現有主流分布式系統的分類，而且歸納了建設分布式系統的一些方法論，那麼接下來我們将從工程角度來介紹真刀真槍搭建分布式系統包含的内容和步驟。

資源排程

巧婦難為無米之炊，我們一切的軟體系統都是建構在硬體伺服器的基礎上。從最開始的實體機直接部署軟體系統，到虛拟機的應用，最後到了資源上雲容器化，硬體資源的使用也開始了集約化的管理。本節對比的是傳統運維角色對應的職責範圍，在 devops 環境下，開發運維一體化，我們要實作的也是資源的靈活高效使用。

[]( https://open.atatech.org/articles/121308#39) 彈性伸縮

過去軟體系統随着使用者量增加需要增加機器資源的話，傳統的方式就是找運維申請機器，然後部署好軟體服務接入叢集，整個過程依賴的是運維人員的人肉經驗，效率低下而且容易出錯。微服務分布式則無需人肉增加實體機器，在容器化技術的支撐下，我們隻需要申請雲資源，然後執行容器腳本即可。

• 應用擴容：使用者激增需要對服務進行擴充，包括自動化擴容，峰值過後的自動縮容
• 機器下線：對于過時應用，進行應用下線，雲平台收回容器宿主資源
• 機器置換：對于故障機器，可供置換容器宿主資源，服務自動啟動，無縫切換

網絡管理

有了計算資源後，另外最重要的就是網絡資源了。在現有的雲化背景下，我們幾乎不會直接接觸到實體的帶寬資源，而是直接由雲平台統一管理帶寬資源。我們需要的是對網絡資源的最大化應用和有效的管理。

• 域名申請：應用申請配套域名資源的申請，多套域名映射規則的規範
• 域名變更：域名變更統一平台管理
• 負載管理：多機應用的通路政策設定
• 安全外聯：基礎通路鑒權，攔截非法請求
• 統一接入：提供統一接入的權限申請平台，提供統一的登入管理

故障快照

在系統故障的時候我們第一要務是系統恢複，同時保留案發現場也是非常重要的，資源排程平台則需要有統一的機制儲存好故障現場。

• 現場保留：記憶體分布，線程數等資源現象的儲存，如 JavaDump 鈎子接入
• 調試接入：采用位元組碼技術無需入侵業務代碼，可以供生産環境現場日志打點調試

流量排程

在我們建設好分布式系統後，最先受到考驗的關口就是網關了，進而我們需要關注系統流量的情況，也就是如何對流量的管理，我們追求的是在系統可容納的流量上限内，把資源留給最優質的流量使用、把非法惡意的流量擋在門外，這樣節省成本的同時確定系統不會被沖擊崩潰。

負載均衡

負載均衡是我們對服務如何消化流量的通用設計，通常分為實體層的底層協定分流的硬負載均衡和軟體層的軟負載。負載均衡解決方案已經是業界成熟的方案，我們通常會針對特定業務在不同環境進行優化，常用有如下的負載均衡解決方案

• 交換機
• F5
• LVS/ALI-LVS
• Nginx/Tengine
• VIPServer/ConfigServer

網關設計

負載均衡首當其沖的就是網關，因為中心化叢集流量最先打到的地方就是網關了，如果網關扛不住壓力的話，那麼整個系統将不可用。

• 高性能：網關設計第一需要考慮的是高性能的流量轉發，網關單節點通常能達到上百萬的并發流量
• 分布式：出于流量壓力分擔和災備考慮，網關設計同樣需要分布式
• 業務篩選：網關同設計簡單的規則，排除掉大部分的惡意流量

流量管理

• 請求校驗：請求鑒權可以把多少非法請求攔截，清洗
• 資料緩存：多數無狀态的請求存在資料熱點，是以采用 CDN 可以把相當大一部分的流量消費掉

流控控制

剩下的真實流量我們采用不同的算法來分流請求。

• 流量配置設定
  • 計數器
  • 隊列
  • 漏鬥
  • 令牌桶
  • 動态流控
• 流量限制在流量激增的時候，通常我們需要有限流措施來防止系統出現雪崩，那麼就需要預估系統的流量上限，然後設定好上限數，但流量增加到一定門檻值後，多出來的流量則不會進入系統，通過犧牲部分流量來保全系統的可用性。
  • 限流政策
  • QPS 粒度
  • 線程數粒度
  • RT 門檻值
  • 限流工具 - Sentinel

服務排程

所謂打鐵還需自身硬，流量做好了排程管理後，剩下的就是服務自身的健壯性了。分布式系統服務出現故障是常有的事情，甚至我們需要把故障本身當做是分布式服務的一部分。

注冊中心

我們網絡管理一節中介紹了網關，網關是流量的集散地，而注冊中心則是服務的根據地。

• 狀态類型：第一好應用服務的狀态，通過注冊中心就可以檢測服務是否可用
• 生命周期：應用服務不同的狀态組成了應用的生命周期

版本管理

• 叢集版本：叢集不用應用有自身對應的版本号，由不同服務組成的叢集也需要定義大的版本号
• 版本復原：在部署異常的時候可以根據大的叢集版本進行復原管理

服務編排

服務編排的定義是：通過消息的互動序列來控制各個部分資源的互動。參與互動的資源都是對等的，沒有集中的控制。微服務環境下服務衆多我們需要有一個總的協調器來協定服務之間的依賴，調用關系，K8s 則是我們的不二選擇。

• K8s
• Spring Cloud
  • ZK+Dubbo

服務控制

前面我們解決了網絡的健壯性和效率問題，這節介紹的是如何使我們的服務更加健壯。

• 發現資源管理那節我們介紹了從雲平台申請了容器宿主資源後，通過自動化腳本就可以啟動應用服務，啟動後服務則需要發現注冊中心，并且把自身的服務資訊注冊到服務網關，即是網關接入。注冊中心則會監控服務的不同狀态，做健康檢查，把不可用的服務歸類标記。
  • 網關接入
  • 健康檢查
• 降級：當使用者激增的時候，我們首先是在流量端做手腳，也就是限流。當我們發現限流後系統響應變慢了，有可能導緻更多的問題時，我們也需要對服務本身做一些操作。服務降級就是把目前不是很核心的功能關閉掉，或者不是很要緊的準确性放寬範圍，事後再做一些人工補救。
  • 降低一緻性限制
  • 關閉非核心服務
  • 簡化功能
• 熔斷：當我們都做了以上的操作後，還是覺得不放心，那麼就需要再進一步操心。熔斷是對過載的一種自身保護，猶如我們開關跳閘一樣。比如當我們服務不斷對資料庫進行查詢的時候，如果業務問題造成查詢問題，這是資料庫本身需要熔斷來保證不會被應用拖垮，并且通路友好的資訊，告訴服務不要再盲目調用了。
  • 閉合狀态
  • 半開狀态
  • 斷開狀态
  • 熔斷工具- Hystrix
• 幂等：我們知道，一個幂等操作的特點是其任意多次執行所産生的影響均與一次執行的影響相同。那麼就需要對單次操作賦予一個全局的 id 來做辨別，這樣多次請求後我們可以判斷來源于同個用戶端，避免出現髒資料。
  • 全局一緻性 ID
  • Snowflake

資料排程

資料存儲最大的挑戰就是資料備援的管理，備援多了效率變低而且占用資源，副本少了起不到災備的作用，我們通常的做法是把有轉态的請求，通過轉态分離，轉化為無狀态請求。

狀态轉移

分離狀态至全局存儲，請求轉換為無狀态流量，比如我們通常會将登陸資訊緩存至全局 redis 中間件，而不需要在多個應用中去備援使用者的登陸資料。

分庫分表

資料橫向擴充。

分片分區

多副本備援。

自動化運維

我們從資源申請管理的時候就介紹到 devops 的趨勢，真正做到開發運維一體化則需要不同的中間件來配合完成。

配置中心

全局配置中心按環境來區分，統一管理，減少了多處配置的混亂局面。

• switch
• diamend

部署政策

微服務分布式部署是家常便飯，如何讓我們的服務更好地支撐業務發展，穩健的部署政策是我們首先需要考慮的，如下的部署政策适合不同業務和不同的階段。

• 停機部署
• 滾動部署
• 藍綠部署
• 灰階部署
• A/B 測試

作業排程

任務排程是系統必不可少的一個環節，傳統的方式是在 Linux 機器上配置 crond 定時任務或者直接在業務代碼裡面完成排程業務，現在則是成熟的中間件來代替。

• SchedulerX
• Spring 定時任務

應用管理

運維工作中很大一部分時間需要對應用進行重新開機，上下線操作，還有日志清理。

• 應用重新開機
• 應用下線
• 日志清理

容錯處理

既然我們知道分布式系統故障是家常便飯，那麼應對故障的方案也是不可或缺的環節。通常我們有主動和被動的方式來處理：

• 主動是在錯誤出現的時候，我們試圖再試試幾次，說不定就成功了，成功的話就可以避免了該次錯誤
• 被動方式是錯誤的事情已經發生了，為了挽回，我們隻是做時候處理，把負面影響降到最小

重試設計

重試設計的關鍵在于設計好重試的時間和次數，如果超過重試次數，或是一段時間，那麼重試就沒有意義了。開源的項目 spring-retry 可以很好地實作我們重試的計劃。

事務補償

事務補償符合我們最終一緻性的理念。補償事務不一定會将系統中的資料傳回到原始操作開始時其所處的狀态。 相反，它補償操作失敗前由已成功完成的步驟所執行的工作。補償事務中步驟的順序不一定與原始操作中步驟的順序完全相反。 例如，一個資料存儲可能比另一個資料存儲對不一緻性更加敏感，因而補償事務中撤銷對此存儲的更改的步驟應該會首先發生。對完成操作所需的每個資源采用短期的基于逾時的鎖并預先擷取這些資源，這樣有助于增加總體活動成功的可能性。 僅在擷取所有資源後才應執行工作。 鎖過期之前必須完成所有操作。

全棧監控

由于分布式系統是由衆多機器共同協作的系統，而且網絡也無法保證完全可用，是以我們需要建設一套對各個環節都能監控的系統，這樣我們才能從底層到業務各個層面進行監控，出現意外的時候可以及時修複故障，避免更多的問題出現。

基礎層

基礎層面是對容器資源的監測，包含各個硬體名額的負載情況

• CPU、IO、記憶體、線程、吞吐

中間件

分布式系統接入了大量的中間件平台，中間件本身的健康情況也需要監控。

應用層

• 性能監控：應用層面的需要對每個應用服務的實時名額（qps，rt），上下遊依賴等進行監控
• 業務監控：除了應用本身的監控程度，業務監控也是保證系統正常的一個環節，通過設計合理的業務規則，對異常的情況做報警設定

監控鍊路

• zipkin/eagleeye
• sls
• goc
• Alimonitor

故障恢複

當故障已經發生後，我們第一個要做的就是馬上消除故障，確定系統服務正常可用，這個時候通常做復原操作。

應用復原

應用復原之前需要儲存好故障現場，以便排查原因。

基線回退

應用服務復原後，代碼基線也需要 revert 到前一版本。

版本復原

整體復原需要服務編排，通過大版本号對叢集進行復原。

性能調優

性能優化是分布式系統的大專題，涉及的面非常廣，這塊簡直可以單獨拿出來做一個系列來講，本節就先不展開。本身我們做服務治理的過程也是在性能的優化過程。

《高并發程式設計知識體系》

分布式鎖

緩存是解決性能問題的一大利器，理想情況下，每個請求不需要額外計算就立刻能擷取到結果時最快。小到 CPU 的三級緩存，大到分布式緩存，緩存無處不在，分布式緩存需要解決的就是資料的一緻性，這個時候我們引入了分布式鎖的概念，如何處理分布式鎖的問題将決定我們擷取緩存資料的效率。

高并發

多線程程式設計模式提升了系統的吞吐量，但也同時帶來了業務的複雜度。

異步

事件驅動的異步程式設計是一種新的程式設計模式，摒棄了多線程的複雜業務處理問題，同時能夠提升系統的響應效率。

總結

最後總結一下，如果有可能的話，請嘗試使用單節點方式而不是分布式系統。分布式系統伴随着一些失敗的操作，為了處理災難性故障，我們使用備份；為了提高可靠性，我們引入了備援。

分布式系統本質就是一堆機器的協同，而我們要做的就是搞出各種手段來然機器的運作達到預期。這麼複雜的系統，需要了解各個環節、各個中間件的接入，是一個非常大的工程。慶幸的是，在微服務背景下，多數基礎性的工作已經有人幫我們實作了。前文所描述的分布式架構，在工程實作了是需要用到分布式三件套 (Docker+K8S+Srping Cloud) 基本就可以建構出來了。

分布式架構核心技術分布圖如下：

原圖來源：

https://dzone.com/articles/deploying-microservices-spring-cloud-vs-kubernetes

分布式技術棧使用中間件：

“ 阿裡巴巴雲原生微信公衆号（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”