分布式服務框架原理與實踐pdf

2018年5月4日14:06:28 評論 327

適讀人群 :本書適合架構師、設計師、軟件開發工程師、測試工程師以及其他對互聯網分布式架構感興趣的相關人士閱讀。

1、微服務是當前非常熱的技術關鍵詞之一,那么微服務如何落地呢?首先要實現服務化,微服務架構是一種服務化架構風格。《分布式服務框架原理與實踐》對如何構建分布式服務化系統,提供了原理分析、關鍵技術、開發案例以及業界技術對比,非常系統化,不論是學習分布式服務技術還是深入大型互聯網架構都非常實用。

2、《分布式服務框架原理與實踐》作者李林鋒多年來在華為一直從事核心代碼的架構設計和開發,屬于實戰型架構師,這本書集合了他多年的架構思路,書中內容組織清晰,圖例詳實,非常便于理解與吸收。

3、《分布式服務框架原理與實踐》首先分析了作為一個分布式服務框架所需具備的能力,包括服務注冊中心、服務調用、服務路由、服務發布/灰度發布等;接著分析了服務底層如何有效地進行通信,包括通信框架、序列化/反序列化及協議棧等;然后分析了服務如何做到高可靠性及高安全性等重要特性;最后也闡述了從服務化如何向微服務演進。干貨滿滿!

分布式服務框架原理與實踐 內容簡介

本書作者具有豐富的分布式服務框架、平臺中間件的架構設計和實踐經驗,主導設計的華為分布式服務框架已經在全球數十個國家成功商用。書中依托工作實踐,從分布式服務框架的架構設計原理到實踐經驗總結,涵蓋了服務化架構演進、訂閱發布、路由策略、集群容錯和服務治理等多個專題,全方位剖析服務框架的設計原則和原理,結合大量實踐案例與讀者分享作者對分布式服務框架設計和運維的體會。同時,對基于Docker部署微服務以及基于微服務架構開發、部署和運維業務系統進行了詳細介紹。

分布式服務框架原理與實踐 目錄

第1章應用架構演進1

1.1傳統垂直應用架構2

1.1.1垂直應用架構介紹2

1.1.2垂直應用架構面臨的挑戰4

1.2RPC架構6

1.2.1RPC框架原理6

1.2.2最簡單的RPC框架實現8

1.2.3業界主流RPC框架14

1.2.4RPC框架面臨的挑戰17

1.3SOA服務化架構18

1.3.1面向服務設計的原則18

1.3.2服務治理19

1.4微服務架構21

1.4.1什么是微服務21

1.4.2微服務架構對比SOA22

1.5總結23

第2章分布式服務框架入門25

2.1分布式服務框架誕生背景26

2.1.1應用從集中式走向分布式.26?

2.1.2亟需服務治理28

2.2業界分布式服務框架介紹29

2.2.1阿里Dubbo30

2.2.2淘寶HSF33

2.2.3亞馬遜CoralService35

2.3分布式服務框架設計36

2.3.1架構原理36

2.3.2功能特性37

2.3.3性能特性39

2.3.4可靠性39

2.3.5服務治理40

2.4總結41

第3章通信框架42

3.1關鍵技術點分析43

3.1.1長連接還是短連接43

3.1.2BIO還是NIO43

3.1.3自研還是選擇開源NIO框架46

3.2功能設計47

3.2.1服務端設計48

3.2.2客戶端設計50

3.3可靠性設計53

3.3.1鏈路有效性檢測54

3.3.2斷連重連機制56

3.3.3消息緩存重發57

3.3.4資源優雅釋放58

3.4性能設計59

3.4.1性能差的三宗罪59

3.4.2通信性能三原則60

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

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

6.3.2innative模式102

6.4路由規則103

6.4.1條件路由規則103

6.4.2腳本路由規則104

6.5路由策略定制105

6.6配置化路由106

6.7最佳實踐—多機房路由107

6.8總結108

第7章集群容錯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

第9章服務注冊中心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

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

分布式服務框架原理與實踐 精彩文摘

8.2.2 異步服務調用

基于JDK的Future機制,可以非常方便地實現異步服務調用,JDK的Future接口定義如圖8-5所示。

