作者 | 曉土??阿里巴巴高級(jí)工程師

創(chuàng)新互聯(lián)公司主要從事做網(wǎng)站、成都網(wǎng)站制作、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)黃陂,10年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專(zhuān)業(yè),歡迎來(lái)電咨詢建站服務(wù):18982081108

姊妹篇閱讀推薦：《[云原生時(shí)代，分布式系統(tǒng)設(shè)計(jì)必備知識(shí)圖譜（內(nèi)含22個(gè)知識(shí)點(diǎn)）](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247486600&idx=1&sn=0ad92a1fe535f141fe2e8c87ffbd1229&chksm=fae50747cd928e51c05c41d2cc206069babbe9dfdba5957c52ac6e77cb754192169bb6b3e898&scene=21#wechat_redirect)》

導(dǎo)讀：本文力求從分布式基礎(chǔ)理論、架構(gòu)設(shè)計(jì)模式、工程應(yīng)用、部署運(yùn)維、業(yè)界方案這幾大方面，介紹基于 MSA（微服務(wù)架構(gòu)）的分布式知識(shí)體系大綱，從而對(duì) SOA 到 MSA 進(jìn)化有著立體的認(rèn)識(shí)；從概念上和工具應(yīng)用上更近一步了解微服務(wù)分布式的本質(zhì)，身臨其境的感受如何搭建全套微服務(wù)架構(gòu)的過(guò)程。

關(guān)注“阿里巴巴云原生”公眾號(hào)，回復(fù)“分布”，即可下載分布式系統(tǒng)及其知識(shí)體系清晰大圖！

隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展和智能終端的普及，計(jì)算機(jī)系統(tǒng)早就從單機(jī)獨(dú)立工作過(guò)渡到多機(jī)器協(xié)作，集群按照分布式理論構(gòu)建出龐大復(fù)雜的應(yīng)用服務(wù)，在分布式的基礎(chǔ)上正進(jìn)行一場(chǎng)云原生的技術(shù)革命，徹底打破傳統(tǒng)的開(kāi)發(fā)方式，解放了新一代的生產(chǎn)力。

分布式系統(tǒng)知識(shí)體系大圖

cdn.com/d16a1bbbb104cad78fe989c3f11828614c75e946.png">

關(guān)注“阿里巴巴云原生”公眾號(hào)，回復(fù)“**分布**”，即可下載分布式系統(tǒng)及其知識(shí)體系清晰大圖！

基礎(chǔ)理論

SOA 到 MSA 的進(jìn)化

SOA 面向服務(wù)架構(gòu)

由于業(yè)務(wù)發(fā)展到一定程度后，需要對(duì)服務(wù)進(jìn)行解耦，進(jìn)而把一個(gè)單一的大系統(tǒng)按邏輯拆分成不同的子系統(tǒng)，通過(guò)服務(wù)接口來(lái)通訊。面向服務(wù)的設(shè)計(jì)模式，最終需要總線集成服務(wù)，而且大部分時(shí)候還共享數(shù)據(jù)庫(kù)，出現(xiàn)單點(diǎn)故障時(shí)會(huì)導(dǎo)致總線層面的故障，更進(jìn)一步可能會(huì)把數(shù)據(jù)庫(kù)拖垮，所以才有了更加獨(dú)立的設(shè)計(jì)方案的出現(xiàn)。

MSA 微服務(wù)架構(gòu)

微服務(wù)是真正意義上的獨(dú)立服務(wù)，從服務(wù)入口到數(shù)據(jù)持久層，邏輯上都是獨(dú)立隔離的，無(wú)需服務(wù)總線來(lái)接入，但同時(shí)也增加了整個(gè)分布式系統(tǒng)的搭建和管理難度，需要對(duì)服務(wù)進(jìn)行編排和管理，所以伴隨著微服務(wù)的興起，微服務(wù)生態(tài)的整套技術(shù)棧也需要無(wú)縫接入，才能支撐起微服務(wù)的治理理念。

節(jié)點(diǎn)與網(wǎng)絡(luò)

節(jié)點(diǎn)

傳統(tǒng)的節(jié)點(diǎn)也就是一臺(tái)單體的物理機(jī)，所有的服務(wù)都揉進(jìn)去包括服務(wù)和數(shù)據(jù)庫(kù)；隨著虛擬化的發(fā)展，單臺(tái)物理機(jī)往往可以分成多臺(tái)虛擬機(jī)，實(shí)現(xiàn)資源利用的最大化，節(jié)點(diǎn)的概念也變成單臺(tái)虛擬機(jī)上面服務(wù)；近幾年容器技術(shù)逐漸成熟后，服務(wù)已經(jīng)徹底容器化，也就是節(jié)點(diǎn)只是輕量級(jí)的容器服務(wù)。總體來(lái)說(shuō)，節(jié)點(diǎn)就是能提供單位服務(wù)的邏輯計(jì)算資源的集合。

網(wǎng)絡(luò)

分布式架構(gòu)的根基就是網(wǎng)絡(luò)，不管是局域網(wǎng)還是公網(wǎng)，沒(méi)有網(wǎng)絡(luò)就無(wú)法把計(jì)算機(jī)聯(lián)合在一起工作，但是網(wǎng)絡(luò)也帶來(lái)了一系列的問(wèn)題。網(wǎng)絡(luò)消息的傳播有先后，消息丟失和延遲是經(jīng)常發(fā)生的事情，我們定義了三種網(wǎng)絡(luò)工作模式：

• 同步網(wǎng)絡(luò)
  • 節(jié)點(diǎn)同步執(zhí)行
  • 消息延遲有限
  • 高效全局鎖
• 半同步網(wǎng)絡(luò)
  • 鎖范圍放寬
• 異步網(wǎng)絡(luò)
  • 節(jié)點(diǎn)獨(dú)立執(zhí)行
  • 消息延遲無(wú)上限
  • 無(wú)全局鎖
  • 部分算法不可行

常用網(wǎng)絡(luò)傳輸層有兩大協(xié)議的特點(diǎn)簡(jiǎn)介：

• TCP 協(xié)議
  • 首先 tcp 協(xié)議傳輸可靠，盡管其他的協(xié)議可以更快傳輸
  • tcp 解決重復(fù)和亂序問(wèn)題
• UDP 協(xié)議
  • 常量數(shù)據(jù)流
  • 丟包不致命

時(shí)間與順序

時(shí)間

慢速物理時(shí)空中，時(shí)間獨(dú)自在流淌著，對(duì)于串行的事務(wù)來(lái)說(shuō)，很簡(jiǎn)單的就是跟著時(shí)間的腳步走就可以，先來(lái)后到的發(fā)生。而后我們發(fā)明了時(shí)鐘來(lái)刻畫(huà)以往發(fā)生的時(shí)間點(diǎn)，時(shí)鐘讓這個(gè)世界井然有序。但是對(duì)于分布式世界來(lái)說(shuō)，跟時(shí)間打交道著實(shí)是一件痛苦的事情。

分布式世界里面，我們要協(xié)調(diào)不同節(jié)點(diǎn)之間的先來(lái)后到關(guān)系，不同節(jié)點(diǎn)本身承認(rèn)的時(shí)間又各執(zhí)己見(jiàn)，于是我們創(chuàng)造了網(wǎng)絡(luò)時(shí)間協(xié)議（NTP）試圖來(lái)解決不同節(jié)點(diǎn)之間的標(biāo)準(zhǔn)時(shí)間，但是 NTP 本身表現(xiàn)并不盡如人意，所以我們又構(gòu)造出了邏輯時(shí)鐘，最后改進(jìn)為向量時(shí)鐘：

• NTP 的一些缺點(diǎn)，無(wú)法完全滿足分布式下并發(fā)任務(wù)的協(xié)調(diào)問(wèn)題
  • 節(jié)點(diǎn)間時(shí)間不同步
  • 硬件時(shí)鐘漂移
  • 線程可能休眠
  • 操作系統(tǒng)休眠
  • 硬件休眠

• 邏輯時(shí)鐘
  • 定義事件先來(lái)后到
  • t' = max(t, t_msg + 1)

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

順序

有了衡量時(shí)間的工具，解決順序問(wèn)題自然就是水到渠成了。因?yàn)檎麄€(gè)分布式的理論基礎(chǔ)就是如何協(xié)商不同節(jié)點(diǎn)的一致性問(wèn)題，而順序則是一致性理論的基本概念，所以前文我們才需要花時(shí)間介紹衡量時(shí)間的刻度和工具。

