微服務設計pdf

圖書網
圖書網
圖書網
11802
文章
1855
評論
2018年5月5日10:31:21 評論 699

過去十年中,分布式系統的粒度變得越來越細,包含大量代碼的單塊應用逐漸轉變為自包含的微服務。但開發微服務系統也有一些讓人頭疼的問題。本書通過大量的例子,全面討論了系統架構師和管理員在構建、管理和演化微服務架構時必須考慮的問題,并給出了實用的建議。

本書不但詳細地闡述了微服務的基本概念,而且還深入探究了如何對自治服務進行建模、集成、測試、部署及監控。書中虛構了某個領域的一家公司,來幫助讀者學習微服務架構是如何影響一個領域的。

了解微服務如何將系統設計與組織目標相匹配

掌握將一個服務和現有系統進行集成的不同方式

使用增量式的做法拆分單塊代碼庫

通過持續集成部署各個微服務

審視對分布式系統進行測試和監控的復雜性

管理“用戶-服務”和“服務-服務”兩種模式下的安全性

理解微服務架構在規模化方面所面臨的問題

微服務設計 內容簡介

本書全面介紹了微服務的建模、集成、測試、部署和監控,通過一個虛構的公司講解了如何建立微服務架構。主要內容包括認識微服務在保證系統設計與組織目標統一上的重要性,學會把服務集成到已有系統中,采用遞增手段拆分單塊大型應用,通過持續集成部署微服務,等等。

微服務設計 目錄

前言

第1章微服務1

1.1什么是微服務2

1.1.1很小,專注于做好一件事2

1.1.2自治性3

1.2主要好處3

1.2.1技術異構性3

1.2.2彈性4

1.2.3擴展5

1.2.4簡化部署5

1.2.5與組織結構相匹配6

1.2.6可組合性6

1.2.7對可替代性的優化6

1.3面向服務的架構7

1.4其他分解技術7

1.4.1共享庫8

1.4.2模塊8

1.5沒有銀彈9

1.6小結10

第2章演化式架構師11

2.1不準確的比較11

2.2架構師的演化視角12

2.3分區14

2.4一個原則性的方法15

2.4.1戰略目標15

2.4.2原則15

2.4.3實踐16

2.4.4將原則和實踐相結合16

2.4.5真實世界的例子16

2.5要求的標準17

2.5.1監控18

2.5.2接口18

2.5.3架構安全性18

2.6代碼治理18

2.6.1范例19

2.6.2裁剪服務代碼模板19

2.7技術債務20

2.8例外管理21

2.9集中治理和領導21

2.10建設團隊22

2.11小結23

第3章如何建模服務24

3.1MusicCorp簡介24

3.2什么樣的服務是好服務25

3.2.1松耦合25

3.2.2高內聚25

3.3限界上下文26

3.3.1共享的隱藏模型26

3.3.2模塊和服務27

3.3.3過早劃分28

3.4業務功能28

3.5逐步劃分上下文29

3.6關于業務概念的溝通30

3.7技術邊界30

3.8小結31

第4章集成32

4.1尋找理想的集成技術32

4.1.1避免破壞性修改32

4.1.2保證API的技術無關性32

4.1.3使你的服務易于消費方使用33

4.1.4隱藏內部實現細節33

4.2為用戶創建接口33

4.3共享數據庫33

4.4同步與異步35

4.5編排與協同35

4.6遠程過程調用38

4.6.1技術的耦合38

4.6.2本地調用和遠程調用并不相同39

4.6.3脆弱性39

4.6.4RPC很糟糕嗎40

4.7REST41

4.7.1REST和HTTP41

4.7.2超媒體作為程序狀態的引擎42

4.7.3JSON、XML還是其他44

4.7.4留心過多的約定44

4.7.5基于HTTP的REST的缺點45

4.8實現基于事件的異步協作方式46

4.8.1技術選擇46

4.8.2異步架構的復雜性47

4.9服務即狀態機48

4.10響應式擴展48

4.11微服務世界中的DRY和代碼重用的危險49

4.12按引用訪問50

4.13版本管理51

4.13.1盡可能推遲51

4.13.2及早發現破壞性修改52

4.13.3使用語義化的版本管理53

4.13.4不同的接口共存53

4.13.5同時使用多個版本的服務54

4.14用戶界面55

4.14.1走向數字化56

4.14.2約束56

4.14.3API組合57

4.14.4UI片段的組合57

4.14.5為前端服務的后端59

4.14.6一種混合方式60

4.15與第三方軟件集成61

4.15.1缺乏控制61

4.15.2定制化62

4.15.3意大利面式的集成62

4.15.4在自己可控的平臺進行定制化62

