架構演變實戰：從單體到微服務再到中台（簡體書）

本書從搭建單體架構遇到的瓶頸開始，通過真實案例介紹從單體架構轉型為微服務架構及中臺架構過程中遇到的困難、問題與具體解決方法。全書共計9章，前3章以案例和原理為基礎，介紹微服務的優劣勢及其使用場景；第4～6章描述如何基於單體架構搭建和優化微服務架構；第7～8章介紹如何掌握測試、部署交付流程等軟件工程中的各個關鍵環節和核心要素；第9章講解在多元化業務場景下如何構建中臺架構，以實現通用能力的下沉，從而形成共享服務，達到資源利用率的極大化。

本書適合技術管理者、架構師和有一定開發基礎的技術人員閱讀，尤其適合已進入或即將進入微服務架構和中臺架構領域的相關人員閱讀。希望本書能夠為讀者提供一些技術路在線的啟發和指引，幫助其少走彎路。

潘志偉

某科技公司技術總監，阿裡云MVP、QCon演講嘉賓，擁有十多年的軟件架構設計經驗，擅長分布式架構與微服務架構設計及中臺規劃，目前帶領研發團隊承擔系統的分析、架構設計、實施、演進，以及團隊管理和培訓等工作，有獨到的團隊建設和管理經驗。

——1. 難得的微服務架構技術選型或實施的優秀參考書——

本書以單體架構為開篇，實戰+基礎理論相結合，逐步升級為微服務架構，並優化微服務架構的每個細節，最終升級為中臺架構，整個升級思路講解清晰。

——2. 詳盡剖析微服務實踐細節、問題及解決辦法、參考價值極高——

本書詳盡闡述了架構選型、拆分、實施、優化等微服務落地過程中所遇到的問題和解決辦法，既有整體的理論性指導，又有對Dubbo、Spring Cloud等微服務工具的詳盡解釋。

——3. 相當的誠意之作，無私奉上有針對性、接地氣的架構範式、演進思路及落地策略——

本書的最大特點是貼合業務來談架構，針對不同的業務場景給出了有針對性、接地氣的架構範式、演進思路及落地策略，同時融合了潘老師基於自身實戰經驗的深度總結。

——4. 從實際案例出發，全程貼合案例講解，更貼合現實和工作需求——

本書從一個創業公司由單體架構向微服務架構轉型的實際案例出發，向讀者展示了構建分布式系統的全生命周期。通過翔實的案例剖析、深度的原理講解及實操分享，讀者不僅知其然，更能知其所以然。

——————本書概要——————

如今，各行業都在步入數字化經濟時代，並通過數字化技術與實體經濟深度融合，以現代信息網絡為重要載體，不斷提高傳統產業數字化、智能化的水平，隨之而來的是注冊用戶量、用戶數據等信息也處於井噴式增長趨勢，企業信息系統架構也由單體架構紛紛向分布式架構轉型。但是，大部分企業架構師缺乏分布式架構的設計能力，其潛意識中認為引入目前流行的微服務開發框架就能完成分布式架構的設計。企業架構師對引入分布式架構給整個研發體系帶來的挑戰預估不足，以致產品在開發、測試、上線階段出現前所未有的種種問題，其結果是研發效率和產質量量不升反降，企業的數字化轉型之路異常艱辛。

——————本書結構——————

第1章以企業一次失敗的從單體架構轉型為分布式架構事件為藍本，以真實案例的方式介紹在單體應用遇到性能瓶頸後通過快速優化升級來暫時解決當前問題，以及匆忙轉型微服務架構後最終失敗的原因。

第2章首先通過復盤分析架構轉型失敗的原因，明確企業在轉型為微服務架構前需要先在技術及組織架構上做出改變；其次在服務拆分環節通過介紹多個實用方法來說明如何正確地拆分服務；最後介紹如何利用工具來保障拆分後每個工程結構的一致性，且命名符合規範。

第3章介紹服務治理的概念，並結合常用的RPC框架，以Dubbo為例，從原理開始，到核心代碼分析，最後結合實際案例介紹在項目中如何使用該框架。

第4章、第5章重點介紹如何將單體應用一步一步地轉型為微服務架構。例如，如何將單體項目平滑遷移到微服務架構並實現流量無損上線，在架構升級過程中如何使用多級緩存、消息隊列、並行調用機制、熔斷與降級等技術手段來保障接口的高並發和低延遲特性。