一致性理論

說(shuō)到一致性理論，我們必須看一張關(guān)于一致性強(qiáng)弱對(duì)系統(tǒng)建設(shè)影響的對(duì)比圖：

該圖對(duì)比了不同一致性算法下的事務(wù)、性能、錯(cuò)誤、延遲的平衡。

強(qiáng)一致性 ACID

單機(jī)環(huán)境下我們對(duì)傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)有苛刻的要求，由于存在網(wǎng)絡(luò)的延遲和消息丟失，ACID 便是保證事務(wù)的原則，這四大原則甚至我們都不需要解釋出來(lái)就耳熟能詳了：

• Atomicity：原子性，一個(gè)事務(wù)中的所有操作，要么全部完成，要么全部不完成，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)；
• Consistency：一致性，在事務(wù)開(kāi)始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫(kù)的完整性沒(méi)有被破壞；
• Isolation：隔離性，數(shù)據(jù)庫(kù)允許多個(gè)并發(fā)事務(wù)同時(shí)對(duì)其數(shù)據(jù)進(jìn)行讀寫(xiě)和修改的能力，隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)，由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致；
• Durabilit：事務(wù)處理結(jié)束后，對(duì)數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會(huì)丟失。

分布式一致性 CAP

分布式環(huán)境下，我們無(wú)法保證網(wǎng)絡(luò)的正常連接和信息的傳送，于是發(fā)展出了 CAP/FLP/DLS 這三個(gè)重要的理論：

• CAP：分布式計(jì)算系統(tǒng)不可能同時(shí)確保一致性（Consistency）、可用性（Availablity）和分區(qū)容忍性（Partition）；<br />
• FLP：在異步環(huán)境中，如果節(jié)點(diǎn)間的網(wǎng)絡(luò)延遲沒(méi)有上限，只要有一個(gè)惡意的節(jié)點(diǎn)存在，就沒(méi)有算法能在有限的時(shí)間內(nèi)達(dá)成共識(shí)；<br />
• DLS：
  • 在一個(gè)部分同步網(wǎng)絡(luò)的模型（也就是說(shuō)：網(wǎng)絡(luò)延時(shí)有界限但是我們并不知道在哪里）下運(yùn)行的協(xié)議可以容忍 1/3 任意（換句話說(shuō)，拜占庭）錯(cuò)誤；
  • 在一個(gè)異步模型中的確定性的協(xié)議（沒(méi)有網(wǎng)絡(luò)延時(shí)上限）不能容錯(cuò)（不過(guò)這個(gè)論文沒(méi)有提起隨機(jī)化算法可以容忍 1/3 的錯(cuò)誤）；
  • 同步模型中的協(xié)議（網(wǎng)絡(luò)延時(shí)可以保證小于已知 d 時(shí)間），可以令人吃驚的達(dá)到 100% 容錯(cuò)，雖然對(duì) 1/2 的節(jié)點(diǎn)出錯(cuò)可以發(fā)生的情況有所限制。

弱一致性 BASE

多數(shù)情況下，其實(shí)我們也并非一定要求強(qiáng)一致性，部分業(yè)務(wù)可以容忍一定程度的延遲一致，所以為了兼顧效率，發(fā)展出來(lái)了最終一致性理論 BASE。BASE 是指基本可用（Basically Available）、軟狀態(tài)（ Soft State）、最終一致性（ Eventual Consistency）：

• 基本可用（Basically Available）：基本可用是指分布式系統(tǒng)在出現(xiàn)故障的時(shí)候，允許損失部分可用性，即保證核心可用；
• 軟狀態(tài)（Soft State）：軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會(huì)影響系統(tǒng)整體可用性。分布式存儲(chǔ)中一般一份數(shù)據(jù)至少會(huì)有三個(gè)副本，允許不同節(jié)點(diǎn)間副本同步的延時(shí)就是軟狀態(tài)的體現(xiàn)；
• 最終一致性（Eventual Consistency）：最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過(guò)一定時(shí)間后，最終能夠達(dá)到一致的狀態(tài)。弱一致性和強(qiáng)一致性相反，最終一致性是弱一致性的一種特殊情況。

一致性算法

分布式架構(gòu)的核心就在于一致性的實(shí)現(xiàn)和妥協(xié)，那么如何設(shè)計(jì)一套算法來(lái)保證不同節(jié)點(diǎn)之間的通信和數(shù)據(jù)達(dá)到無(wú)限趨向一致性，就非常重要了。保證不同節(jié)點(diǎn)在充滿不確定性網(wǎng)絡(luò)環(huán)境下能達(dá)成相同副本的一致性是非常困難的，業(yè)界對(duì)該課題也做了大量的研究。

首先我們要了解一致性的大前提原則?(CALM):
CALM 原則的全稱(chēng)是 Consistency and Logical Monotonicity ，主要描述的是分布式系統(tǒng)中單調(diào)邏輯與一致性的關(guān)系，它的內(nèi)容如下，參考?consistency as logical monotonicity。

• 在分布式系統(tǒng)中，單調(diào)的邏輯都能保證 “最終一致性”，這個(gè)過(guò)程中不需要依賴(lài)中心節(jié)點(diǎn)的調(diào)度；
• 任意分布式系統(tǒng)，如果所有的非單調(diào)邏輯都有中心節(jié)點(diǎn)調(diào)度，那么這個(gè)分布式系統(tǒng)就可以實(shí)現(xiàn)最終“一致性”。

然后再關(guān)注分布式系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)?CRDT(Conflict-Free Replicated Data Types)：
我們了解到分布式一些規(guī)律原則之后，就要著手考慮如何來(lái)實(shí)現(xiàn)解決方案，一致性算法的前提是數(shù)據(jù)結(jié)構(gòu)，或者說(shuō)一切算法的根基都是數(shù)據(jù)結(jié)構(gòu)，設(shè)計(jì)良好的數(shù)據(jù)結(jié)構(gòu)加上精妙的算法可以高效的解決現(xiàn)實(shí)的問(wèn)題。經(jīng)過(guò)前人不斷的探索，我們得知分布式系統(tǒng)被廣泛采用的數(shù)據(jù)結(jié)構(gòu) CRDT。
參考《談?wù)?CRDT》,A comprehensive study of Convergent and Commutative Replicated Data Types

• 基于狀態(tài)（state-based）：即將各個(gè)節(jié)點(diǎn)之間的 CRDT 數(shù)據(jù)直接進(jìn)行合并，所有節(jié)點(diǎn)都能最終合并到同一個(gè)狀態(tài)，數(shù)據(jù)合并的順序不會(huì)影響到最終的結(jié)果；
• 基于操作（operation-based）：將每一次對(duì)數(shù)據(jù)的操作通知給其他節(jié)點(diǎn)。只要節(jié)點(diǎn)知道了對(duì)數(shù)據(jù)的所有操作（收到操作的順序可以是任意的），就能合并到同一個(gè)狀態(tài)。

了解數(shù)據(jù)結(jié)構(gòu)后，我們需要來(lái)關(guān)注一下分布式系統(tǒng)的一些重要的協(xié)議HATs(Highly Available Transactions)，ZAB(Zookeeper Atomic Broadcast)：
參考《高可用事務(wù)》，《ZAB 協(xié)議分析》

最后要學(xué)習(xí)的是業(yè)界主流的一致性算法?：
說(shuō)實(shí)話具體的算法我也還沒(méi)完全搞懂，一致性算法是分布式系統(tǒng)最核心本質(zhì)的內(nèi)容，這部分的發(fā)展也會(huì)影響架構(gòu)的革新，不同場(chǎng)景的應(yīng)用也催生不同的算法。

• Paxos：《優(yōu)雅的Paxos算法》
• Raft ：《Raft 一致性算法》
• Gossip：《Gossip Visualization》

這一節(jié)我們說(shuō)完分布式系統(tǒng)里面核心理論基礎(chǔ)，如何達(dá)成不同節(jié)點(diǎn)之間的數(shù)據(jù)一致性，下面我們將會(huì)講到目前都有哪些主流的分布式系統(tǒng)。

場(chǎng)景分類(lèi)

文件系統(tǒng)

單臺(tái)計(jì)算機(jī)的存儲(chǔ)始終有上限，隨著網(wǎng)絡(luò)的出現(xiàn)，多臺(tái)計(jì)算機(jī)協(xié)作存儲(chǔ)文件的方案也相繼被提出來(lái)。最早的分布式文件系統(tǒng)其實(shí)也稱(chēng)為網(wǎng)絡(luò)文件系統(tǒng)，第一個(gè)文件服務(wù)器在 1970 年代被發(fā)展出來(lái)。在 1976 年迪吉多公司設(shè)計(jì)出 File Access Listener（FAL），而現(xiàn)代分布式文件系統(tǒng)則出自赫赫有名的 Google 的論文，《The Google File System》奠定了分布式文件系統(tǒng)的基礎(chǔ)。現(xiàn)代主流分布式文件系統(tǒng)參考《分布式文件系統(tǒng)對(duì)比》,下面列舉幾個(gè)常用的文件系統(tǒng)：

• HDFS
• FastDFS
• Ceph
• mooseFS

數(shù)據(jù)庫(kù)

數(shù)據(jù)庫(kù)當(dāng)然也屬于文件系統(tǒng)，主數(shù)據(jù)增加了事務(wù)、檢索、擦除等高級(jí)特性，所以復(fù)雜度又增加了，既要考慮數(shù)據(jù)一致性也得保證足夠的性能。傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)為了兼顧事務(wù)和性能的特性，在分布式方面的發(fā)展有限，非關(guān)系型數(shù)據(jù)庫(kù)擺脫了事務(wù)的強(qiáng)一致性束縛，達(dá)到了最終一致性的效果，從而有了飛躍的發(fā)展，NOSQL(Not Only Sql) 也產(chǎn)生了多個(gè)架構(gòu)的數(shù)據(jù)庫(kù)類(lèi)型，包括 KV、列式存儲(chǔ)、文檔類(lèi)型等。

• 列式存儲(chǔ)：Hbase
• 文檔存儲(chǔ)：Elasticsearch，MongoDB
• KV 類(lèi)型：redis
• 關(guān)系型：Spanner

計(jì)算

分布式計(jì)算系統(tǒng)構(gòu)建在分布式存儲(chǔ)的基礎(chǔ)上，充分發(fā)揮分布式系統(tǒng)的數(shù)據(jù)冗余災(zāi)備，多副本高效獲取數(shù)據(jù)的特性，進(jìn)而并行計(jì)算，把原本需要長(zhǎng)時(shí)間計(jì)算的任務(wù)拆分成多個(gè)任務(wù)并行處理，從而提高了計(jì)算效率。分布式計(jì)算系統(tǒng)在場(chǎng)景上分為離線計(jì)算、實(shí)時(shí)計(jì)算和流式計(jì)算。

• 離線：Hadoop
• 實(shí)時(shí)：Spark
• 流式：Storm，F(xiàn)link/Blink

緩存

緩存作為提升性能的利器無(wú)處不在，小到 CPU 緩存架構(gòu)，大到分布式應(yīng)用存儲(chǔ)。分布式緩存系統(tǒng)提供了熱點(diǎn)數(shù)據(jù)的隨機(jī)訪問(wèn)機(jī)制，大大了提升了訪問(wèn)時(shí)間，但是帶來(lái)的問(wèn)題是如何保證數(shù)據(jù)的一致性，引入分布式鎖來(lái)解決這個(gè)問(wèn)題，主流的分布式存儲(chǔ)系統(tǒng)基本就是 Redis 了。

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

消息

分布式消息隊(duì)列系統(tǒng)是消除異步帶來(lái)的一系列復(fù)雜步驟的一大利器，在多線程高并發(fā)場(chǎng)景下，我們常常需要謹(jǐn)慎設(shè)計(jì)業(yè)務(wù)代碼，來(lái)保證多線程并發(fā)情況下不出現(xiàn)資源競(jìng)爭(zhēng)導(dǎo)致的死鎖問(wèn)題。而消息隊(duì)列以一種延遲消費(fèi)的模式將異步任務(wù)都存到隊(duì)列，然后再逐個(gè)消化。

• Kafka
• RabbitMQ
• RocketMQ
• ActiveMQ

監(jiān)控

分布式系統(tǒng)從單機(jī)到集群的形態(tài)發(fā)展，復(fù)雜度也大大提高，所以對(duì)整個(gè)系統(tǒng)的監(jiān)控也是必不可少。

• Zookeeper

應(yīng)用

分布式系統(tǒng)的核心模塊就是在應(yīng)用如何處理業(yè)務(wù)邏輯，應(yīng)用直接的調(diào)用依賴(lài)于特定的協(xié)議來(lái)通信，有基于 RPC 協(xié)議的，也有基于通用的 HTTP 協(xié)議。

• HSF
• Dubbo

日志

錯(cuò)誤對(duì)應(yīng)分布式系統(tǒng)是家常便飯，而且我們?cè)O(shè)計(jì)系統(tǒng)的時(shí)候，本身就需要把容錯(cuò)作為普遍存在的現(xiàn)象來(lái)考慮。那么當(dāng)出現(xiàn)故障的時(shí)候，快速恢復(fù)和排查故障就顯得非常重要了。分布式日志采集存儲(chǔ)和檢索則可以給我們提供有力的工具來(lái)定位請(qǐng)求鏈路中出現(xiàn)問(wèn)題的環(huán)節(jié)。

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

賬本

前文我們提到所謂分布式系統(tǒng)，是迫于單機(jī)的性能有限，而堆硬件卻又無(wú)法無(wú)休止的增加，單機(jī)堆硬件最終也會(huì)遇到性能增長(zhǎng)曲線的瓶頸。于是我們才采用了多臺(tái)計(jì)算機(jī)來(lái)干同樣的活，但是這樣的分布式系統(tǒng)始終需要中心化的節(jié)點(diǎn)來(lái)監(jiān)控或者調(diào)度系統(tǒng)的資源，即使該中心節(jié)點(diǎn)也可能是多節(jié)點(diǎn)組成。區(qū)塊鏈則是真正的區(qū)中心化分布式系統(tǒng)，系統(tǒng)里面只有 P2P 網(wǎng)絡(luò)協(xié)議各自通信，沒(méi)有真正意義的中心節(jié)點(diǎn)，彼此按照區(qū)塊鏈節(jié)點(diǎn)的算力、權(quán)益等機(jī)制來(lái)協(xié)調(diào)新區(qū)塊的產(chǎn)生。

• 比特幣
• 以太坊

設(shè)計(jì)模式

上節(jié)我們列舉了不同場(chǎng)景下不同分布式系統(tǒng)架構(gòu)扮演的角色和實(shí)現(xiàn)的功能，本節(jié)我們更進(jìn)一步歸納分布式系統(tǒng)設(shè)計(jì)的時(shí)候是如何考慮架構(gòu)設(shè)計(jì)的、不同設(shè)計(jì)方案直接的區(qū)別和側(cè)重點(diǎn)、不同場(chǎng)景需要選擇合作設(shè)計(jì)模式，來(lái)減少試錯(cuò)的成本，設(shè)計(jì)分布式系統(tǒng)需要考慮以下的問(wèn)題。

可用性

可用性是系統(tǒng)運(yùn)行和工作的時(shí)間比例，通常以正常運(yùn)行時(shí)間的百分比來(lái)衡量。它可能受系統(tǒng)錯(cuò)誤、基礎(chǔ)架構(gòu)問(wèn)題、惡意attack和系統(tǒng)負(fù)載的影響。分布式系統(tǒng)通常為用戶提供服務(wù)級(jí)別協(xié)議（SLA），因此應(yīng)用程序必須設(shè)計(jì)為最大化可用性。

• 健康檢查：系統(tǒng)實(shí)現(xiàn)全鏈路功能檢查，外部工具定期通過(guò)公開(kāi)端點(diǎn)訪問(wèn)系統(tǒng)
• 負(fù)載均衡：使用隊(duì)列起到削峰作用，作為請(qǐng)求和服務(wù)之間的緩沖區(qū)，以平滑間歇性的重負(fù)載
• 節(jié)流：限制應(yīng)用級(jí)別、租戶或整個(gè)服務(wù)所消耗資源的范圍

數(shù)據(jù)管理

數(shù)據(jù)管理是分布式系統(tǒng)的關(guān)鍵要素，并影響大多數(shù)質(zhì)量的屬性。由于性能，可擴(kuò)展性或可用性等原因，數(shù)據(jù)通常托管在不同位置和多個(gè)服務(wù)器上，這可能帶來(lái)一系列挑戰(zhàn)。例如，必須維護(hù)數(shù)據(jù)一致性，并且通常需要跨不同位置同步數(shù)據(jù)。

• 緩存：根據(jù)需要將數(shù)據(jù)從數(shù)據(jù)存儲(chǔ)層加載到緩存
• CQRS(Command Query Responsibility Segregation)： 命令查詢職責(zé)分離
• 事件溯源：僅使用追加方式記錄域中完整的系列事件
• 索引表：在經(jīng)常查詢引用的字段上創(chuàng)建索引
• 物化視圖：生成一個(gè)或多個(gè)數(shù)據(jù)預(yù)填充視圖
• 拆分：將數(shù)據(jù)拆分為水平的分區(qū)或分片

設(shè)計(jì)與實(shí)現(xiàn)

良好的設(shè)計(jì)包括諸如組件設(shè)計(jì)和部署的一致性、簡(jiǎn)化管理和開(kāi)發(fā)的可維護(hù)性、以及允許組件和子系統(tǒng)用于其他應(yīng)用程序和其他方案的可重用性等因素。在設(shè)計(jì)和實(shí)施階段做出的決策對(duì)分布式系統(tǒng)和服務(wù)質(zhì)量和總體擁有成本產(chǎn)生巨大影響。

• 代理：反向代理
• 適配器： 在現(xiàn)代應(yīng)用程序和遺留系統(tǒng)之間實(shí)現(xiàn)適配器層
• 前后端分離： 后端服務(wù)提供接口供前端應(yīng)用程序調(diào)用
• 計(jì)算資源整合：將多個(gè)相關(guān)任務(wù)或操作合并到一個(gè)計(jì)算單元中
• 配置分離：將配置信息從應(yīng)用程序部署包中移出到配置中心
• 網(wǎng)關(guān)聚合：使用網(wǎng)關(guān)將多個(gè)單獨(dú)的請(qǐng)求聚合到一個(gè)請(qǐng)求中
• 網(wǎng)關(guān)卸載：將共享或?qū)Ｓ梅?wù)功能卸載到網(wǎng)關(guān)代理
• 網(wǎng)關(guān)路由：使用單個(gè)端點(diǎn)將請(qǐng)求路由到多個(gè)服務(wù)
• 領(lǐng)導(dǎo)人選舉：通過(guò)選擇一個(gè)實(shí)例作為負(fù)責(zé)管理其他實(shí)例管理員，協(xié)調(diào)分布式系統(tǒng)的云
• 管道和過(guò)濾器：將復(fù)雜的任務(wù)分解為一系列可以重復(fù)使用的單獨(dú)組件
• 邊車(chē)：將應(yīng)用的監(jiān)控組件部署到單獨(dú)的進(jìn)程或容器中，以提供隔離和封裝
• 靜態(tài)內(nèi)容托管：將靜態(tài)內(nèi)容部署到 CDN，加速訪問(wèn)效率

