《從零開始學(xué)架構(gòu)》讀書筆記(下)
書接上文
思維導(dǎo)圖
高可用架構(gòu)模式
高可用的理論
CAP
在一個分布式系統(tǒng)（指互相連接并共享數(shù)據(jù)的節(jié)點的集合）中，當(dāng)涉及到讀寫操作時，只能保證
一致性（Consistence）、可用性（Availability）、分區(qū)容錯性（Partition Tolerance）三者中的兩個，另外一個必須被犧牲
一致性
對某個指定的客戶端來說，讀操作保證能夠返回最新的寫操作數(shù)據(jù)
可用性
非故障的節(jié)點在合理的時間內(nèi)返回合理的響應(yīng)（不是錯誤和超時的響應(yīng)）
分區(qū)容忍性
當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)(發(fā)生丟包、連接中斷、擁塞等)后，系統(tǒng)能夠繼續(xù)按預(yù)期工作
CAP為什么只能選兩個
首先，你肯定是要選P分區(qū)容忍性的，因為網(wǎng)絡(luò)本身是無法100%可靠的，所以分區(qū)是必然的，你也不想網(wǎng)絡(luò)一點抖動你系統(tǒng)就掛了吧。如果不選分區(qū)容忍性，那么發(fā)生分區(qū)時，為了保障一致性，系統(tǒng)要禁止寫操作，當(dāng)發(fā)生寫操作時返回err,這又和可用性沖突了，所以理論上你必須選P分區(qū)容忍性。
CP一致性+分區(qū)容忍性：前面說了，當(dāng)發(fā)生分區(qū)時，為了保障一致性，要禁止寫操作返回err,所以這時候可用性是不能被滿足的，所說CAP只能滿足CP。
AP可用性+分區(qū)容忍性：為了保障可用性，發(fā)生分區(qū)時，底層數(shù)據(jù)無法同步，必然造成數(shù)據(jù)的不一致，這時系統(tǒng)還要對外提供服務(wù)，所以CAP只能滿足AP。
CAP還有一些細(xì)節(jié)需要注意。
- CAP關(guān)注的粒度是數(shù)據(jù)，而不是整個系統(tǒng)
- CAP是忽略網(wǎng)絡(luò)延遲的，這就意味著
一致性是不可能完美實現(xiàn)的 - 正常情況下，可以同時滿足CA。分區(qū)不存在的時候
可用性和一致性是可以同時被滿足的 - 分區(qū)恢復(fù)后，需要為數(shù)據(jù)的同步做準(zhǔn)備
ACID
ACID是數(shù)據(jù)庫管理系統(tǒng)為了保證事務(wù)的正確性而提出來的一個理論，包含四個約束：
- 原子性(Atomicity): 一個事務(wù)中所有操作，要么全部完成，要么全部不完成，沒有中間狀態(tài)
- 一致性(Consistency): 在事務(wù)開始之前和事務(wù)結(jié)束之后，數(shù)據(jù)庫的完整性沒有被破壞
- 隔離性(isolation):允許多個并發(fā)事務(wù)同時執(zhí)行
- 持久性(durability): 事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即使系統(tǒng)故障也不會丟失
BASE
BASE是指基本可用(Basically Available)、軟狀態(tài)(Soft State)、最終一致性(Eventual Consistency)。其核心思想是即使無法做到強(qiáng)一致性，但可以采用合適的方式達(dá)到最終一致性?，F(xiàn)實中很多系統(tǒng)大多都是采用的最終一致性，強(qiáng)一致性常見于金融業(yè)務(wù)。
- 基本可用：在系統(tǒng)出現(xiàn)故障時，允許損失部分可用性，保證核心業(yè)務(wù)可用就行，影響范圍盡可能小
- 軟狀態(tài)：也就是短時間的數(shù)據(jù)不一致
- 最終一致性：所有數(shù)據(jù)副本經(jīng)過一段時間后，最終能夠達(dá)到一致的狀態(tài)
FMEA
FMEA（故障模式與影響分析）又稱為失效模式與后果分析等，是一套分析和思考的方法。具體分析方法如下：
- 給出初始的架構(gòu)設(shè)計圖
- 假設(shè)架構(gòu)中的某個部件發(fā)生故障
- 分析此故障對系統(tǒng)功能造成的影響
- 根據(jù)分析結(jié)果，判斷架構(gòu)是否需要進(jìn)行優(yōu)化
此方法輸出的是一份表格，包含功能點、故障模式、故障影響、嚴(yán)重程度、故障原因、故障概率、風(fēng)險程度、已有措施、解決措施和后續(xù)規(guī)劃?？偨Y(jié)來說就是一份分析報告，列出系統(tǒng)的薄弱點，并提出改進(jìn)措施，很可能改進(jìn)之后又會引入新的薄弱點，所以需要不斷更新。除此之外也可以當(dāng)成一份運維手冊來看，當(dāng)發(fā)生故障時看看這份表上有沒有相應(yīng)的補(bǔ)救措施。
存儲高可用
存儲高可用本質(zhì)都是將數(shù)據(jù)復(fù)制到多個節(jié)點，通過冗余來實現(xiàn)高可用。這類方案都要面對的一個問題是復(fù)制延遲和中斷導(dǎo)致的數(shù)據(jù)不一致。任何一個存儲高可用方案，都要想清楚以下幾點：
- 數(shù)據(jù)是怎么復(fù)制的
- 各個數(shù)據(jù)節(jié)點的職責(zé)是什么，是單純備份還是對外提供服務(wù)還是二者兼有
- 如何面對復(fù)制延遲
- 如果面對復(fù)制中斷
主備復(fù)制
主機(jī)對外提供服務(wù)，通過復(fù)制通道將數(shù)據(jù)復(fù)制到備機(jī)，備機(jī)不對外提供服務(wù)。發(fā)生故障時需要將客戶端的請求轉(zhuǎn)到備機(jī)上。
缺點是如果主機(jī)永久掛了，對于復(fù)制延遲和中斷造成的數(shù)據(jù)缺失沒啥好的解決方案。由于備機(jī)不提供服務(wù)，平時會造成資源浪費。
優(yōu)點就是比較簡單，適用于內(nèi)部管理系統(tǒng)。
主從復(fù)制
跟主備復(fù)制類似，但是備機(jī)是可以對外提供讀服務(wù)的。
優(yōu)點就是機(jī)器資源得到有效利用，主機(jī)掛了，讀操作不受影響
缺點就是如果延遲比較高，寫完立即讀可能讀到舊數(shù)據(jù)。也比較復(fù)雜，需要將不同的操作發(fā)給不同的機(jī)器
適應(yīng)于論壇新聞類的業(yè)務(wù)，讀多寫少，影響范圍可以控制
主備倒換和主從倒換
無論是上面哪種模式，發(fā)生故障時都要進(jìn)行角色的轉(zhuǎn)換。需要有狀態(tài)的判斷機(jī)制和倒換策略。例如：
- 狀態(tài)是怎么傳遞的
- 傳遞的內(nèi)容是什么？是心跳？還是包含了當(dāng)前負(fù)載狀態(tài)？
- 什么時候進(jìn)行轉(zhuǎn)換？沒心跳轉(zhuǎn)換？還是延遲高就轉(zhuǎn)換？
- 轉(zhuǎn)換手段是什么？人工or自動？
- 故障節(jié)點恢復(fù)后，數(shù)據(jù)沖突怎么解決？永遠(yuǎn)不恢復(fù)，缺失的數(shù)據(jù)怎么辦？
根據(jù)狀態(tài)傳遞渠道的不同，常見的主備倒換架構(gòu)有三種形式：
- 互連式：主備互聯(lián)。這里操作空間很大，怎么連？單向還是雙向？萬一通道本身出問題，那備機(jī)可就自己決定變成主機(jī)了
- 中介式：主備機(jī)分別向中介機(jī)發(fā)生信息，中介來決定角色。這種模式要簡單很多，但是也要注意中介本身掛了的情況
- 模擬式：備機(jī)假裝成客戶端，向主機(jī)發(fā)請求，請求異常自己升級為主機(jī)。實現(xiàn)比互連簡單，但是僅依靠響應(yīng)信息決策還是有點草率
數(shù)據(jù)集群
當(dāng)一臺節(jié)點存儲不下全部數(shù)據(jù)時，上面的兩種方案就用不了了，就要上數(shù)據(jù)集群了，把數(shù)據(jù)分散到各個節(jié)點上。此方案的復(fù)雜點在于如何將數(shù)據(jù)分配到不同的服務(wù)器上，設(shè)計時需要考慮以下幾點：
- 均衡性：各個節(jié)點的數(shù)據(jù)大小是均衡的
- 容錯性：部分節(jié)點故障時，需要將原來分配給故障節(jié)點的數(shù)據(jù)分區(qū)分配給其他節(jié)點
- 可伸縮性：需要擴(kuò)容時，能夠自動遷移數(shù)據(jù)
既然數(shù)據(jù)分散到各個節(jié)點，那避免不了的問題就是分布式事務(wù)。目前分布式事務(wù)算法非常多，但再多的算法也不能徹底解決問題，極端情況下還得看人工。目前常用的分布式事務(wù)算法有：
- 2PC: 二階段提交。分為請求階段和提交階段。缺點比較明顯，存在同步阻塞、狀態(tài)不一致和單點故障問題
- 3PC: 三節(jié)點提交。分為提交判斷、準(zhǔn)備提交和提交執(zhí)行三個階段。解決了單點故障導(dǎo)致的系統(tǒng)阻塞問題，但還是沒解決數(shù)據(jù)不一致問題。
- 消息表：把各個節(jié)點的執(zhí)行情況記錄到一張表里，協(xié)調(diào)者掛了之后新的協(xié)調(diào)者根據(jù)表信息再決定怎么操作，比較復(fù)雜。
數(shù)據(jù)分區(qū)
數(shù)據(jù)分區(qū)是指將數(shù)據(jù)按照一定的規(guī)則進(jìn)行分區(qū)，不同分區(qū)分布到不同的地理位置上，每個分區(qū)存儲一部分?jǐn)?shù)據(jù)，通過這種方式來規(guī)避地理級別的故障。分區(qū)規(guī)則有很多，你可以選城市分區(qū)、國家分區(qū)、洲際分區(qū)等，一般看業(yè)務(wù)量決定。同時，即使是數(shù)據(jù)分區(qū)，也要考慮分區(qū)數(shù)據(jù)的備份，萬一真發(fā)生地理級別的故障，還是要盡可能將數(shù)據(jù)恢復(fù)。一般有以下幾種備份規(guī)則：
- 集中式：所有分區(qū)備份到一個總的數(shù)據(jù)中心。簡單是簡單，但是總的數(shù)據(jù)中心一旦掛掉，也挺頭疼。
- 互備式：各個數(shù)據(jù)分區(qū)互相備份。穩(wěn)定性大大上升，但是拓展性很差，后續(xù)增加一個新分區(qū)，是放到哪里備份呢？
- 獨立式：各個數(shù)據(jù)分區(qū)有自己的數(shù)據(jù)中心。終極解決方式，但是成本非常高。
計算高可用
計算高可用的主要目的是當(dāng)部分節(jié)點故障時，服務(wù)依然能正常對外提供服務(wù)。因此和存儲高可用的思路是一致的，就是通過冗余來規(guī)避風(fēng)險。這里復(fù)雜度主要體現(xiàn)在任務(wù)管理方便，即怎么分發(fā)任務(wù)和任務(wù)執(zhí)行失敗后怎么處理的問題。架構(gòu)一般由任務(wù)分配器+計算節(jié)點組成。
常見的計算高可用架構(gòu)：
- 主備：備機(jī)平時不干活，主機(jī)故障時開始干活。簡單但是故障時需要人工操作，也浪費一定的資源
- 主從：備機(jī)平時也干活。缺點是任務(wù)分配器會復(fù)雜一些
- 對稱集群：目前最常見的負(fù)載均衡集群方案。各個計算節(jié)點沒有角色區(qū)別，通過分配器均衡任務(wù)。
- 非對稱集群：計算節(jié)點區(qū)分角色，不同角色執(zhí)行不同任務(wù)，比較少見。
業(yè)務(wù)高可用
業(yè)務(wù)高可用主要實現(xiàn)方式就是異地多活，異地多活又分同城異區(qū)、跨城異地、跨國異地，具體采用哪種方案需要根據(jù)業(yè)務(wù)量級以及業(yè)務(wù)重要程度來選擇。另外，核心業(yè)務(wù)內(nèi)部也分核心數(shù)據(jù)和非核心數(shù)據(jù)，所以在選擇方案是也可以根據(jù)數(shù)據(jù)重要程度進(jìn)行進(jìn)一步劃分。
在發(fā)生業(yè)務(wù)故障時，要使用日志記錄并做好用戶的補(bǔ)償，降低影響范圍和輿論影響程度。
另外針對接口級別的故障，平時發(fā)生的概率比較高，我們一般有以下幾種應(yīng)對方案
- 降級：將某些業(yè)務(wù)或接口的功能降低，指提供部分功能或完全不提供功能。例如APP的頁面數(shù)據(jù)，可以只提供核心模塊的數(shù)據(jù)。
- 熔斷：一般是指依賴的下游故障。熔斷需要有應(yīng)對方案，例如熔斷后返回緩存數(shù)據(jù)等等
- 限流：限流是從用戶訪問壓力的角度來應(yīng)對。在上線服務(wù)時，要設(shè)置請求的閾值，超過這個閾值的請求可以被丟棄，避免機(jī)器負(fù)載過高影響所有用戶
可拓展架構(gòu)
可拓展架構(gòu)的主要價值在于后續(xù)改動時，能盡量降低開發(fā)成本，降低改動范圍。一般來說，設(shè)計方法有很多，但核心思想就是拆分，怎么拆各有各的說法，你可以面向流程拆分，也可以面向服務(wù)拆分，也可以面向功能拆分。
分層架構(gòu)
這是非常常見的架構(gòu)模式，例如C/S架構(gòu)、B/S架構(gòu)、MVC架構(gòu)等等。平常設(shè)計時也會習(xí)慣性進(jìn)行分層，進(jìn)行邏輯的劃分，降低整體的復(fù)雜度。劃分的原則也很簡單，就是要保證各層之間的差異足夠清晰，邊界足夠明顯，可讀性高。
但有個缺點就是可能會發(fā)生冗余，有時候你只需要調(diào)用最底層的一個接口就好，但是為了維持這個分層架構(gòu)，不得不層次傳遞，如果各層之間是網(wǎng)絡(luò)連接，那網(wǎng)絡(luò)耗時將會大大增加。
SOA架構(gòu)
SOA是面向服務(wù)的架構(gòu)，現(xiàn)在在傳統(tǒng)大企業(yè)里面可能比較容易見到。提出的背景是企業(yè)內(nèi)部的IT系統(tǒng)重復(fù)建設(shè)且效率低下。例如企業(yè)里面有很多獨立的系統(tǒng)，財務(wù)系統(tǒng)、銷售系統(tǒng)、HR系統(tǒng)等等，這些系統(tǒng)都需要進(jìn)行員工的權(quán)限管理，也許都要重復(fù)開發(fā)該能力。
SOA主要有三個概念：
- 服務(wù)：所有業(yè)務(wù)功能都是一項服務(wù)，服務(wù)需要對外提供能力，其他系統(tǒng)需要這些能力時，無需重復(fù)開發(fā)
- ESB：因為各個服務(wù)之間是異構(gòu)的，所以需要ESB來屏蔽各個系統(tǒng)對外提供各種不同的接口方式
- 松耦合：目的是減少各個服務(wù)間的依賴和互相影響
SOA的瓶頸就在ESB上，因為所有服務(wù)都要通過它來進(jìn)行通信。
微服務(wù)
微服務(wù)是大家耳熟能詳?shù)睦匣镉嬃耍趪鴥?nèi)的互聯(lián)網(wǎng)公司，稍微大一點的業(yè)務(wù)都會采用微服務(wù)架構(gòu)。微服務(wù)很容易和SOA混淆，主要區(qū)別在于服務(wù)粒度不同(SOA粒度比較粗)、服務(wù)通信(SOA使用ESB通信，兼容不同協(xié)議，微服務(wù)的通信協(xié)議是一致的，簡單很多)、服務(wù)交付(微服務(wù)的交付成本先易后難，微服務(wù)越多，越需要更強(qiáng)的管理手段)、應(yīng)用場景(SOA適用于改動成本高的企業(yè)級系統(tǒng)，微服務(wù)適用于快速迭代的互聯(lián)網(wǎng)系統(tǒng))。
采用微服務(wù)架構(gòu)，開發(fā)基建一定要跟上，因為隨著微服務(wù)越來越多，怎么做服務(wù)發(fā)現(xiàn)，怎么做服務(wù)路由，怎么自動部署，怎么排查問題就是實實在在要面對的問題。
那么，微服務(wù)要怎么拆分呢，基于什么原則進(jìn)行拆分？
首先有一個“三個火槍手原則”:
三個火槍手原則：一個微服務(wù)三個人負(fù)責(zé)開發(fā)
具體的拆分方法有，可以根據(jù)自己的業(yè)務(wù)特點進(jìn)行選擇：
- 基于業(yè)務(wù)邏輯拆分
- 基于可拓展性拆分
- 基于可靠性拆分
- 基于性能拆分
關(guān)于微服務(wù)有很多其他經(jīng)典的書籍可以學(xué)習(xí)，后續(xù)可以展開寫寫。
微內(nèi)核
就是插件式架構(gòu)，關(guān)鍵技術(shù)有：插件管理、插件連接和插件通信。
應(yīng)用場景有很多，例如促銷規(guī)則生成系統(tǒng)，內(nèi)核就是一個計算邏輯，但是很多商品種類可以封裝成插件，新增規(guī)則時開發(fā)成很低。
互聯(lián)網(wǎng)架構(gòu)模板
一張圖就可以說明了，內(nèi)容深度不大。
架構(gòu)的重構(gòu)
前面我們介紹架構(gòu)設(shè)計原則的時候，有一條原則就是“演化原則”。
演化優(yōu)于一步到位
現(xiàn)在就是演化的時候了。在演化時，我們要注意：
- 識別當(dāng)前的主要矛盾
- 換位思考推送項目，你得讓對方有利可圖，才會配合你演化
- 分階段演化
讀后感
讀完收益良多，以前總是覺得架構(gòu)挺神秘的，奈何沒有一個系統(tǒng)的教程入門，網(wǎng)上資料汗牛充棟，根本無從下手，進(jìn)行系統(tǒng)設(shè)計時腦子都是空白的，沒有頭緒。這本書介紹的挺全面的，很適合掃盲用，適合那些剛接觸架構(gòu)設(shè)計的開發(fā)人員。文章來源：http://www.zghlxwxcb.cn/news/detail-406628.html
后續(xù)可以在這里練練手:系統(tǒng)設(shè)計題文章來源地址http://www.zghlxwxcb.cn/news/detail-406628.html
到了這里，關(guān)于《從零開始學(xué)架構(gòu)》讀書筆記(下)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
