1.問題

• 1、何為分布式何為微服務(wù)川队？

• 2力细、為什么需要分布式？

• 3固额、分布式核心理論基礎(chǔ)眠蚂，節(jié)點(diǎn)、網(wǎng)絡(luò)斗躏、時間逝慧、順序，一致性啄糙？

• 4笛臣、分布式是系統(tǒng)有哪些設(shè)計模式？

• 5隧饼、分布式有哪些類型沈堡？

• 6、如何實(shí)現(xiàn)分布式燕雁？

2.關(guān)鍵詞

節(jié)點(diǎn)诞丽，時間，一致性拐格，CAP僧免，ACID，BASE捏浊，P2P懂衩，機(jī)器伸縮，網(wǎng)絡(luò)變更，負(fù)載均衡勃痴，限流谒所，鑒權(quán)，服務(wù)發(fā)現(xiàn)沛申，服務(wù)編排劣领，降級，熔斷铁材，冪等尖淘，分庫分表，分片分區(qū)著觉，自動運(yùn)維村生，容錯處理，全棧監(jiān)控饼丘，故障恢復(fù)趁桃，性能調(diào)優(yōu)

3.全文概要

隨著移動互聯(lián)網(wǎng)的發(fā)展智能終端的普及，計算機(jī)系統(tǒng)早就從單機(jī)獨(dú)立工作過渡到多機(jī)器協(xié)作工作肄鸽。計算機(jī)以集群的方式存在卫病，按照分布式理論的指導(dǎo)構(gòu)建出龐大復(fù)雜的應(yīng)用服務(wù)，也已經(jīng)深入人心典徘。本文力求從分布式基礎(chǔ)理論蟀苛，架構(gòu)設(shè)計模式，工程應(yīng)用逮诲，部署運(yùn)維帜平，業(yè)界方案這幾大方面，介紹基于MSA(微服務(wù)架構(gòu))的分布式的知識體系大綱梅鹦。從而對SOA到MSA進(jìn)化有個立體的認(rèn)識裆甩，從概念上和工具應(yīng)用上更近一步了解微服務(wù)分布式的本質(zhì)，身臨其境的感受如何搭建全套微服務(wù)架構(gòu)的過程帘瞭。

4.基礎(chǔ)理論

4.1SOA到MSA的進(jìn)化

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

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

image

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

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

image

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

節(jié)點(diǎn)

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

網(wǎng)絡(luò)

分布式架構(gòu)的根基就是網(wǎng)絡(luò)，不管是局域網(wǎng)還是公網(wǎng)秸侣，沒有網(wǎng)絡(luò)就無法把計算機(jī)聯(lián)合在一起工作存筏，但是網(wǎng)絡(luò)也帶來了一系列的問題。網(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ǎng)絡(luò)傳輸層有兩大協(xié)議的特點(diǎn)簡介：

TCP協(xié)議

• 首先tcp盡管其他可以更快

• tcp解決重復(fù)和亂序問題

UDP協(xié)議

• 常量數(shù)據(jù)流

• 丟包不致命

4.3時間與順序

時間

慢速物理時空中椭坚，時間獨(dú)自在流淌著，對于串行的事務(wù)來說搏色，很簡單的就是跟著時間的腳步走就可以善茎，先來后到的發(fā)生。而后我們發(fā)明了時鐘來刻畫以往發(fā)生的時間點(diǎn)频轿，時鐘讓這個世界盡然有序垂涯。但是對于分布式世界來說，跟時間打交道著實(shí)是一件痛苦的事情航邢。分布式世界里面耕赘，我們要協(xié)調(diào)不同節(jié)點(diǎn)之間的先來后到關(guān)系，但是不同節(jié)點(diǎn)本身承認(rèn)的時間又各執(zhí)己見膳殷，于是我們創(chuàng)造了網(wǎng)絡(luò)時間協(xié)議（NTP）試圖來解決不同節(jié)點(diǎn)之間的標(biāo)準(zhǔn)時間操骡，但是NTP本身表現(xiàn)并不如人意纵寝，所以我們又構(gòu)造除了邏輯時鐘蝉揍，最后改進(jìn)為向量時鐘：

NTP的一些缺點(diǎn)，無法完全滿足分布式下并發(fā)任務(wù)的協(xié)調(diào)問題

• 節(jié)點(diǎn)間時間不同步