第6章介紹微服務的統一入口API網關，從零開始介紹如何搭建高性能API網關。API網關在微服務架構中起著至關重要的作用，本章介紹如何採用異步模式來提高API網關的吞吐量，並集成熔斷與降級功能來實現API資源隔離及接口的高可用。

第7章介紹對微服務架構下的企業應用該如何高效地測試。通過講述測試模型的迭代過程來引出契約測試平臺的需求，並介紹如何搭建滿足要求的契約測試平臺。為了提高系統的穩定性，簡單的業務功能測試肯定不能滿足要求。因此，在最後的測試環節又引入了混沌實驗來模擬各種異常場景。

第8章介紹比較容易被忽視的系統容量預估和服務上線的流程。在面向終端用戶的互聯網產品上線後，通常應盡可能地避免產生在線問題。本章介紹如何在產品發布環節引入灰度發布機制來提前發現和解決問題，在容量預估環節採用了目前比較成熟的全鏈路壓測方案來預估在線系統的實際處理能力。

第9章介紹企業在面臨多業務線同時運營時，如何把業務線中共性、可復用的能力下沉，形成通用能力來給外部系統調用，減少重復造輪子的工作。本章以實際案例為出發點，講解如何自頂向下地創建業務中臺，包括如何識別共性需求、如何創建中臺團隊等。萬事有利必有弊，中臺的確對具備多業務線的企業有利，但是弊端也很明顯。本章最後講解了企業在推行中臺建設過程中存在的弊端。

希望讀者能通過本書快速地對微服務架構所涉及的方方面面有一個基本認識，理解其優點和不足，並進一步試用和評估。

——————本書讀者物件——————

本書適合技術管理者、架構師和有一定開發基礎的技術人員閱讀，尤其適合已進入或即將進入微服務架構和中臺架構領域的相關人員閱讀。希望本書能夠為讀者提供一些技術路在線的啟發和指引，幫助其少走彎路。

——————致 謝——————

本書的寫作持續了兩年多，基本上是利用平時的晚間，以及包括周末在內的節假日進行的。在此感謝我的家人，是他們所給予的包容和全力支持讓我得以專心寫作。

感謝博文視點的蝦米編輯（張國霞）、李云靜編輯和相關工作人員為本書的出版所付出的努力。

》》》第1章 從單體架構開始 1《《《

1.1 單體應用優化之路 2

1.1.1 應用無狀態 3

1.1.2 數據讀/寫分離 4

1.1.3 分庫分表 5

1.2 比性能更可怕的問題 7

1.3 微服務框架選型 8

1.3.1 總體架構對比 9

1.3.2 編程方式對比 10

1.4 第一次失敗的微服務重構 10

》》》第２章 服務拆分與工程劃分 14《《《

2.1 實施微服務架構的前置條件 15

2.1.1 思想統一 15

2.1.2 充分培訓 16

2.1.3 標準化的工程 17

2.1.4 自動化部署 18

2.2 服務拆分的角度和原則 19

2.2.1 服務拆分的角度 20

2.2.2 服務拆分的原則 21

2.3 服務拆分案例剖析 23

2.4 項目框架自動化 26

2.5 微服務的數據請求模型 31

2.6 日志收集和控制 33

》》》第3章 微服務模式開發 39《《《

3.1 服務治理的核心概念 40

3.1.1 分布式系統 40

3.1.2 RPC框架 43

3.1.3 服務治理 44

3.2 注冊中心簡介 47

3.2.1 ZooKeeper 47

3.2.2 Nacos 51

3.3 Provider的配置與發布 53

3.4 Consumer的配置 56

3.5 對負載均衡策略的選擇 58

3.6 Dubbo的常用特性 64

3.6.1 服務的多版本管理 65

3.6.2 上下文信息 66

3.6.3 隱式傳參 67

3.7 SPI原理介紹 67

3.7.1 Java SPI的執行流程 68

3.7.2 Dubbo SPI的執行流程 70

3.7.3 Dubbo SPI原理解析 74

3.8 Filter的擴展使用場景 77

3.8.1 Dubbo Filter的執行過程 77

3.8.2 Dubbo Filter的使用場景 81

3.9 Dubbo服務發布和調用分析 85

3.9.1 標簽解析 87

3.9.2 服務注冊和發布流程 88