JDK原生的Future主要用于異步操作,它代表了異步操作的執行結果,用戶可以通過調用它的get方法獲取結果。如果當前操作沒有執行完,get操作將阻塞調用線程。

在實際項目中,往往會擴展JDK的Future,提供Future-Listener機制,它支持主動獲取和被動異步回調通知兩種模式,適用于不同的業務場景。

以Netty的Future接口定義為例,新增了監聽器管理接口,監聽器主要用于異步通知回調。

異步服務調用的工作流程如下:

1) 消費者調用服務端發布的接口,接口調用由分布式服務框架包裝成動態代理,發起遠程服務調用。

2) 通信框架異步發送請求消息,如果沒有發生I/O異常,返回。

3) 請求消息發送成功后,I/O線程構造Future對象,設置到RPC上下文中。

4) 用戶線程通過RPC上下文獲取Future對象。

5) 構造Listener對象,將其添加到Future中,用于服務端應答異步回調通知。

6) 用戶線程返回,不阻塞等待應答。

7) 服務端返回應答消息,通信框架負責反序列化等。

8) I/O線程將應答設置到Future對象的操作結果中。

9) Future對象掃描注冊的監聽器列表,循環調用監聽器的operationComplete方法,將結果通知給監聽器,監聽器獲取到結果之后,繼續后續業務邏輯的執行,異步服務調用結束。

需要指出的是,還有另外一種異步服務調用形式,就是不添加Listener,用戶連續發起N次服務調用,然后依次從RPC上下文中獲取Future對象,最終再主動get結果,業務線程阻塞,相比于老的同步服務調用,它的阻塞時間更短,其工作原理如圖8-8所示。

異步服務調用的代碼示例如下:

xxxService1.xxxMethod(Req);

Future f1 = RpcContext.getContext().getFuture();

xxxService2.xxxMethod(Req);

Future f2 = RpcContext.getContext().getFuture();

Object xxResult1 = f1.get(3000);

Object xxResult2 = f2.get(3000); }

假如xxxService1和xxxService2發布成異步服務,則調用xxxMethod之后當前業務線程不阻塞,立即返回null。用戶不能直接使用它的返回值,而是通過當前線程上下文RPCContext獲取異步操作結果Future。獲取到Future之后繼續發起其他異步服務調用,然后獲取另一個Future……最后,通過Future的get方法集中獲取結果。無論有多少個Future,采用此種方式用戶線程最長阻塞時間為耗時最長的Future,即T = Max t(future1N)。如果采用同步服務調用,用戶線程的阻塞時間T = t(future1) + t(future2) + ……+ t(futureN)。

異步服務調用相比于同步服務調用有兩個優點:

◎ 化串行為并行,提升服務調用效率,減少業務線程阻塞時間。

◎ 化同步為異步,避免業務線程阻塞。

由于每次服務調用都是同步阻塞,三個服務調用總耗時為T = T1 + T2 + T3。下面我們看下采用異步服務調用之后的優化效果。

采用異步服務調用模式,最后調用三個服務異步操作結果Future的get方法同步等待應答,它的總執行時間T = Max(T1, T2, T3),相比于同步服務調用,性能提升效果非常明顯。

第二種基于Future-Listener的純異步服務調用,它的代碼示例如下:

xxxService1.xxxMethod(Req);

Future f1 = RpcContext.getContext().getFuture();

Listener l = new xxxListener();

f1.addListener(l);

后續代碼省略 }

基于Future-Listener的異步服務調用相比于Future-get模式更好,但是在實際使用中有一定的局限性,具體的使用限制留給讀者自己思考。

圖書網:分布式服務框架原理與實踐pdf

恭喜,此資源為免費資源,請先
本站所有資源收集于互聯網,只做學習和交流使用,版權歸著作人和出版社所有,請在下載后24小時之內自覺刪除,若作商業用途,請購買正版,由于未及時購買和付費發生的侵權行為,與本站無關。本站發布的內容若侵犯到您的權益,請聯系站長刪除,我們將及時處理!
  • 我的微信
  • 掃一掃加好友
  • weinxin
  • 微信公眾號
  • 掃一掃關注(網站備用地址)
  • weinxin

發表評論

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: