1　微服務架構 1
微服務應運而生 1
單塊軟件 2
現實世界中的微服務 2
麵嚮微服務的架構 3
為什麼麵嚮微服務的架構更好 3
不足之處 3
關鍵設計原則 4
從組件到業務單元 5
智能的服務，愚蠢的通信管道 7
去中心化 8
技術對比 10
多微纔是足夠的微 10
關鍵的好處 11
彈性 11
可伸縮性 11
技術多樣性 13
可替換性 14
獨立性 15
SOA與微服務的比較 16
為什麼選擇Node.js 18
API聚閤 18
展望Node.js 19
小結 20
2　基於Seneca和PM2構建Node.js微服務 21
選擇Node.js的理由 21
安裝Node.js、npm、Seneca和PM2 22
第一個程序——Hello World 25
Node.js的綫程模型 27
模塊化組織的最佳實踐 27
微服務框架Seneca 32
實現控製反轉 35
Seneca的模式匹配 35
PM2——Node.js的任務執行器 46
單綫程應用及異常 46
PM2——業界標準的任務執行器 47
小結 52
3　從單塊軟件到微服務 53
首先，我們擁有一個單塊軟件 53
如何控製自然增長 54
多抽象纔是過度抽象 57
微服務的齣現 58
微服務的缺陷 64
分割單塊軟件 64
數據纔是分割單塊軟件的主要問題 65
組織架構適配 66
小結 67
4　編寫你的第一個Node.js微服務 69
微電子商務概覽 69
商品管理服務——雙重核心 71
獲取商品信息 72
獲取指定類彆的商品 73
根據ID獲取商品 74
添加商品 75
刪除商品 75
編輯商品 76
整閤各模塊 76
集成Express與Seneca——如何創建REST API 81
郵件服務：一個常見的問題 82
如何發送郵件 82
接口定義 83
設置Mandrill 84
親自動手在微服務中集成Mandrill 86
迴退策略 91
訂單管理服務 92
根據如何獲取非本地數據來定義微服務 93
訂單管理服務代碼 95
UI——API聚閤的産物 99
前端微服務的必要性 99
代碼 99
服務降級——當齣現非災難性故障時 107
斷路器 108
Seneca——一塊使我們工作變得更容易的拼圖 109
Seneca和promise 111
調試 115
小結 118
5　安全性和可追溯性 119
基礎設施的邏輯安全 119
利用SSH來對通信加密 120
應用程序安全 122
保持安全方麵的與時俱進來應對常見威脅 123
有效的代碼審閱 131
可追溯性 132
日誌 132
請求追蹤 134
審計 135
HTTP狀態碼 136
小結 138
6　Node.js微服務的測試及文檔化 140
功能性測試 141
自動化測試的金字塔 142
采用Node.js測試微服務 145
對微服務進行文檔化 175
采用Swagger對API進行文檔化 175
根據Swagger定義來生成項目 182
小結 184
7　微服務的監控 185
服務監控 185
采用PM2和Keymetrics進行監控 186
類人猿大軍—來自Netflix的主動監控 201
吞吐量和性能的降級 204
小結 206
8　微服務的部署 208
軟件部署的一些概念 208
持續集成 209
持續交付 209
采用PM2進行部署 209
PM2中的“生態係統” 210
采用PM2來部署微服務 212
Docker——一種可用於軟件交付的容器 213
組裝容器 215
部署Node.js應用 221
將Docker容器的創建過程自動化 223
Node.js事件循環—入門容易精通難 225
Node.js應用的集群化 228
為應用增加負載均衡 233
NGINX的健康檢查 238
小結 239
· · · · · · (收起)