消息

分布式系統(tǒng)需要一個(gè)連接組件和服務(wù)的消息傳遞中間件，理想情況是以松散耦合的方式，以便最大限度地提高可伸縮性。異步消息傳遞被廣泛使用，并提供許多好處，但也帶來(lái)了諸如消息排序，冪等性等挑戰(zhàn)

• 競(jìng)爭(zhēng)消費(fèi)者：多線程并發(fā)消費(fèi)
• 優(yōu)先級(jí)隊(duì)列： 消息隊(duì)列分優(yōu)先級(jí)，優(yōu)先級(jí)高的先被消費(fèi)

管理與監(jiān)控

分布式系統(tǒng)在遠(yuǎn)程數(shù)據(jù)中心運(yùn)行，無(wú)法完全控制基礎(chǔ)結(jié)構(gòu)，這使管理和監(jiān)視比單機(jī)部署更困難。應(yīng)用必須公開(kāi)運(yùn)行時(shí)信息，管理員可以使用這些信息來(lái)管理和監(jiān)視系統(tǒng)，以及支持不斷變化的業(yè)務(wù)需求和自定義，而無(wú)需停止或重新部署應(yīng)用。

性能與擴(kuò)展

性能表示系統(tǒng)在給定時(shí)間間隔內(nèi)執(zhí)行任何操作的響應(yīng)性，而可伸縮性是系統(tǒng)處理負(fù)載增加而不影響性能或容易增加可用資源的能力。分布式系統(tǒng)通常會(huì)遇到變化的負(fù)載和活動(dòng)高峰，特別是在多租戶場(chǎng)景中，幾乎是不可能預(yù)測(cè)的。相反，應(yīng)用應(yīng)該能夠在限制范圍內(nèi)擴(kuò)展以滿足需求高峰，并在需求減少時(shí)進(jìn)行擴(kuò)展。可伸縮性不僅涉及計(jì)算實(shí)例，還涉及其他元素，如數(shù)據(jù)存儲(chǔ)、消息隊(duì)列等。

彈性

彈性是指系統(tǒng)能夠優(yōu)雅地處理故障并從故障中恢復(fù)。分布式系統(tǒng)通常是多租戶，使用共享平臺(tái)服務(wù)、競(jìng)爭(zhēng)資源和帶寬，通過(guò) Internet 進(jìn)行通信，以及在商用硬件上運(yùn)行，意味著出現(xiàn)瞬態(tài)和更永久性故障的可能性增加。為了保持彈性，必須快速有效地檢測(cè)故障并進(jìn)行恢復(fù)。

• 隔離：將應(yīng)用程序的元素隔離到池中，以便在其中一個(gè)失敗時(shí)，其他元素將繼續(xù)運(yùn)行
• 斷路器：處理連接到遠(yuǎn)程服務(wù)或資源時(shí)可能需要不同時(shí)間修復(fù)的故障
• 補(bǔ)償交易：撤消一系列步驟執(zhí)行的工作，這些步驟共同定義最終一致的操作
• 健康檢查：系統(tǒng)實(shí)現(xiàn)全鏈路功能檢查，外部工具定期通過(guò)公開(kāi)端點(diǎn)訪問(wèn)系統(tǒng)
• 重試：通過(guò)透明地重試先前失敗的操作，使應(yīng)用程序在嘗試連接到服務(wù)或網(wǎng)絡(luò)資源時(shí)處理預(yù)期的臨時(shí)故障

安全

安全性是系統(tǒng)能夠防止在設(shè)計(jì)使用之外的惡意或意外行為，并防止泄露或丟失信息。分布式系統(tǒng)在受信任的本地邊界之外的 Internet 上運(yùn)行，通常向公眾開(kāi)放，并且可以為不受信任的用戶提供服務(wù)。必須以保護(hù)應(yīng)用程序免受惡意attack，限制僅允許對(duì)已批準(zhǔn)用戶的訪問(wèn)，并保護(hù)敏感數(shù)據(jù)。

• 聯(lián)合身份：將身份驗(yàn)證委派給外部身份提供商
• 看門(mén)人： 通過(guò)使用專(zhuān)用主機(jī)實(shí)例來(lái)保護(hù)應(yīng)用程序和服務(wù)，該實(shí)例充當(dāng)客戶端與應(yīng)用程序或服務(wù)之間的代理，驗(yàn)證和清理請(qǐng)求，并在它們之間傳遞請(qǐng)求和數(shù)據(jù)
• 代客鑰匙：使用為客戶端提供對(duì)特定資源或服務(wù)的受限直接訪問(wèn)的令牌或密鑰

工程應(yīng)用

前文我們介紹了分布式系統(tǒng)的核心理論，面臨的一些難題和解決問(wèn)題的折中思路，羅列了現(xiàn)有主流分布式系統(tǒng)的分類(lèi)，而且歸納了建設(shè)分布式系統(tǒng)的一些方法論，那么接下來(lái)我們將從工程角度來(lái)介紹搭建分布式系統(tǒng)包含的內(nèi)容和步驟。

資源調(diào)度

巧婦難為無(wú)米之炊，我們一切的軟件系統(tǒng)都是構(gòu)建在硬件服務(wù)器的基礎(chǔ)上。從最開(kāi)始的物理機(jī)直接部署軟件系統(tǒng)，到虛擬機(jī)的應(yīng)用，最后到了資源上云容器化，硬件資源的使用也開(kāi)始了集約化的管理。本節(jié)對(duì)比的是傳統(tǒng)運(yùn)維角色對(duì)應(yīng)的職責(zé)范圍，在 devops 環(huán)境下，開(kāi)發(fā)運(yùn)維一體化，我們要實(shí)現(xiàn)的也是資源的靈活高效使用。

彈性伸縮

過(guò)去軟件系統(tǒng)隨著用戶量增加需要增加機(jī)器資源的話，傳統(tǒng)的方式就是找運(yùn)維申請(qǐng)機(jī)器，然后部署好軟件服務(wù)接入集群，整個(gè)過(guò)程依賴(lài)的是運(yùn)維人員的人肉經(jīng)驗(yàn)，效率低下而且容易出錯(cuò)。微服務(wù)分布式則無(wú)需人肉增加物理機(jī)器，在容器化技術(shù)的支撐下，我們只需要申請(qǐng)?jiān)瀑Y源，然后執(zhí)行容器腳本即可。