3.9.3 服務引用流程和服務調用流程 91

》》》第4章 實施微服務架構的全過程 94《《《

4.1 前後端分離 95

4.2 服務無狀態化 96

4.3 統一認證服務 97

4.3.1 令牌方式 98

4.3.2 JWT方式 100

4.4 微服務設計模式 105

4.5 微服務實戰詳解 106

4.5.1 需求背景 107

4.5.2 技術選型 108

4.5.3 設計數據庫表 110

4.5.4 代碼結構模型 114

4.5.5 服務發布上線 120

4.6 在線問題及解決方案 122

4.6.1 服務線程池滿 122

4.6.2 數據庫的CPU占用率飆高 124

4.6.3 無止境的循環依賴 125

》》》第5章 微服務進階優化 126《《《

5.1 緩存分類 127

5.1.1 CDN緩存 128

5.1.2 本地緩存 129

5.1.3 分布式緩存 135

5.2 微服務緩存優化 137

5.2.1 單級緩存 137

5.2.2 多級緩存 138

5.2.3 緩存管理策略 140

5.3 串行轉並行 144

5.3.1 串行、並行的概念 144

5.3.2 將串行調用轉為並行調用的方法 145

5.3.3 案例實戰 147

5.4 服務的熔斷與降級 150

5.4.1 熔斷器的工作原理 150

5.4.2 服務降級的原理 152

5.4.3 Hystrix詳解 153

5.4.4 Sentinel詳解 158

5.4.5 熔斷器與Dubbo的集成 165

5.4.6 狀態監控 168

5.5 限流 170

5.5.1 限流算法 170

5.5.2 如何進行限流 171

5.5.3 單機限流 171

5.5.4 分布式限流 172

5.5.5 混合限流 174

5.6 接口的冪等性 174

5.6.1 為什麼需要冪等性 175

5.6.2 如何保證接口的冪等性 175

5.6.3 冪等實戰 179

5.7 配置中心 180

5.7.1 常見的配置方式 180

5.7.2 配置中心概述 181

5.7.3 案例實戰 182

5.7.4 案例說明 183

5.8 消息隊列 183

5.8.1 為什麼使用消息隊列 183

5.8.2 消息隊列的使用場景 185

5.9 分布式事務 189

5.9.1 事務的特性 189

5.9.2 分布式事務方案 191

》》》第6章 億級流量網關開發實戰 200《《《

6.1 為什麼使用網關 201

6.1.1 網關的職責和工作原理 202

6.1.2 核心功能 203

6.2 網關的高可用性設計 207

6.2.1 高可用性的衡量標準 207

6.2.2 影響系統高可用性的因素 209

6.2.3 提升系統可用性的常用方法 209

6.3 從零開始自研高性能異步網關 211

6.3.1 API協議的制定 211

6.3.2 API的注冊與發布 211

6.3.3 異步化請求 215

6.3.4 泛化調用 220

6.3.5 功能插件化 223

6.3.6 請求快照 226

6.3.7 API生命周期 227

6.4 網關優化 228

6.4.1 資源隔離 228

6.4.2 業務線程分離 230

6.4.3 Epoll加速 231

6.4.4 高速緩存 232

6.4.5 自恢復能力 234

6.5 自研網關所遇到的難題 234

6.5.1 網關找不到服務提供者 235

6.5.2 多餘的class字段 236

6.5.3 錯誤傳值 236

6.5.4 日期格式異常 237

6.5.5 自定義異常失效 238

6.5.6 源碼修改如何集成 239

》》》第7章 微服務之服務測試的演進 242《《《

7.1 測試模型的演進 243

7.1.1 倒三角測試模型 243

7.1.2 金字塔測試模型 244

7.1.3 橄欖球測試模型 245

7.1.4 契約測試模型 246

7.2 微服務架構的測試流程 247

7.2.1 測試策略 247

7.2.2 單元測試 249

7.2.3 API測試 252

7.2.4 服務框架測試 254

7.3 構建契約測試平臺 255

7.3.1 測試面臨的阻礙 255

7.3.2 契約測試的核心思想 258

7.3.3 自研契約測試平臺 260

7.3.4 數據采集流程 264

7.3.5 契約測試的核心代碼 269

7.3.6 契約驗證流程 277

7.4 混沌工程 280

7.4.1 理解混沌工程 281

7.4.2 如何實施混沌實驗 283