4.15.5絞殺者模式64

4.16小結65

第5章分解單塊系統66

5.1關鍵是接縫66

5.2分解MusicCorp67

5.3分解單塊系統的原因68

5.3.1改變的速度68

5.3.2團隊結構68

5.3.3安全68

5.3.4技術68

5.4雜亂的依賴69

5.5數據庫69

5.6找到問題的關鍵69

5.7例子:打破外鍵關系70

5.8例子:共享靜態數據71

5.9例子:共享數據72

5.10例子:共享表73

5.11重構數據庫74

5.12事務邊界75

5.12.1再試一次76

5.12.2終止整個操作77

5.12.3分布式事務77

5.12.4應該怎么辦呢78

5.13報告78

5.14報告數據庫78

5.15通過服務調用來獲取數據80

5.16數據導出81

5.17事件數據導出82

5.18數據導出的備份83

5.19走向實時84

5.20修改的代價84

5.21理解根本原因84

5.22小結85

第6章部署86

6.1持續集成簡介86

6.2把持續集成映射到微服務87

6.3構建流水線和持續交付90

6.4平臺特定的構建物91

6.5操作系統構建物92

6.6定制化鏡像93

6.6.1將鏡像作為構建物94

6.6.2不可變服務器95

6.7環境95

6.8服務配置96

6.9服務與主機之間的映射97

6.9.1單主機多服務97

6.9.2應用程序容器99

6.9.3每個主機一個服務100

6.9.4平臺即服務101

6.10自動化101

6.11從物理機到虛擬機102

6.11.1傳統的虛擬化技術103

6.11.2Vagrant104

6.11.3Linux容器104

6.11.4Docker106

6.12一個部署接口107

6.13小結109

第7章測試110

7.1測試類型110

7.2測試范圍111

7.2.1單元測試112

7.2.2服務測試113

7.2.3端到端測試114

7.2.4權衡114

7.2.5比例115

7.3實現服務測試115

7.3.1mock還是打樁115

7.3.2智能的打樁服務116

7.4微妙的端到端測試117

7.5端到端測試的缺點118

7.6脆弱的測試118

7.6.1誰來寫這些測試119

7.6.2測試多長時間119

7.6.3大量的堆積120

7.6.4元版本120

7.7測試場景,而不是故事121

7.8拯救消費者驅動的測試121

7.8.1Pact123

7.8.2關于溝通124

7.9還應該使用端到端測試嗎124

7.10部署后再測試125

7.10.1區分部署和上線125

7.10.2金絲雀發布126

7.10.3平均修復時間勝過平均故障間隔時間127

7.11跨功能的測試128

7.12小結129

第8章監控131

8.1單一服務,單一服務器132

8.2單一服務,多個服務器132

8.3多個服務,多個服務器133

8.4日志,日志,更多的日志134

8.5多個服務的指標跟蹤135

8.6服務指標135

8.7綜合監控136

8.8關聯標識137

8.9級聯139

8.10標準化139

8.11考慮受眾140

8.12未來140

8.13小結141

第9章安全143

9.1身份驗證和授權143

9.1.1常見的單點登錄實現144

9.1.2單點登錄網關145

9.1.3細粒度的授權146

9.2服務間的身份驗證和授權146

9.2.1在邊界內允許一切146

9.2.2HTTP(S)基本身份驗證147

9.2.3使用SAML或OpenIDConnect148

9.2.4客戶端證書148

9.2.5HTTP之上的HMAC149

9.2.6API密鑰149

9.2.7代理問題150

9.3靜態數據的安全152

9.3.1使用眾所周知的加密算法152

9.3.2一切皆與密鑰相關153

9.3.3選擇你的目標153

9.3.4按需解密153

9.3.5加密備份153

9.4深度防御154

9.4.1防火墻154

9.4.2日志154

9.4.3入侵檢測(和預防)系統154

9.4.4網絡隔離155

9.4.5操作系統155

9.5一個示例156

9.6保持節儉158

9.7人的因素158

9.8黃金法則158

9.9內建安全159

9.10外部驗證159

9.11小結159

第10章康威定律和系統設計161

10.1證據161

10.1.1松耦合組織和緊耦合組織162

10.1.2WindowsVista162

10.2Netflix和Amazon162

10.3我們可以做什么163

10.4適應溝通途徑163

10.5服務所有權164

10.6共享服務的原因164

10.6.1難以分割164

10.6.2特性團隊164

10.6.3交付瓶頸165

10.7內部開源166

10.7.1守護者的角色166

10.7.2成熟166

10.7.3工具167

10.8限界上下文和團隊結構167

10.9孤兒服務167