• 應(yīng)用擴(kuò)容：用戶激增需要對(duì)服務(wù)進(jìn)行擴(kuò)展，包括自動(dòng)化擴(kuò)容，峰值過(guò)后的自動(dòng)縮容<br />
• 機(jī)器下線：對(duì)于過(guò)時(shí)應(yīng)用，進(jìn)行應(yīng)用下線，云平臺(tái)收回容器宿主資源<br />
• 機(jī)器置換：對(duì)于故障機(jī)器，可供置換容器宿主資源，服務(wù)自動(dòng)啟動(dòng)，無(wú)縫切換

網(wǎng)絡(luò)管理

有了計(jì)算資源后，另外最重要的就是網(wǎng)絡(luò)資源了。在現(xiàn)有的云化背景下，我們幾乎不會(huì)直接接觸到物理的帶寬資源，而是直接由云平臺(tái)統(tǒng)一管理帶寬資源。我們需要的是對(duì)網(wǎng)絡(luò)資源的最大化應(yīng)用和有效的管理。

• 域名申請(qǐng)：應(yīng)用申請(qǐng)配套域名資源的申請(qǐng)，多套域名映射規(guī)則的規(guī)范
• 域名變更：域名變更統(tǒng)一平臺(tái)管理
• 負(fù)載管理：多機(jī)應(yīng)用的訪問(wèn)策略設(shè)定
• 安全外聯(lián)：基礎(chǔ)訪問(wèn)鑒權(quán)，攔截非法請(qǐng)求
• 統(tǒng)一接入：提供統(tǒng)一接入的權(quán)限申請(qǐng)平臺(tái)，提供統(tǒng)一的登錄管理

故障快照

在系統(tǒng)故障的時(shí)候我們第一要?jiǎng)?wù)是系統(tǒng)恢復(fù)，同時(shí)保留案發(fā)現(xiàn)場(chǎng)也是非常重要的，資源調(diào)度平臺(tái)則需要有統(tǒng)一的機(jī)制保存好故障現(xiàn)場(chǎng)。

• 現(xiàn)場(chǎng)保留：內(nèi)存分布，線程數(shù)等資源現(xiàn)象的保存，如 JavaDump 鉤子接入
• 調(diào)試接入：采用字節(jié)碼技術(shù)無(wú)需侵入業(yè)務(wù)代碼，可以供生產(chǎn)環(huán)境現(xiàn)場(chǎng)日志打點(diǎn)調(diào)試

流量調(diào)度

在我們建設(shè)好分布式系統(tǒng)后，最先受到考驗(yàn)的關(guān)口就是網(wǎng)關(guān)了，進(jìn)而我們需要關(guān)注系統(tǒng)流量的情況，也就是如何對(duì)流量的管理，我們追求的是在系統(tǒng)可容納的流量上限內(nèi)，把資源留給最優(yōu)質(zhì)的流量使用、把非法惡意的流量擋在門(mén)外，這樣節(jié)省成本的同時(shí)確保系統(tǒng)不會(huì)被沖擊崩潰。

負(fù)載均衡

負(fù)載均衡是我們對(duì)服務(wù)如何消化流量的通用設(shè)計(jì)，通常分為物理層的底層協(xié)議分流的硬負(fù)載均衡和軟件層的軟負(fù)載。負(fù)載均衡解決方案已經(jīng)是業(yè)界成熟的方案，我們通常會(huì)針對(duì)特定業(yè)務(wù)在不同環(huán)境進(jìn)行優(yōu)化，常用有如下的負(fù)載均衡解決方案

• 交換機(jī)
• F5
• LVS/ALI-LVS
• Nginx/Tengine
• VIPServer/ConfigServer

網(wǎng)關(guān)設(shè)計(jì)

負(fù)載均衡首當(dāng)其沖的就是網(wǎng)關(guān)，因?yàn)橹行幕毫髁孔钕却虻降牡胤骄褪蔷W(wǎng)關(guān)了，如果網(wǎng)關(guān)扛不住壓力的話，那么整個(gè)系統(tǒng)將不可用。

• 高性能：網(wǎng)關(guān)設(shè)計(jì)第一需要考慮的是高性能的流量轉(zhuǎn)發(fā)，網(wǎng)關(guān)單節(jié)點(diǎn)通常能達(dá)到上百萬(wàn)的并發(fā)流量
• 分布式：出于流量壓力分擔(dān)和災(zāi)備考慮，網(wǎng)關(guān)設(shè)計(jì)同樣需要分布式
• 業(yè)務(wù)篩選：網(wǎng)關(guān)同設(shè)計(jì)簡(jiǎn)單的規(guī)則，排除掉大部分的惡意流量

流量管理

• 請(qǐng)求校驗(yàn)：請(qǐng)求鑒權(quán)可以把多少非法請(qǐng)求攔截，清洗
• 數(shù)據(jù)緩存：多數(shù)無(wú)狀態(tài)的請(qǐng)求存在數(shù)據(jù)熱點(diǎn)，所以采用 CDN 可以把相當(dāng)大一部分的流量消費(fèi)掉

流控控制

剩下的真實(shí)流量我們采用不同的算法來(lái)分流請(qǐng)求。

• 流量分配

  • 計(jì)數(shù)器
  • 隊(duì)列
  • 漏斗
  • 令牌桶
  • 動(dòng)態(tài)流控
• 流量限制在流量激增的時(shí)候，通常我們需要有限流措施來(lái)防止系統(tǒng)出現(xiàn)雪崩，那么就需要預(yù)估系統(tǒng)的流量上限，然后設(shè)定好上限數(shù)，但流量增加到一定閾值后，多出來(lái)的流量則不會(huì)進(jìn)入系統(tǒng)，通過(guò)犧牲部分流量來(lái)保全系統(tǒng)的可用性。
  • 限流策略
  • QPS 粒度
  • 線程數(shù)粒度
  • RT 閾值
  • 限流工具 - Sentinel

服務(wù)調(diào)度

所謂打鐵還需自身硬，流量做好了調(diào)度管理后，剩下的就是服務(wù)自身的健壯性了。分布式系統(tǒng)服務(wù)出現(xiàn)故障是常有的事情，甚至我們需要把故障本身當(dāng)做是分布式服務(wù)的一部分。

注冊(cè)中心

我們網(wǎng)絡(luò)管理一節(jié)中介紹了網(wǎng)關(guān)，網(wǎng)關(guān)是流量的集散地，而注冊(cè)中心則是服務(wù)的根據(jù)地。

• 狀態(tài)類(lèi)型：第一好應(yīng)用服務(wù)的狀態(tài)，通過(guò)注冊(cè)中心就可以檢測(cè)服務(wù)是否可用
• 生命周期：應(yīng)用服務(wù)不同的狀態(tài)組成了應(yīng)用的生命周期

版本管理

• 集群版本：集群不用應(yīng)用有自身對(duì)應(yīng)的版本號(hào)，由不同服務(wù)組成的集群也需要定義大的版本號(hào)
• 版本回滾：在部署異常的時(shí)候可以根據(jù)大的集群版本進(jìn)行回滾管理

服務(wù)編排

服務(wù)編排的定義是：通過(guò)消息的交互序列來(lái)控制各個(gè)部分資源的交互。參與交互的資源都是對(duì)等的，沒(méi)有集中的控制。微服務(wù)環(huán)境下服務(wù)眾多我們需要有一個(gè)總的協(xié)調(diào)器來(lái)協(xié)議服務(wù)之間的依賴(lài)，調(diào)用關(guān)系，K8s 則是我們的不二選擇。

• K8s
• Spring Cloud
  • HSF
  • ZK+Dubbo

服務(wù)控制

前面我們解決了網(wǎng)絡(luò)的健壯性和效率問(wèn)題，這節(jié)介紹的是如何使我們的服務(wù)更加健壯。

• 發(fā)現(xiàn)資源管理那節(jié)我們介紹了從云平臺(tái)申請(qǐng)了容器宿主資源后，通過(guò)自動(dòng)化腳本就可以啟動(dòng)應(yīng)用服務(wù)，啟動(dòng)后服務(wù)則需要發(fā)現(xiàn)注冊(cè)中心，并且把自身的服務(wù)信息注冊(cè)到服務(wù)網(wǎng)關(guān)，即是網(wǎng)關(guān)接入。注冊(cè)中心則會(huì)監(jiān)控服務(wù)的不同狀態(tài)，做健康檢查，把不可用的服務(wù)歸類(lèi)標(biāo)記。

  • 網(wǎng)關(guān)接入
  • 健康檢查

• 降級(jí)：當(dāng)用戶激增的時(shí)候，我們首先是在流量端做手腳，也就是限流。當(dāng)我們發(fā)現(xiàn)限流后系統(tǒng)響應(yīng)變慢了，有可能導(dǎo)致更多的問(wèn)題時(shí)，我們也需要對(duì)服務(wù)本身做一些操作。服務(wù)降級(jí)就是把當(dāng)前不是很核心的功能關(guān)閉掉，或者不是很要緊的準(zhǔn)確性放寬范圍，事后再做一些人工補(bǔ)救。

  • 降低一致性約束
  • 關(guān)閉非核心服務(wù)
  • 簡(jiǎn)化功能

• 熔斷：當(dāng)我們都做了以上的操作后，還是覺(jué)得不放心，那么就需要再進(jìn)一步操心。熔斷是對(duì)過(guò)載的一種自身保護(hù)，猶如我們開(kāi)關(guān)跳閘一樣。比如當(dāng)我們服務(wù)不斷對(duì)數(shù)據(jù)庫(kù)進(jìn)行查詢的時(shí)候，如果業(yè)務(wù)問(wèn)題造成查詢問(wèn)題，這是數(shù)據(jù)庫(kù)本身需要熔斷來(lái)保證不會(huì)被應(yīng)用拖垮，并且訪問(wèn)友好的信息，告訴服務(wù)不要再盲目調(diào)用了。

  • 閉合狀態(tài)
  • 半開(kāi)狀態(tài)
  • 斷開(kāi)狀態(tài)
  • 熔斷工具- Hystrix
• 冪等：我們知道，一個(gè)冪等操作的特點(diǎn)是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。那么就需要對(duì)單次操作賦予一個(gè)全局的 id 來(lái)做標(biāo)識(shí)，這樣多次請(qǐng)求后我們可以判斷來(lái)源于同個(gè)客戶端，避免出現(xiàn)臟數(shù)據(jù)。
  • 全局一致性 ID
  • Snowflake

數(shù)據(jù)調(diào)度

數(shù)據(jù)存儲(chǔ)最大的挑戰(zhàn)就是數(shù)據(jù)冗余的管理，冗余多了效率變低而且占用資源，副本少了起不到災(zāi)備的作用，我們通常的做法是把有轉(zhuǎn)態(tài)的請(qǐng)求，通過(guò)轉(zhuǎn)態(tài)分離，轉(zhuǎn)化為無(wú)狀態(tài)請(qǐng)求。

狀態(tài)轉(zhuǎn)移

分離狀態(tài)至全局存儲(chǔ)，請(qǐng)求轉(zhuǎn)換為無(wú)狀態(tài)流量，比如我們通常會(huì)將登陸信息緩存至全局 redis 中間件，而不需要在多個(gè)應(yīng)用中去冗余用戶的登陸數(shù)據(jù)。

分庫(kù)分表

數(shù)據(jù)橫向擴(kuò)展。

分片分區(qū)

多副本冗余。

自動(dòng)化運(yùn)維

我們從資源申請(qǐng)管理的時(shí)候就介紹到 devops 的趨勢(shì)，真正做到開(kāi)發(fā)運(yùn)維一體化則需要不同的中間件來(lái)配合完成。

配置中心

全局配置中心按環(huán)境來(lái)區(qū)分，統(tǒng)一管理，減少了多處配置的混亂局面。

• switch
• diamend

部署策略

微服務(wù)分布式部署是家常便飯，如何讓我們的服務(wù)更好地支撐業(yè)務(wù)發(fā)展，穩(wěn)健的部署策略是我們首先需要考慮的，如下的部署策略適合不同業(yè)務(wù)和不同的階段。

• 停機(jī)部署
• 滾動(dòng)部署
• 藍(lán)綠部署
• 灰度部署
• A/B 測(cè)試

作業(yè)調(diào)度

任務(wù)調(diào)度是系統(tǒng)必不可少的一個(gè)環(huán)節(jié)，傳統(tǒng)的方式是在 Linux 機(jī)器上配置 crond 定時(shí)任務(wù)或者直接在業(yè)務(wù)代碼里面完成調(diào)度業(yè)務(wù)，現(xiàn)在則是成熟的中間件來(lái)代替。

• SchedulerX
• Spring 定時(shí)任務(wù)

應(yīng)用管理

運(yùn)維工作中很大一部分時(shí)間需要對(duì)應(yīng)用進(jìn)行重啟，上下線操作，還有日志清理。

• 應(yīng)用重啟
• 應(yīng)用下線
• 日志清理

容錯(cuò)處理

既然我們知道分布式系統(tǒng)故障是家常便飯，那么應(yīng)對(duì)故障的方案也是不可或缺的環(huán)節(jié)。通常我們有主動(dòng)和被動(dòng)的方式來(lái)處理：

• 主動(dòng)是在錯(cuò)誤出現(xiàn)的時(shí)候，我們?cè)噲D再試試幾次，說(shuō)不定就成功了，成功的話就可以避免了該次錯(cuò)誤
• 被動(dòng)方式是錯(cuò)誤的事情已經(jīng)發(fā)生了，為了挽回，我們只是做時(shí)候處理，把負(fù)面影響降到最小

重試設(shè)計(jì)

重試設(shè)計(jì)的關(guān)鍵在于設(shè)計(jì)好重試的時(shí)間和次數(shù)，如果超過(guò)重試次數(shù)，或是一段時(shí)間，那么重試就沒(méi)有意義了。開(kāi)源的項(xiàng)目 spring-retry 可以很好地實(shí)現(xiàn)我們重試的計(jì)劃。