• 硬件時鐘漂移

• 線程可能休眠

• 操作系統(tǒng)休眠

• 硬件休眠

image.gif

邏輯時鐘

• 定義事件先來后到

• t’ = max(t, t_msg + 1)

• image

向量時鐘

• t_i’ = max(t_i, t_msg_i)

原子鐘

順序

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

4.4一致性理論

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

image

該圖對比了不同一致性算法下的事務(wù)冀惭，性能震叙，錯誤，延遲的平衡散休。

強(qiáng)一致性ACID

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

• Atomicity：原子性划址，一個事務(wù)中的所有操作，要么全部完成限府，要么全部不完成夺颤，不會結(jié)束在中間某個環(huán)節(jié)。

• Consistency：一致性胁勺，在事務(wù)開始之前和事務(wù)結(jié)束以后世澜，數(shù)據(jù)庫的完整性沒有被破壞。

• Isolation：隔離性署穗，數(shù)據(jù)庫允許多個并發(fā)事務(wù)同時對其數(shù)據(jù)進(jìn)行讀寫和修改的能力寥裂，隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。

• Durabilit：事務(wù)處理結(jié)束后案疲，對數(shù)據(jù)的修改就是永久的封恰，即便系統(tǒng)故障也不會丟失。

分布式一致性CAP

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

• CAP:分布式計算系統(tǒng)不可能同時確保一致性（Consistency）、可用性（Availablity）和分區(qū)容忍性（Partition）备畦。

• FLP：在異步環(huán)境中低飒，如果節(jié)點(diǎn)間的網(wǎng)絡(luò)延遲沒有上限，只要有一個惡意的節(jié)點(diǎn)存在萍恕，就沒有算法能在有限的時間內(nèi)達(dá)成共識逸嘀。

• DLS:

  （1）在一個部分同步網(wǎng)絡(luò)的模型（也就是說：網(wǎng)絡(luò)延時有界限但是我們并不知道在哪里）下運(yùn)行的協(xié)議可以容忍1/3任意（換句話說，拜占庭）錯誤允粤；

  （2）在一個異步模型中的確定性的協(xié)議（沒有網(wǎng)絡(luò)延時上限）不能容錯（不過這個論文沒有提起隨機(jī)化算法可以容忍1/3的錯誤）崭倘；

  （3）同步模型中的協(xié)議（網(wǎng)絡(luò)延時可以保證小于已知d時間）可以翼岁，令人吃驚的，達(dá)到100%容錯司光，雖然對1/2的節(jié)點(diǎn)出錯可以發(fā)生的情況有所限制

弱一致性BASE

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

• 基本可用(Basically Available)：基本可用是指分布式系統(tǒng)在出現(xiàn)故障的時候，允許損失部分可用性回窘，即保證核心可用诺擅。

• 軟狀態(tài)(Soft State)：軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會影響系統(tǒng)整體可用性啡直。分布式存儲中一般一份數(shù)據(jù)至少會有三個副本烁涌，允許不同節(jié)點(diǎn)間副本同步的延時就是軟狀態(tài)的體現(xiàn)。

• 最終一致性(Eventual Consistency)：最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時間后酒觅，最終能夠達(dá)到一致的狀態(tài)撮执。弱一致性和強(qiáng)一致性相反，最終一致性是弱一致性的一種特殊情況舷丹。

一致性算法

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

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

CALM原則的全稱是 Consistency and Logical Monotonicity 装获，主要描述的是分布式系統(tǒng)中單調(diào)邏輯與一致性的關(guān)系，它的內(nèi)容如下厉颤，參考consistency as logical monotonicity

• 在分布式系統(tǒng)中穴豫，單調(diào)的邏輯都能保證 “最終一致性”，這個過程中不需要依賴中心節(jié)點(diǎn)的調(diào)度

• 任意分布式系統(tǒng)逼友，如果所有的非單調(diào)邏輯都有中心節(jié)點(diǎn)調(diào)度精肃，那么這個分布式系統(tǒng)就可以實(shí)現(xiàn)最終“一致性”

然后再關(guān)注分布式系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)CRDT(Conflict-Free Replicated Data Types)：