10.10案例研究168

10.11反向的康威定律169

10.12人170

10.13小結170

第11章規模化微服務171

11.1故障無處不在171

11.2多少是太多172

11.3功能降級173

11.4架構性安全措施174

11.5反脆弱的組織175

11.5.1超時176

11.5.2斷路器176

11.5.3艙壁178

11.5.4隔離179

11.6冪等179

11.7擴展180

11.7.1更強大的主機181

11.7.2拆分負載181

11.7.3分散風險181

11.7.4負載均衡182

11.7.5基于worker的系統184

11.7.6重新設計184

11.8擴展數據庫185

11.8.1服務的可用性和數據的持久性185

11.8.2擴展讀取185

11.8.2擴展寫操作186

11.8.4共享數據庫基礎設施187

11.8.5CQRS187

11.9緩存188

11.9.1客戶端、代理和服務器端緩存188

11.9.2HTTP緩存189

11.9.3為寫使用緩存190

11.9.4為彈性使用緩存190

11.9.5隱藏源服務191

11.9.6保持簡單191

11.9.7緩存中毒:一個警示192

11.10自動伸縮192

11.11CAP定理193

11.11.1犧牲一致性194

11.11.2犧牲可用性195

11.11.3犧牲分區容忍性195

11.11.4AP還是CP196

11.11.5這不是全部或全不196

11.11.6真實世界197

11.12服務發現197

11.13動態服務注冊199

11.13.1Zookeeper199

11.13.2Consul200

11.13.4構造你自己的系統201

11.13.5別忘了人201

11.14文檔服務201

11.14.1Swagger202

11.14.2HAL和HAL瀏覽器202

11.15自描述系統203

11.16小結203

第12章總結204

12.1微服務的原則204

12.1.1圍繞業務概念建模205

12.1.2接受自動化文化205

12.1.3隱藏內部實現細節205

12.1.4讓一切都去中心化206

12.1.5可獨立部署206

12.1.6隔離失敗206

12.1.7高度可觀察207

12.2什么時候你不應該使用微服務207

12.3臨別贈言208

關于作者209

關于封面209

微服務設計 精彩文摘

在介紹具體的技術選擇之前,讓我們先就服務如何協作這個問題做一些討論。服務之間的通信應該是同步的還是異步的呢?這個基礎性的選擇會不可避免地引導我們使用不同的實現。

如果使用同步通信,發起一個遠程服務調用后,調用方會阻塞自己并等待整個操作的完成。如果使用異步通信,調用方不需要等待操作完成就可以返回,甚至可能不需要關心這個操作完成與否。

同步通信聽起來合理,因為可以知道事情到底成功與否。異步通信對于運行時間比較長的任務來說比較有用,否則就需要在客戶端和服務器之間開啟一個長連接,而這是非常不實際的。當你需要低延遲的時候,通常會使用異步通信,否則會由于阻塞而降低運行的速度。對于移動網絡及設備而言,發送一個請求之后假設一切工作正常(除非被告知不正常),這種方式可以在很大程度上保證在網絡很卡的情況下用戶界面依然很流暢。另一方面,處理異步通信的技術相對比較復雜,后面會討論。

這兩種不同的通信模式有著各自的協作風格,即請求/響應或者基于事件。對于請求/響應來說,客戶端發起一個請求,然后等待響應。這種模式能夠與同步通信模式很好地匹配,但異步通信也可以使用這種模式。我可以發起一個請求,然后注冊一個回調,當服務端操作結束之后,會調用該回調。

對于使用基于事件的協作方式來說,情況會顛倒過來。客戶端不是發起請求,而是發布一個事件,然后期待其他的協作者接收到該消息,并且知道該怎么做。我們從來不會告知任何人去做任何事情。基于事件的系統天生就是異步的。整個系統都很聰明,也就是說,業務邏輯并非集中存在于某個核心大腦,而是平均地分布在不同的協作者中。基于事件的協作方式耦合性很低。客戶端發布一個事件,但并不需要知道誰或者什么會對此做出響應,這也意味著,你可以在不影響客戶端的情況下對該事件添加新的訂閱者。
哪些因素會影響對這兩種風格的選擇呢?一個重要的因素是這種風格能否很好地解決復雜問題,比如如何處理跨服務邊界的流程'_而且這種流程有可能會運行很長時間。

圖書網:微服務設計pdf

繼續閱讀
資源地址:用心發表評論,回復即可查看(字數限制至少10字以上)。
  • 我的微信
  • 掃一掃加好友
  • weinxin
  • 微信公眾號
  • 掃一掃關注
  • weinxin
匿名

發表評論

匿名網友 填寫信息

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