7.4.3 CPU滿載實驗 284

7.4.4 磁盤寫滿實驗 285

7.4.5 內存負載實驗 286

7.4.6 數據庫調用延時實驗 286

7.4.7 Redis調用延時實驗 287

7.4.8 Dubbo服務延時實驗 288

7.4.9 Dubbo線程池滿實驗 289

7.4.10 混沌實驗的可視化 290

》》》第8章 容量預估與服務上線 291《《《

8.1 持續集成和持續交付 292

8.1.1 為什麼需要持續集成和持續交付 292

8.1.2 持續集成和持續交付的流程 296

8.1.3 搭建持續集成平臺 301

8.1.4 持續集成項目實戰 324

8.2 灰度發布 337

8.2.1 灰度發布介紹 338

8.2.2 灰度發布的流程 340

8.2.3 灰度發布實戰 343

8.3 搭建全鏈路壓測平臺 348

8.3.1 實施全鏈路壓測的原則 349

8.3.2 流量染色與數據隔離 351

8.3.3 如何生成壓測流量 353

8.3.4 全鏈路壓測實戰 355

8.4 生產環境容量預估 367

8.4.1 容量預估的參考指標 368

8.4.2 硬件選型 370

8.4.3 容量預估實戰 371

》》》第9章 中臺架構設計 376《《《

9.1 什麼是中臺 377

9.1.1 研發亂象 377

9.1.2 中臺的定義 379

9.1.3 中臺的分類 380

9.1.4 企業是否需要中臺 381

9.1.5 中臺對企業的價值 382

9.2 業務中臺的搭建步驟 382

9.2.1 高管的介入決定成敗 382

9.2.2 獨立中臺的產品經理 385

9.2.3 獨立中臺的技術團隊 389

9.2.4 需求邊界管理 390

9.2.5 業務中臺的架構設計 391

9.3 業務中臺實戰 392

9.3.1 需求分析 393

9.3.2 架構實現 395

9.3.3 業務流程 396

9.3.4 業務線接入 399

9.4 中臺的績效考核標準 401

9.5 中臺的弊端 403

9.5.1 不同業務線的需求不具備共性 403

9.5.2 需求的優先級被降低 403

9.5.3 項目組溝通難 404

9.5.4 業務線被動升級 405

9.6 實戰總結 406

推薦序

與潘老師相識多年，曾聽他飽含真情地分享設計經驗，如今喜聞其大作即將面世，又得作序之邀，榮幸之至。

軟件工程系統的構建殊非易事，項目多毀於溝通。敏捷項目人士常說“團隊規模最好符合‘兩個比薩餅’原則”，想必他們受夠了溝通之苦。但是，並沒有方法能夠很好地規避這一難題。尤其是隨著企業的成長，各種問題會日益突出。這些問題反映到架構上，就是如何遵循一定的原則處理結構和關係，盡管這些原則極有可能並非“一定”要遵循。這些原則需要團隊、企業自己逐漸磨合、領悟，這也是企業自己逐漸形成方法論、形成架構觀的過程。本書正反映了這樣的過程。

經驗學習並非都來自成功案例，更重要的是對失敗的總結：避免重復犯錯才是成功的開始。本書第1章就將一次“翻車”的微服務改造案例生動地呈現給讀者，這是最好的代入方式。畢竟，所有的架構學習就像學習騎自行車一樣，肯定是從“摔跟頭”學起的。從“摔跟頭”中找到平衡感，才是逐漸習得服務劃分、規範設計的路徑，才是架構師逐漸知道何以自處，以及整個團隊知道架構應當何以處之的過程。

本書基於潘老師自己的經驗，對中臺架構及其實現做了很客觀的闡述，利弊解釋都頗富“實感”。沒有完美的架構，也沒有完美的方法，顧“此”極有可能失“彼”，這也再度驗證了很多人對架構的看法。架構即平衡之道，架構即取舍之道。架構理論有共性，架構實施則充滿個性，需要在實施中時刻提醒自己，在別人的經驗和自己的環境中做好取舍，在別人的能力和自己的限制之間做好平衡。不然，本書第1章的“翻車”事故，就有可能在你實踐本書第9章的設計時重現。大的成功不是很容易復現，大的失敗卻很容易再臨。

——《企業級業務架構設計：方法論與實踐》《聚合架構：面向數字生態的構件化企業架構》作者 付曉巖