我們了解到分布式一些規(guī)律原則之后，就要著手考慮如何來實(shí)現(xiàn)解決方案帜乞，一致性算法的前提是數(shù)據(jù)結(jié)構(gòu)司抱，或者說一切算法的根基都是數(shù)據(jù)結(jié)構(gòu)，設(shè)計良好的數(shù)據(jù)結(jié)構(gòu)加上精妙的算法可以高效的解決現(xiàn)實(shí)的問題黎烈。經(jīng)過前人不斷的探索习柠，我們得知分布式系統(tǒng)被廣泛采用的數(shù)據(jù)結(jié)構(gòu)CRDT匀谣。

參考《談?wù)凜RDT》,A comprehensive study of Convergent and Commutative Replicated Data Types

• 基于狀態(tài)(state-based)：即將各個節(jié)點(diǎn)之間的CRDT數(shù)據(jù)直接進(jìn)行合并，所有節(jié)點(diǎn)都能最終合并到同一個狀態(tài)资溃，數(shù)據(jù)合并的順序不會影響到最終的結(jié)果武翎。

• 基于操作(operation-based)：將每一次對數(shù)據(jù)的操作通知給其他節(jié)點(diǎn)。只要節(jié)點(diǎn)知道了對數(shù)據(jù)的所有操作（收到操作的順序可以是任意的）溶锭，就能合并到同一個狀態(tài)宝恶。

了解數(shù)據(jù)結(jié)構(gòu)后，我們需要來關(guān)注一下分布式系統(tǒng)的一些重要的協(xié)議HATs(Highly Available Transactions)趴捅，ZAB(Zookeeper Atomic Broadcast)：

參考《高可用事務(wù)》垫毙，《ZAB協(xié)議分析》

最后要學(xué)習(xí)的是業(yè)界主流的一致性算法：

說實(shí)話具體的算法我也還沒完全搞懂，一致性算法是分布式系統(tǒng)最核心本質(zhì)的內(nèi)容拱绑，這部分的發(fā)展也會影響架構(gòu)的革新综芥，不同場景的應(yīng)用也催生不同的算法

• Paxos：《優(yōu)雅的Paxos算法》

• Raft ：《Raft 一致性算法》

• Gossip：《Gossip Visualization》

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

5.場景分類

5.1文件系統(tǒng)

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

• HDFS

• FastDFS

• Ceph

• mooseFS

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

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

• 列式存儲：Hbase

• 文檔存儲：Elasticsearch任内，MongoDB

• KV類型：Redis

• 關(guān)系型：Spanner

5.3計算

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

• 離線：Hadoop

• 實(shí)時：Spark

• 流式：Storm廊敌，F(xiàn)link/Blink

5.4緩存

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

• 持久化：Redis

• 非持久化：Memcache

5.5消息

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

• Kafka

• RabbitMQ

• RocketMQ

• ActiveMQ

5.6監(jiān)控

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

• Zookeeper

5.7應(yīng)用

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

• HSF

• Dubble

5.8日志

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

• 日志采集：flume

• 日志存儲：ElasticSearch/Solr绢记，SLS

• 日志定位：Zipkin

5.9賬本

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

• 比特幣

• 以太坊

6.設(shè)計模式

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

6.1可用性

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

• 健康檢查：系統(tǒng)實(shí)現(xiàn)全鏈路功能檢查，外部工具定期通過公開端點(diǎn)訪問系統(tǒng)

• 負(fù)載均衡：使用隊列起到削峰作用岖赋，作為請求和服務(wù)之間的緩沖區(qū)檬果，以平滑間歇性的重負(fù)載

• 節(jié)流：限制應(yīng)用級別、租戶或整個服務(wù)所消耗資源的范圍

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

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

• 緩存：根據(jù)需要將數(shù)據(jù)從數(shù)據(jù)存儲層加載到緩存

• CQRS(Command Query Responsibility Segregation)： 命令查詢職責(zé)分離

• 事件溯源：僅使用追加方式記錄域中完整的系列事件

• 索引表：在經(jīng)常查詢引用的字段上創(chuàng)建索引

• 物化視圖：生成一個或多個數(shù)據(jù)預(yù)填充視圖

• 拆分：將數(shù)據(jù)拆分為水平的分區(qū)或分片

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

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

• 代理：反向代理

• 適配器： 在現(xiàn)代應(yīng)用程序和遺留系統(tǒng)之間實(shí)現(xiàn)適配器層

• 前后端分離： 后端服務(wù)提供接口供前端應(yīng)用程序調(diào)用

• 計算資源整合：將多個相關(guān)任務(wù)或操作合并到一個計算單元中

• 配置分離：將配置信息從應(yīng)用程序部署包中移出到配置中心

• 網(wǎng)關(guān)聚合：使用網(wǎng)關(guān)將多個單獨(dú)的請求聚合到一個請求中

• 網(wǎng)關(guān)卸載：將共享或?qū)Ｓ梅?wù)功能卸載到網(wǎng)關(guān)代理

• 網(wǎng)關(guān)路由：使用單個端點(diǎn)將請求路由到多個服務(wù)

• 領(lǐng)導(dǎo)人選舉：通過選擇一個實(shí)例作為負(fù)責(zé)管理其他實(shí)例管理員碗脊，協(xié)調(diào)分布式系統(tǒng)的云

• 管道和過濾器：將復(fù)雜的任務(wù)分解為一系列可以重復(fù)使用的單獨(dú)組件

• 邊車：將應(yīng)用的監(jiān)控組件部署到單獨(dú)的進(jìn)程或容器中，以提供隔離和封裝

• 靜態(tài)內(nèi)容托管：將靜態(tài)內(nèi)容部署到CDN橄妆，加速訪問效率

6.4消息

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

• 競爭消費(fèi)者：多線程并發(fā)消費(fèi)

• 優(yōu)先級隊列： 消息隊列分優(yōu)先級芬沉，優(yōu)先級高的先被消費(fèi)

6.5管理與監(jiān)控

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

6.6性能與擴(kuò)展

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

6.7彈性

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

• 隔離：將應(yīng)用程序的元素隔離到池中凤粗，以便在其中一個失敗時酥泛，其他元素將繼續(xù)運(yùn)行。

• 斷路器：處理連接到遠(yuǎn)程服務(wù)或資源時可能需要不同時間修復(fù)的故障。

• 補(bǔ)償交易：撤消一系列步驟執(zhí)行的工作揭璃，這些步驟共同定義最終一致的操作

• 健康檢查：系統(tǒng)實(shí)現(xiàn)全鏈路功能檢查，外部工具定期通過公開端點(diǎn)訪問系統(tǒng)

• 重試：通過透明地重試先前失敗的操作亭罪，使應(yīng)用程序在嘗試連接到服務(wù)或網(wǎng)絡(luò)資源時處理預(yù)期的臨時故障

6.8安全

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

• 聯(lián)合身份：將身份驗(yàn)證委派給外部身份提供商

• 看門人： 通過使用專用主機(jī)實(shí)例來保護(hù)應(yīng)用程序和服務(wù)袍祖，該實(shí)例充當(dāng)客戶端與應(yīng)用程序或服務(wù)之間的代理底瓣，驗(yàn)證和清理請求，并在它們之間傳遞請求和數(shù)據(jù)

• 代客鑰匙：使用為客戶端提供對特定資源或服務(wù)的受限直接訪問的令牌或密鑰蕉陋。

7.工程應(yīng)用

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

7.1資源調(diào)度

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

彈性伸縮

過去軟件系統(tǒng)隨著用戶量增加需要增加機(jī)器資源的話绞旅，傳統(tǒng)的方式就是找運(yùn)維申請機(jī)器，然后部署好軟件服務(wù)接入集群温艇，整個過程依賴的是運(yùn)維人員的人肉經(jīng)驗(yàn)因悲，效率低下而且容易出錯。微服務(wù)分布式則無需人肉增加物理機(jī)器勺爱，在容器化技術(shù)的支撐下晃琳，我們只需要申請云資源，然后執(zhí)行容器腳本即可。

• 應(yīng)用擴(kuò)容

  用戶激增需要對服務(wù)進(jìn)行擴(kuò)展卫旱，包括自動化擴(kuò)容人灼，峰值過后的自動縮容

• 機(jī)器下線

  對于過時應(yīng)用，進(jìn)行應(yīng)用下線顾翼，云平臺收回容器宿主資源

• 機(jī)器置換

  對于故障機(jī)器投放，可供置換容器宿主資源，服務(wù)自動啟動适贸，無縫切換

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

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

• 域名申請

  應(yīng)用申請配套域名資源的申請谒获，多套域名映射規(guī)則的規(guī)范

• 域名變更

  域名變更統(tǒng)一平臺管理

• 負(fù)載管理

  多機(jī)應(yīng)用的訪問策略設(shè)定

• 安全外聯(lián)

  基礎(chǔ)訪問鑒權(quán)，攔截非法請求

• 統(tǒng)一接入

  提供統(tǒng)一接入的權(quán)限申請平臺晴埂，提供統(tǒng)一的登錄管理

故障快照

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

• 現(xiàn)場保留

  內(nèi)存分布精耐，線程數(shù)等資源現(xiàn)象的保存，如JavaDump鉤子接入

• 調(diào)試接入

  采用字節(jié)碼技術(shù)無需入侵業(yè)務(wù)代碼琅锻，可以供生產(chǎn)環(huán)境現(xiàn)場日志打點(diǎn)調(diào)試

7.2流量調(diào)度

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

負(fù)載均衡

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

• 交換機(jī)

• F5

• LVS/ALI-LVS

• Nginx/Tengine

• VIPServer/ConfigServer

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

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

• 高性能

  網(wǎng)關(guān)設(shè)計第一需要考慮的是高性能的流量轉(zhuǎn)發(fā)檬输，網(wǎng)關(guān)單節(jié)點(diǎn)通常能達(dá)到上百萬的并發(fā)流量

• 分布式

  出于流量壓力分擔(dān)和災(zāi)備考慮主卫，網(wǎng)關(guān)設(shè)計同樣需要分布式

• 業(yè)務(wù)篩選

  網(wǎng)關(guān)同設(shè)計簡單的規(guī)則，排除掉大部分的惡意流量

流量管理

• 請求校驗(yàn)

  請求鑒權(quán)可以把多少非法請求攔截关噪，清洗

• 數(shù)據(jù)緩存

  多數(shù)無狀態(tài)的請求存在數(shù)據(jù)熱點(diǎn)虐沥，所以采用CDN可以把相當(dāng)大一部分的流量消費(fèi)掉

流控控制

剩下的真實(shí)流量我們采用不同的算法來分流請求

• 流量分配

• 計數(shù)器

• 隊列

• 漏斗

• 令牌桶

• 動態(tài)流控

• 流量限制

  在流量激增的時候天试，通常我們需要有限流措施來防止系統(tǒng)出現(xiàn)雪崩带兜，那么就需要預(yù)估系統(tǒng)的流量上限涩咖，然后設(shè)定好上限數(shù)闸昨，但流量增加到一定閾值后循诉，多出來的流量則不會進(jìn)入系統(tǒng)，通過犧牲部分流量來保全系統(tǒng)的可用性撇他。

• QPS粒度

• 線程數(shù)粒度

• RT閾值

• 限流策略

• 限流工具 - Sentinel

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

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

注冊中心

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

• 狀態(tài)類型

  第一好應(yīng)用服務(wù)的狀態(tài)笙蒙，通過注冊中心就可以檢測服務(wù)是否可用

• 生命周期

  應(yīng)用服務(wù)不同的狀態(tài)組成了應(yīng)用的生命周期

版本管理

• 集群版本

  集群不用應(yīng)用有自身對應(yīng)的版本號，由不同服務(wù)組成的集群也需要定義大的版本號

• 版本回滾

  在部署異常的時候可以根據(jù)大的集群版本進(jìn)行回滾管理

服務(wù)編排

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

• K8S

• Spring Cloud

• HSF

• ZK+Dubble

服務(wù)控制

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

• 發(fā)現(xiàn)

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

• 網(wǎng)關(guān)接入

• 健康檢查

• 降級

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

• 降低一致性約束

• 關(guān)閉非核心服務(wù)

• 簡化功能

• 熔斷

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

• 閉合狀態(tài)

• 半開狀態(tài)

• 斷開狀態(tài)

• 熔斷工具- Hystrix

• 冪等

  我們知道挎挖，一個冪等操作的特點(diǎn)是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。那么久需要對單次操作賦予一個全局的id來做標(biāo)識航夺，這樣多次請求后我們可以判斷來源于同個客戶端蕉朵，避免出現(xiàn)臟數(shù)據(jù)。

• 全局一致性ID

• Snowflake

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

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

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

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

分庫分表

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

分片分區(qū)

多副本冗余

7.5自動化運(yùn)維

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

配置中心

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

• switch

• diamend

部署策略

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

• 停機(jī)部署

• 滾動部署

• 藍(lán)綠部署

• 灰度部署

• A/B測試

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

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

• SchedulerX

• Spring定時任務(wù)

應(yīng)用管理

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

• 應(yīng)用重啟

• 應(yīng)用下線

• 日志清理

7.6容錯處理

既然我們知道分布式系統(tǒng)故障時家常便飯的事情，那么應(yīng)對故障的方案也是不可或缺的環(huán)節(jié)厦瓢。通常我們有主動和被動的方式來處理提揍，主動是在錯誤出現(xiàn)的時候，我們試圖再試試幾次煮仇，說不定就成功了劳跃，成功的話就可以避免了該次錯誤。被動方式是錯誤的事情已經(jīng)發(fā)生了欺抗，為了挽回，我們只是做時候處理强重，把負(fù)面影響降到最小绞呈。

重試設(shè)計

重試設(shè)計的關(guān)鍵在于設(shè)計好重試的時間和次數(shù)，如果超過重試次數(shù)间景，或是一段時間佃声，那么重試就沒有意義了。開源的項目 spring-retry可以很好的實(shí)現(xiàn)我們重試的計劃倘要。

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

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

7.7全棧監(jiān)控

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

基礎(chǔ)層

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

• CPU蓖乘，IO，內(nèi)存韧骗，線程嘉抒，吞吐

中間件

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

應(yīng)用層

• 性能監(jiān)控

  應(yīng)用層面的需要對每個應(yīng)用服務(wù)的實(shí)時指標(biāo)（qps袍暴，rt）些侍，上下游依賴等進(jìn)行監(jiān)控

• 業(yè)務(wù)監(jiān)控

  除了應(yīng)用本身的監(jiān)控程度，業(yè)務(wù)監(jiān)控也是保證系統(tǒng)正常的一個環(huán)節(jié)政模，通過設(shè)計合理的業(yè)務(wù)規(guī)則岗宣，對異常的情況做報警設(shè)置

監(jiān)控鏈路

• zipkin/eagleeye

• sls

• goc

• Alimonitor

7.8故障恢復(fù)

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

應(yīng)用回滾

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

基線回退

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

版本回滾

整體回滾需要服務(wù)編排，通過大版本號對集群進(jìn)行回滾捕犬。

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

性能優(yōu)化是分布式系統(tǒng)的大專題跷坝，涉及的面非常廣，這塊簡直可以單獨(dú)拿出來做一個系列來講碉碉，本節(jié)就先不展開柴钻。本身我們做服務(wù)治理的過程也是在性能的優(yōu)化過程。

分布式鎖

緩存是解決性能問題的一大利器垢粮，理想情況下顿颅，每個請求不需要額外計算立刻能獲取到結(jié)果返回時最快的。小到CPU的三級緩存，大到分布式緩存粱腻，緩存無處不在庇配，分布式緩存需要解決的就是數(shù)據(jù)的一致性癣籽，這個時候我們引入了分布式鎖的概念仅淑，如何處理分布式鎖的問題將決定我們獲取緩存數(shù)據(jù)的效率。

高并發(fā)

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

異步

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

8.總結(jié)

最后總結(jié)一下嗅虏，如果有可能的話，請嘗試使用單節(jié)點(diǎn)方式而不是分布式系統(tǒng)上沐。分布式系統(tǒng)伴隨著一些失敗的操作皮服，為了處理災(zāi)難性故障，我們使用備份参咙。為了提高可靠性龄广，我們引入了冗余。分布式系統(tǒng)本質(zhì)就是一堆機(jī)器的協(xié)同蕴侧。而我們要做的就是搞出各種手段來然機(jī)器的運(yùn)行達(dá)到預(yù)期择同。這么復(fù)雜的系統(tǒng)，需要了解各個環(huán)節(jié)净宵，各個中間件的接入敲才，是一個非常大的工程。慶幸的是择葡，在微服務(wù)背景下紧武，多數(shù)基礎(chǔ)性的工作已經(jīng)有人幫我們實(shí)現(xiàn)了。前文所描述的分布式架構(gòu)刁岸，在工程實(shí)現(xiàn)了是需要用到分布式三件套(Docker+K8S+Srping Cloud)基本就可以構(gòu)建出來了脏里。

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

image

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

image

最后用一張圖來概括分布式系統(tǒng)的知識體系她我。

image