軟體架構設計：大型網站技術架構與業務架構融合之道

第1部分 什麼是架構

第1章 五花八門的架構師職業 2
1.1 架構師職業分類 2
1.2 架構的分類 2

第2章 架構的道與術 5
2.1 何為道，何為術 5
2.2 道與術的辯證關係 6

第2部分 電腦功底

第3章 語言 10
3.1 層出不窮的程式設計語言 10
3.2 精通一門語言 10

第4章 作業系統 12
4.1 緩衝I/O和直接I/O 12
4.2 記憶體映射檔與零拷貝 14
4.2.1 記憶體映射檔 14
4.2.2 零拷貝 15
4.3 網路I/O模型 17
4.3.1 實現層面的網路I/O模型 17
4.3.2 Reactor模式與Preactor模式 20
4.3.3 select、epoll的LT與ET 20
4.3.4 伺服器程式設計的1 N M模型 22
4.4 進程、執行緒和協程 24
4.5 無鎖（記憶體屏障與CAS） 27
4.5.1 記憶體屏障 27
4.5.2 CAS 30

第5章 網路 31
5.1 HTTP 1.0 31
5.1.1 HTTP 1.0的問題 31
5.1.2 Keep-Alive機制與Content-Length屬性 31
5.2 HTTP 1.1 32
5.2.1 連接複用與Chunk機制 32
5.2.2 Pipeline與Head-of-line Blocking問題 33
5.2.3 HTTP/2出現之前的性能提升方法 34
5.2.4 “一來多回”問題 35
5.2.5 中斷點續傳 36
5.3 HTTP/2 36
5.3.1 與HTTP 1.1的相容 37
5.3.2 二進位分幀 37
5.3.3 頭部壓縮 39
5.4 SSL/TLS 39
5.4.1 背景 39
5.4.2 對稱加密的問題 40
5.4.3 雙向非對稱加密 41
5.4.4 單向非對稱加密 42
5.4.5 中間人攻擊 43
5.4.6 數位憑證與證書認證中心 44
5.4.7 根證書與CA信任鏈 45
5.4.8 SSL/TLS協議：四次握手 47
5.5 HTTPS 48
5.6 TCP/UDP 49
5.6.1 可靠與不可靠 49
5.6.2 TCP的“假”連接（狀態機） 51
5.6.3 三次握手（網路2將軍問題） 53
5.6.4 四次揮手 54
5.7 QUIC 56
5.7.1 不丟包（Raid5演算法和Raid6演算法） 57
5.7.2 更少的RTT 58
5.7.3 連接遷移 58

第6章 資料庫 59
6.1 范式與反範式 59
6.2 分庫分表 59
6.2.1 為什麼要分 60
6.2.2 分散式ID生成服務 60
6.2.3 拆分維度的選擇 60
6.2.4 Join查詢問題 61
6.2.5 分散式事務 61
6.3 B 樹 62
6.3.1 B 樹邏輯結構 62
6.3.2 B 樹物理結構 63
6.3.3 非主鍵索引 65
6.4 事務與鎖 66
6.4.1 事務的四個隔離級別 66
6.4.2 悲觀鎖和樂觀鎖 67
6.4.3 鎖死檢測 71
6.5 事務實現原理之1：Redo Log 72
6.5.1 Write-Ahead 73
6.5.2 Redo Log的邏輯與物理結構 74
6.5.3 Physiological Logging 75
6.5.4 I/O寫入的原子性（Double Write） 76
6.5.5 Redo Log Block結構 77
6.5.6 事務、LSN與Log Block的關係 78
6.5.7 事務Rollback與崩潰恢復（ARIES演算法） 80
6.6 事務實現原理之2：Undo Log 86
6.6.1 Undo Log是否一定需要 86
6.6.2 Undo Log（MVCC） 88
6.6.3 Undo Log不是Log 89
6.6.4 Undo Log與Redo Log的關聯 90
6.6.4 各種鎖 91
6.7 Binlog與主從複製 94
6.7.1 Binlog與Redo Log的主要差異 94
6.7.2 內部XA ?C Binlog與Redo Log一致性問題 95
6.7.3 三種主從複製方式 96
6.7.3 並行複製 97
第7章 框架、軟體與中介軟體 99
7.1 對生態體系的認知 99
7.2 框架 99
7.3 軟體與中介軟體 100

第3部分 技術架構之道

第8章 高併發問題 104
8.1 問題分類 104
8.1.1 側重于“高併發讀”的系統 104
8.1.2 側重于“高併發寫”的系統 105
8.1.3 同時側重于“高併發讀”和“高併發寫”的系統 106
8.2 高併發讀 108
8.2.1 策略1：加緩存 108
8.2.2 策略2：併發讀 109
8.2.3 策略3：重寫輕讀 110
8.2.4 總結：讀寫分離（CQRS架構） 113
8.3 高併發寫 114
8.3.1 策略1：數據分片 114
8.3.2 策略2：任務分片 115
8.3.3 策略3：非同步化 117
8.3.4 策略4：批量 123
8.3.5 策略5：序列化 多進程單執行緒 非同步I/O 124
8.4 容量規劃 125
8.4.1 輸送量、回應時間與併發數 125
8.4.2 壓力測試與容量評估 127

第9章 高可用與穩定性 129
9.1 多副本 129
9.2 隔離、限流、熔斷和降級 130
9.3 灰度發佈與回滾 135
9.4 監控體系與日誌報警 136

第10章 事務一致性 138
10.1 隨處可見的分散式事務問題 138
10.2 分散式事務解決方案匯總 139
10.2.1 2PC 139
10.2.2 最終一致性（消息中介軟體） 141
10.2.3 TCC 145
10.2.4 事務狀態表 調用方重試 接收方冪等 147
10.2.5 對賬 148
10.2.6 妥協方案：弱一致性 基於狀態的補償 149
10.2.7 妥協方案：重試 回滾 報警 人工修復 151
10.2.8 總結 152

第11章 多副本一致性 153
11.1 高可用且強一致性到底有多難 153
11.1.1 Kafka的消息丟失問題 153
11.1.2 Kafka消息錯亂問題 156
11.2 Paxos演算法解析 158
11.2.1 Paxos解決什麼問題 158
11.2.2 複製狀態機 161
11.2.3 一個樸素而深刻的思想 163
11.2.4 Basic Paxos演算法 164
11.2.5 Multi Paxos演算法 167
11.3 Raft演算法解析 169
11.3.1 為“可理解性”而設計 169
11.3.2 單點寫入 170
11.3.3 日誌結構 171
11.3.4 階段1：Leader選舉 174
11.3.5 階段2：日誌複製 176
11.3.6 階段3：恢復階段 177
11.3.7 安全性保證 177
11.4 Zab演算法解析 180
11.4.1 Replicated State Machine vs. Primary-Backup System 180
11.4.2 zxid 182
11.4.3 “序”：亂序提交 vs. 順序提交 182
11.4.4 Leader選舉：FLE演算法 184
11.4.5 正常階段：2階段提交 186
11.4.6 恢復階段 186
11.5 三種演算法對比 187

第12章 CAP理論 189
12.1 CAP理論的誤解 189
12.2 現實世界不存在“強一致性”（PACELC理論） 190
12.3 典型案例：分散式鎖 192

第4部分 業務架構之道

第13章 業務意識 196
13.1 產品經理vs.需求分析師 196
13.2 什麼叫作一個“業務” 198
13.3 “業務架構”的雙重含義 199
13.4 “業務架構”與“技術架構”的區分 200

第14章 業務架構思維 202
14.1 “偽”分層 202
14.2 邊界思維 204
14.3 系統化思維 205
14.4 利益相關者分析 206
14.5 非功能性需求分析（以終為始） 208
14.6 視角（橫看成嶺側成峰） 209
14.7 抽象 210
14.8 建模 213
14.9 正交分解 215

第15章 技術架構與業務架構的融合 218
15.1 各式各樣的方法論 218
15.2 為什麼要“領域驅動” 218
15.3 “業務流程”不等於“系統流程” 221
15.4 為何很難設計一個好的領域模型 222
15.5 領域驅動設計與微服務架構的“合” 223
15.6 領域驅動設計與讀寫分離（CQRS） 224
15.7 業務分層架構模式 225
15.8 管道—篩檢程式架構模式 226
15.9 狀態機架構模式 226
15.10 業務切面/業務閉環架構模式 228

第5部分 從架構到技術管理

第16章 個人素質的提升 232
16.1 能力模型 232
16.2 影響力的塑造 234

第17章 團隊能力的提升 237
17.1 不確定性與風險把控 237
17.2 以價值為中心的管理 239
17.3 團隊培養 241

當我在撰寫本書時，腦海中曾浮現出當初上學期間一個勁兒地啃UML建模、軟體架構設計書籍的情景。對於一個沒有太多項目經驗的人來說有點可笑，但也正是這種“過早薰陶”，使得我之後在工作中接手一個個項目時，會“多想”一些架構方面的事情。

為什麼說是“多想”了呢？因為無論在企業面試還是日常工作中，人們更多談論的是語言、資料結構、演算法、作業系統原理，框架或中介軟體的使用方式、原理等“硬”性的內容，因為這些“硬”性的內容比較容易表述，其中學問的深淺也容易衡量。而對於軟體建模、架構設計等“軟”性的內容，就不容易衡量了。人們都知道它們很重要，但又說不清楚裡面到底包含了哪些學問，所以談論這些內容時通常都比較“虛”，最終導致很少從方法論的角度去講，而是在專案中遇到問題時再具體解決，屬於實用主義思維的做法。

另一方面，隨著互聯網技術的發展，很多大型網站或系統要處理海量的使用者訪問，需要解決高併發、高可用和由此帶來的資料一致性問題，這也使得大家把大部分精力都用在解決這些問題上。這些問題可以被稱為“顯性問題”，因為如果解決不好，會造成系統宕機，使用者體驗受損，給企業帶來嚴重損失，人們能意識到這種問題很重要。解決的思路通常有兩個：第一，利用分散式系統的特性不斷地分拆，把大系統拆小，各個擊破，降低風險；第二，小步快跑，快速反覆運算。

但還有一類問題是“隱性問題”，是指系統的再使用性、可擴展性、可維護性等。因為一個系統由於設計問題導致研發人力的投入和時間成本的增加，往往無法顯性地衡量。也可能並非系統設計得不好，而是業務本身就很複雜，或者各部門之間的溝通協調問題導致開發效率低。即便系統設計得不好，做新功能有沉重的歷史包袱，也能依靠加班加點解決。但其實“隱性問題”比“顯性問題”的影響更大，因為它會讓技術拖累業務，當有新需求的時候，系統無法跟隨業務快速變化。

所以，本書不想偏廢兩者中的任意一個。因為對於一個系統來說，可能既面臨高併發、高可用的技術問題，又面臨複雜的業務問題，所以如何處理兩者的關係，打通技術和業務的任督二脈，是本書想要探討的內容。

架構是一種綜合能力，而不是某一方面的技能。也正因為如此，本書提供的是一個全面的解決方案、方法論、成體系的設計思維。本書從基礎技術談起，之後到高層技術，再到業務、管理，提供一個架構能力的全域視圖，從而詮釋一個架構師的完整能力模型。

具體來說，全書分為5大部分：

第1部分：從行業背景出發，對架構做一個宏觀概述，闡述架構是什麼。

第2部分：電腦功底。功底非常重要，這是做架構的基本門檻。大學的教科書上教的全是功底，但經過多年實踐之後，再回過頭看書本內容，會有新的理解和體會。

第3部分：技術架構。這部分是純技術，講解如何應對高併發、高可用、一致性方面的問題。

第4部分：業務架構。如何從技術延展到業務，如何跳出技術細節抽象思考問題，如何通過業務建模把技術和業務進行融合。

第5部分：從職業發展的角度，從技術延展到管理。建立對公司、商業、團隊管理的一些認知。

對於剛入行的新人，建議從頭看到尾，從而對架構的能力體系有一個全面的認知；對於有經驗的從業者，可以選取自己感興趣的章節閱讀。

由於編寫時間緊張，書中難免存在不足之處，望廣大讀者批評指正。