事務(wù)補(bǔ)償

事務(wù)補(bǔ)償符合我們最終一致性的理念。補(bǔ)償事務(wù)不一定會(huì)將系統(tǒng)中的數(shù)據(jù)返回到原始操作開(kāi)始時(shí)其所處的狀態(tài)。 相反，它補(bǔ)償操作失敗前由已成功完成的步驟所執(zhí)行的工作。補(bǔ)償事務(wù)中步驟的順序不一定與原始操作中步驟的順序完全相反。 例如，一個(gè)數(shù)據(jù)存儲(chǔ)可能比另一個(gè)數(shù)據(jù)存儲(chǔ)對(duì)不一致性更加敏感，因而補(bǔ)償事務(wù)中撤銷(xiāo)對(duì)此存儲(chǔ)的更改的步驟應(yīng)該會(huì)首先發(fā)生。對(duì)完成操作所需的每個(gè)資源采用短期的基于超時(shí)的鎖并預(yù)先獲取這些資源，這樣有助于增加總體活動(dòng)成功的可能性。 僅在獲取所有資源后才應(yīng)執(zhí)行工作。 鎖過(guò)期之前必須完成所有操作。

全棧監(jiān)控

由于分布式系統(tǒng)是由眾多機(jī)器共同協(xié)作的系統(tǒng)，而且網(wǎng)絡(luò)也無(wú)法保證完全可用，所以我們需要建設(shè)一套對(duì)各個(gè)環(huán)節(jié)都能監(jiān)控的系統(tǒng)，這樣我們才能從底層到業(yè)務(wù)各個(gè)層面進(jìn)行監(jiān)控，出現(xiàn)意外的時(shí)候可以及時(shí)修復(fù)故障，避免更多的問(wèn)題出現(xiàn)。

基礎(chǔ)層

基礎(chǔ)層面是對(duì)容器資源的監(jiān)測(cè)，包含各個(gè)硬件指標(biāo)的負(fù)載情況

• CPU、IO、內(nèi)存、線程、吞吐

中間件

分布式系統(tǒng)接入了大量的中間件平臺(tái)，中間件本身的健康情況也需要監(jiān)控。

應(yīng)用層

• 性能監(jiān)控：應(yīng)用層面的需要對(duì)每個(gè)應(yīng)用服務(wù)的實(shí)時(shí)指標(biāo)（qps，rt），上下游依賴(lài)等進(jìn)行監(jiān)控
• 業(yè)務(wù)監(jiān)控：除了應(yīng)用本身的監(jiān)控程度，業(yè)務(wù)監(jiān)控也是保證系統(tǒng)正常的一個(gè)環(huán)節(jié)，通過(guò)設(shè)計(jì)合理的業(yè)務(wù)規(guī)則，對(duì)異常的情況做報(bào)警設(shè)置

監(jiān)控鏈路

• zipkin/eagleeye
• sls
• goc
• Alimonitor

故障恢復(fù)

當(dāng)故障已經(jīng)發(fā)生后，我們第一個(gè)要做的就是馬上消除故障，確保系統(tǒng)服務(wù)正常可用，這個(gè)時(shí)候通常做回滾操作。

應(yīng)用回滾

應(yīng)用回滾之前需要保存好故障現(xiàn)場(chǎng)，以便排查原因。

基線回退

應(yīng)用服務(wù)回滾后，代碼基線也需要 revert 到前一版本。

版本回滾

整體回滾需要服務(wù)編排，通過(guò)大版本號(hào)對(duì)集群進(jìn)行回滾。

性能調(diào)優(yōu)

性能優(yōu)化是分布式系統(tǒng)的大專(zhuān)題，涉及的面非常廣，這塊簡(jiǎn)直可以單獨(dú)拿出來(lái)做一個(gè)系列來(lái)講，本節(jié)就先不展開(kāi)。本身我們做服務(wù)治理的過(guò)程也是在性能的優(yōu)化過(guò)程。<br />參考《高并發(fā)編程知識(shí)體系》

分布式鎖

緩存是解決性能問(wèn)題的一大利器，理想情況下，每個(gè)請(qǐng)求不需要額外計(jì)算就立刻能獲取到結(jié)果時(shí)最快。小到 CPU 的三級(jí)緩存，大到分布式緩存，緩存無(wú)處不在，分布式緩存需要解決的就是數(shù)據(jù)的一致性，這個(gè)時(shí)候我們引入了分布式鎖的概念，如何處理分布式鎖的問(wèn)題將決定我們獲取緩存數(shù)據(jù)的效率。

高并發(fā)

多線程編程模式提升了系統(tǒng)的吞吐量，但也同時(shí)帶來(lái)了業(yè)務(wù)的復(fù)雜度。

異步

事件驅(qū)動(dòng)的異步編程是一種新的編程模式，摒棄了多線程的復(fù)雜業(yè)務(wù)處理問(wèn)題，同時(shí)能夠提升系統(tǒng)的響應(yīng)效率。

總結(jié)

最后總結(jié)一下，如果有可能的話，請(qǐng)嘗試使用單節(jié)點(diǎn)方式而不是分布式系統(tǒng)。分布式系統(tǒng)伴隨著一些失敗的操作，為了處理災(zāi)難性故障，我們使用備份；為了提高可靠性，我們引入了冗余。

分布式系統(tǒng)本質(zhì)就是一堆機(jī)器的協(xié)同，而我們要做的就是搞出各種手段來(lái)然機(jī)器的運(yùn)行達(dá)到預(yù)期。這么復(fù)雜的系統(tǒng)，需要了解各個(gè)環(huán)節(jié)、各個(gè)中間件的接入，是一個(gè)非常大的工程。慶幸的是，在微服務(wù)背景下，多數(shù)基礎(chǔ)性的工作已經(jīng)有人幫我們實(shí)現(xiàn)了。前文所描述的分布式架構(gòu)，在工程實(shí)現(xiàn)了是需要用到分布式三件套 (Docker+K8S+Srping Cloud) 基本就可以構(gòu)建出來(lái)了。

分布式架構(gòu)核心技術(shù)分布圖如下：

原圖來(lái)源：https://dzone.com/articles/deploying-microservices-spring-cloud-vs-kubernetes

分布式技術(shù)棧使用中間件：

原圖來(lái)源：https://dzone.com/articles/deploying-microservices-spring-cloud-vs-kubernetes

“ 阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的技術(shù)公眾號(hào)。”

網(wǎng)頁(yè)名稱(chēng)：一文讀懂分布式架構(gòu)知識(shí)體系（內(nèi)含超全核心知識(shí)大圖）
網(wǎng)站地址：http://chinadenli.net/article12/geosdc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、移動(dòng)網(wǎng)站建設(shè)、品牌網(wǎng)站建設(shè)、面包屑導(dǎo)航、電子商務(wù)、網(wǎng)站排名

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)