【分享說明】：
我會花很多時間或淺或深的研讀一本書，然後總結一些提煉出來的精華，用簡短的語言，讓其他人能夠用很少的時間大致知道這本書能帶給自己的價值，如果適用自己，鼓勵買一本正本實體書細讀和收藏。
通篇會以原文目錄爲結構，給出提煉內容，如果不重要或者一看目錄就懂的，會保留目錄，有不明白的，以原文學習爲參照。
所有分享內容，爲了區分，會以》開頭，可能有多行縮進，或差異化顏色表示。
【書名】：《分佈式服務框架原理與實踐》李林鋒（華爲PaaS平臺架構師）著
【發行】：2016年
【適用】：分佈式0基礎人員，希望強化實踐的，複雜服務平臺構建者，微服務方向，java更宜，不適用於用c++做定製化創造框架組件方向的（我個人在這個方向上，後文簡單過了一下），更偏基於各種已有組件，構建大型功能集成平臺。
【總結】：
1、書不是很長，章節非常多。前面從宏觀上講了需求目標和大體架構，後文分章節細分和實踐講解。
2、整體架構形態講解的很細緻到位，瞭解全面。
3、後面太長，有重複和冗餘，連續讀心累，最好後面章節邊實踐練習邊研討。
4、讀完之後視野有開拓的感覺，值得回味再讀一遍。
【章節總結】
1章應用框架演變講了從MVC、RPC、SOA到微服務框架的演變原因、特性和設計原則，深刻體會一下需求場景，有了框架的宏觀認識。
2章分佈式服務框架入門通過幾個常用的框架的分析，整體的講了分佈式設計的原理和組成組件。
3-9章圍繞各主要組件，詳細的講了設計考慮因素和一些具體實踐。
10-19章圍繞分佈式架構的一些特殊場景，詳細的講了設計考慮因素和一些具體實踐。
20章細節的講了微服務框架。
21章總結了分佈式設計實踐中遇到的一些其他方面的總結。
【正式分享】
第1章應用架構演進1
1.1傳統垂直應用架構2
》LAMP和MVC爲典型
1.1.1垂直應用架構介紹2
》簡單說就是單線，上是訪問入口，最底層是數據存儲
》高負責時，通過上層分流（F5七層負載均衡或SLB）做分流，後面是對等邏輯部署（每個分流完全一致）
1.1.2垂直應用架構面臨的挑戰4
》1複雜應用維護成本高，效率低：一次編譯出錯全部重新打包
》2團隊效率差，公共功能重複開發
》3系統可靠性變差，雪崩效應，一個模塊故障，其他模塊壓力暴增
》4維護和定製困難，代碼量增加導致
》5新功能上線週期變長：測試周期長，功能無法獨立上線
》進化：一些公共功能抽以出來，提供api訪問，跨進程形成rpc調用
1.2RPC架構6
》遠程調用框架
1.2.1RPC框架原理6
》4個核心技術點
1、遠程服務需要以某種形式提供服務調用相關信息
2、遠程代理對象：將本地調用封閉成遠程服務調用
3、通信
4、數據序列化
1.2.2最簡單的RPC框架實現8
1.2.3業界主流RPC框架14
》介紹4在
1、FaceBook開發的ApacheThrift：高效完備，豐富的選擇
2、Hadoop子項目Avro-RPC：良好的定製化支持，傳輸和業務分離
3、caucho提供基於binary-RPC的Hessian：輕量簡單易用
4、google gRPC：高性能通用
1.2.4RPC框架面臨的挑戰17
》負載均衡實現路由，隨着服務增加，單點壓力過大
》需要額外增加一個服務註冊中心，客戶端通過大量緩存路由來降壓
》隨着業務增多，服務關係複雜，啓動順序難以理清
》服用調用增大，質量問題突顯
》服務上線容易下線難
》進化：單純的RPC治理能力都不健全，需要通過服務框架+服務治理解決
1.3SOA服務化架構18
》粗粒度鬆耦合的以服務爲中心的框架
1.3.1面向服務設計的原則18
》
1、服務可複用
2、服務共享一個標準契約
3、服務是鬆耦合的，儘可能不依賴其他
4、服務是底層邏輯的抽象
5、服務是可組合可編排的：多個服務組合成一個新服務
6、服務是自治的，邏輯由服務控制，不依賴其他服務
7、服務是無狀態的
8、服務是可被自動發現
1.3.2服務治理19
》至少7條挑戰
1、分佈式框架下的服務調用性能
2、服務化框架如何支持線性擴展
3、如何實現高效、實時監控
4、大規模分佈式下的故障快速定界和定位
5、分佈下式海量日誌檢索、模糊查詢
6、服務的流控（業務流、事務）、超時控制、服務升降機（增刪設備）
7、服務的劃分原則，如何實現最大程度複用
8、更多……
》SOA的治理
1、服務定義：對服務進行標識，與使用團隊協調確保滿足需求，避免重複工作
2、服務生命週期治理：計劃（未實現）、測試（不服務或有限服務）、運行（服務階段）、棄用（標識棄用，只減不加）、廢棄（下線，從注刪中心移除或標記移除）
3、服務版本治理
4、服務註冊中心
5、服務監控
6、運行期質量保證：限流、遷入和遷出、升降機、權重調節、服務超時控制
7、快速故障定界定位手段：1、日誌彙總索引2、事件跟蹤
8、服務安全：主要指服務權限
1.4微服務架構21
》通過將功能分散到離散的各個服務中以實現對解決方案的解耦
1.4.1什麼是微服務21
》主要特徵
1、原子服務，專注於一件事
2、高密度部署
3、敏捷交付
4、微自治
1.4.2微服務架構對比SOA22
》兩者差異
1、拆分粒度不同：SOA粗，重點是異構服務化
2、服務依賴：微服務解耦，儘可能不依賴
3、服務規模不同：SOA打包爲主，微服務部署規模膨脹
4、服務治理：SOA靜態治理，微服務動態治理
5、微服務敏捷交付爲主，小團隊研發
1.5總結23
第2章分佈式服務框架入門25
》服務化改造的核心技術就是：分佈式服務框架
2.1分佈式服務框架誕生背景26
2.1.1應用從集中式走向分佈式26?
》儘可能拆分
縱向拆分：按屬性不同分類處理
橫向拆分：按本質不同分塊處理，拆分公共等
2.1.2亟需服務治理28
2.2業界分佈式服務框架介紹29
2.2.1阿里Dubbo30
》主要質量屬性
1、連通性：組件間長連接和緩存
2、健壯性：很多組件掛掉不影響服務
3、伸縮性：服務中心對等集羣、服務提供者無狀態
4、擴展性：插件設計+管道設計
2.2.2淘寶HSF33
》框架總結
1、配置化開發，對業務代碼低侵入
2、插件管理系統
3、異步NIO（一種通信框架名稱）通信，多種序列化方式
4、靈活的路由能力
5、多協議地
6、多種服務治理策略
2.2.3亞馬遜CoralService35
》特點總結
1、支持多協議
2、輕量級框架，非常容易與已有系統集成
3、配置化開發
4、與亞馬遜的其他基礎設施集成，實現DevOps
2.3分佈式服務框架設計36
2.3.1架構原理36
》通常抽象成3層
1、RPC層：本質是通信層，通信和序列化
2、FilterChain層：本質是控制和框架層，負載均衡、統計、通知、重試等
3、service層：業務對接層
》功能上看核心：服務治理中心和服務註冊中心
2.3.2功能特性37
》服務訂閱和發佈
配置化發佈和引用服務
服務自動發現機制
服務在線註冊和去註冊
》服務路由
默認提供隨機路由、輪循、權重路由等
粘滯鏈接：總向同一個提供方發請求，記憶功能
路由定製
》集羣容錯
Failover：失敗重試其他節點，讀操作或冪等性寫操作
Failback：失敗自動恢復，重試等，通常用於消息機制
Failfash：只發起一次調用，失敗立即報錯
》服務調用：同步、異步、並行
》多協議：私有協議、公有協議
》序列化：二進制、文本
》配置中心：本地靜態和配置中心動態
2.3.3性能特性39
》高性能、低時延、性能線性增長（不隨着服務增大、負載增大而明顯增長）
2.3.4可靠性39
》服務註冊中心
服務健康狀態檢測
故障切換
高HA：高可用，全部掛掉不影響已存在服務
》清除單點狀態
服務無狀態：任意一臺宕掉不影響服務
服務集羣容錯：只要集羣還有1臺就正常
》鏈接健壯性
心跳檢測
斷連重連
2.3.5服務治理40
》服務運行狀管控
服務路由：高峯修改路由導流
服務限流
服務遷入遷出：高峯遷出
服務降級：強制減用資源
服務超時控制：保持成功率
》服務監控
性能統計
統計報表
告警
》服務生命週期管理
上線審批
下線通知
服務灰度發佈
》故障快速定界定位
分佈式日誌採集
海量日誌在線檢索
調用鏈可視化展示
運行日誌故障定位
》服務安全
敏感服務的授權策略
鏈路安全：針對調用者，客戶端
2.4總結41
第3章通信框架42
3.1關鍵技術點分析43
3.1.1長連接還是短連接43
》通常是長連接，節約資源
3.1.2BIO還是NIO43
》BIO：同步阻塞模式 NIO：支持多路複用非阻塞
3.1.3自研還是選擇開源NIO框架46
》BIO有不足，開源經歷實踐，netty
3.2功能設計47
3.2.1服務端設計48
》重要設計原則
1、只提供上層api，不綁定具體協議
2、提供的api屏蔽底層通信細節
3、服務端功能不要求全，而是擴展性
3.2.2客戶端設計50
3.3可靠性設計53
3.3.1鏈路有效性檢測54
》ping-pong：發心跳，立即回，請求-迴應型
》ping-ping：對等心跳，雙向心跳
3.3.2斷連重連機制56
3.3.3消息緩存重發57
3.3.4資源優雅釋放58
3.4性能設計59
3.4.1性能差的三宗罪59
》罪一：網絡傳輸方式問題，同步通信壓力增大，通信變差
》罪二：序列化性能差
》罪三：線程模型問題導致開了大量線程
3.4.2通信性能三原則60
》同步的3條
3.4.3高性能之道61
3.5最佳實踐61
3.6總結64
第4章序列化與反序列化65
》跳過
4.1幾個關鍵概念澄清66
4.1.1序列化與通信框架的關係66
4.1.2序列化與通信協議的關係66
4.1.3是否需要支持多種序列化方式67
4.2功能設計67
4.2.1功能豐富度67
4.2.2跨語言支持68
4.2.3兼容性69
4.2.4性能70
4.3擴展性設計71
4.3.1內置的序列化/反序列化功能類71
4.3.2反序列化擴展72
4.3.3序列化擴展75
4.4最佳實踐77
4.4.1接口的前向兼容性規範77
4.4.2高併發下的穩定性78
4.5總結78
第5章協議棧79
》簡單過了一下
5.1關鍵技術點分析80
5.1.1是否必須支持多協議80
5.1.2公有協議還是私有協議80
5.1.3集成開源還是自研81
5.2功能設計82
5.2.1功能描述82
5.2.2通信模型82
5.2.3協議消息定義84
5.2.4協議棧消息序列化支持的字段類型85
5.2.5協議消息的序列化和反序列化86
5.2.6鏈路創建89
5.2.7鏈路關閉90
5.3可靠性設計90
5.3.1客戶端連接超時90
5.3.2客戶端重連機制91
5.3.3客戶端重複握手保護91
》禁止客戶端重複連接以避免客戶端異常消耗大量句柄
5.3.4消息緩存重發92
5.3.5心跳機制92
5.4安全性設計92
》IP白名單機制
5.5最佳實踐―協議的前向兼容性94
5.6總結95
第6章服務路由96
》簡單過一下
6.1透明化路由97
6.1.1基於服務註冊中心的訂閱發佈97
6.1.2消費者緩存服務提供者地址98
6.2負載均衡98
6.2.1隨機98
6.2.2輪循99
6.2.3服務調用時延99
6.2.4一致性哈希100
6.2.5粘滯連接101
》長連接記錄狀態
6.3本地路由優先策略102
6.3.1injvm模式102
》優先尋找本jvm，用本地調用替換遠程調用
6.3.2innative模式102
》優先尋找本機jvm，用本機調用替換遠程調用
6.4路由規則103
6.4.1條件路由規則103
6.4.2腳本路由規則104
6.5路由策略定製105
6.6配置化路由106
6.7最佳實踐——多機房路由107
6.8總結108
第７章集羣容錯109
7.1集羣容錯場景110
7.1.1通信鏈路故障110
7.1.2服務端超時111
7.1.3服務端調用失敗111
7.2容錯策略112
7.2.1失敗自動切換（Failover）112
》失敗重新回到路由入口
7.2.2失敗通知（Failback）113
》將失敗告訴調用者
7.2.3失敗緩存（Failcache）113
》失敗保存，等下次：週期性的、可預測恢復的、延時不敏感的、通知類的等
7.2.4快速失敗（Failfast）114
》高峯時非核心業務，就調用一次
7.2.5容錯策略擴展114
7.3總結115
第8章服務調用116
》簡單看一下
8.1幾個誤區117
8.1.1NIO就是異步服務117
8.1.2服務調用天生就是同步的118
8.1.3異步服務調用性能更高120
8.2服務調用方式120
8.2.1同步服務調用120
8.2.2異步服務調用121
8.2.3並行服務調用125
8.2.4泛化調用129
8.3最佳實踐130
8.4總結131
第９章服務註冊中心132
》簡單看一下
9.1幾個概念133
9.1.1服務提供者133
9.1.2服務消費者133
9.1.3服務註冊中心133
9.2關鍵功能特性設計134
9.2.1支持對等集羣135
9.2.2提供CRUD接口136
9.2.3安全加固136
9.2.4訂閱發佈機制137
9.2.5可靠性138
9.3基於ZooKeeper的服務註冊中心設計139
9.3.1服務訂閱發佈流程設計139
9.3.2服務健康狀態檢測141
9.3.3對等集羣防止單點故障142
9.3.4變更通知機制144
9.4總結144
第10章服務發佈和引用145
10.1服務發佈設計146
10.1.1服務發佈的幾種方式146
10.1.2本地實現類封裝成代理148
10.1.3服務發佈成指定協議148
10.1.4服務提供者信息註冊149
10.2服務引用設計150
10.2.1本地接口調用轉換成遠程服務調用150
10.2.2服務地址本地緩存151
10.2.3遠程服務調用151
10.3最佳實踐152
10.3.1對等設計原則152
10.3.2啓動順序問題153
》不可控，需要支持亂序
10.3.3同步還是異步發佈服務153
》集羣或啓動比較快，異步發佈是可以的（啓動成功，但還有未就緒的）
10.3.4警惕網絡風暴154
10.3.5配置擴展154
10.4總結156
第11章服務灰度發佈157
11.1服務灰度發佈流程設計158
11.1.1灰度環境準備158
》對灰度環境進行劃分、隔離和準備
11.1.2灰度規則設置159
11.1.3灰度規則下發160
11.1.4灰度路由161
11.1.5失敗回滾162
11.1.6灰度發佈總結163
11.2總結163
第12章參數傳遞164
12.1內部傳參165
12.1.1業務內部參數傳遞165
12.1.2服務框架內部參數傳遞168
12.2外部傳參169
12.2.1通信協議支持169
12.2.2傳參接口定義170
12.3最佳實踐171
12.3.1防止參數互相覆蓋171
》沒有好辦法，系統可以預先定義聲明給業務方不要覆蓋
12.3.2參數生命週期管理171
》map無限追加，需要控制
12.4總結172
第13章服務多版本173
》簡單看一下，主要思路就是版本號管理
13.1服務多版本管理設計174
13.1.1服務版本號管理174
13.1.2服務提供者175
13.1.3服務消費者175
13.1.4基於版本號的服務路由176
13.1.5服務熱升級177
13.2與OSGi的對比178
13.2.1模塊化開發179
13.2.2插件熱部署和熱升級184
13.2.3不使用OSGi的其他理由185
13.3總結185
第14章流量控制186
》簡單看一下
14.1靜態流控187
14.1.1傳統靜態流控設計方案187
14.1.2傳統方案的缺點188
14.1.3動態配額分配製188
14.1.4動態配額申請制190
14.2動態流控191
14.2.1動態流控因子192
14.2.2分級流控192
14.3併發控制193
14.3.1服務端全局控制193
14.3.2服務消費者流控194
14.4連接控制195
14.4.1服務端連接數流控195
14.4.2服務消費者連接數流控195
14.5併發和連接控制算法195
14.6總結197
第15章服務降級198
》跳過
15.1屏蔽降級199
15.1.1屏蔽降級的流程199
15.1.2屏蔽降級的設計實現200
15.2容錯降級202
15.2.1容錯降級的工作原理202
15.2.2運行時容錯降級204
15.3業務層降級205
15.4總結205
第16章服務優先級調度207
》跳過
16.1設置服務優先級208
16.2線程調度器方案209
16.3Java優先級隊列210
16.4加權優先級隊列211
16.5服務遷入遷出212
16.6總結213
第17章服務治理214
》跳過
17.1服務治理技術的歷史變遷215
17.1.1SOAGovernance215
17.1.2分佈式服務框架服務治理217
17.1.3AWS雲端微服務治理217
17.2應用服務化後面臨的挑戰218
17.2.1跨團隊協作問題219
17.2.2服務的上下線管控220
17.2.3服務安全220
17.2.4服務SLA保障221
17.2.5故障快速定界定位221
17.3服務治理222
17.3.1服務治理架構設計223
17.3.2運行態服務治理功能設計225
17.3.3線下服務治理232
17.3.4安全和權限管理234
17.4總結237
第18章分佈式消息跟蹤239
》跳過
18.1業務場景分析240
18.1.1故障的快速定界定位240
18.1.2調用路徑分析241
18.1.3調用來源和去向分析242
18.2分佈式消息跟蹤系統設計242
18.2.1系統架構243
18.2.2埋點日誌244
18.2.3採樣率247
18.2.4採集和存儲埋點日誌248
18.2.5計算和展示249
18.2.6調用鏈擴展251
18.3總結251
第19章可靠性設計253
》簡單看一下，主要策略就是隔離分散風險
19.1服務狀態檢測254
19.1.1基於服務註冊中心狀態檢測254
19.1.2鏈路有效性狀態檢測機制255
19.2服務健康度檢測256
19.3服務故障隔離257
19.3.1進程級故障隔離257
19.3.2VM級故障隔離259
19.3.3物理機故障隔離260
19.3.4機房故障隔離261
19.4其他可靠性特性262
19.4.1服務註冊中心262
19.4.2監控中心262
19.4.3服務提供者262
19.5總結263
第20章微服務架構264
》簡單看一下
20.1微服務架構產生的歷史背景265
20.1.1研發成本挑戰265
20.1.2運維成本高267
20.1.3新需求上線週期長268
20.2微服務架構帶來的改變268
20.2.1應用解耦268
20.2.2分而治之270
20.2.3敏捷交付271
20.3微服務架構解析271
20.3.1微服務劃分原則272
20.3.2開發微服務272
20.3.3基於Docker容器部署微服務274
20.3.4治理和運維微服務277
20.3.5特點總結278
20.4總結279
第21章服務化最佳實踐280
21.1性能和時延問題281
21.1.1RPC框架高性能設計281
21.1.2業務最佳實踐285
21.2事務一致性問題286
21.2.1分佈式事務設計方案287
》盡力避免，因爲性能取決於最慢的
》分階段處理：先通用準備、都準備好了通用處理、失敗通知回滾
21.2.2分佈式事務優化288
》選擇一箇中間人
21.3研發團隊協作問題289
21.3.1共用服務註冊中心290
21.3.2直連提供者290
21.3.3多團隊進度協同291
21.3.4服務降級和Mock測試291
21.3.5協同調試問題292
21.3.6接口前向兼容性292
21.4總結292