-- 會員 / 註冊 --  
 帳號:
 密碼:
  | 註冊 | 忘記密碼
3/26 新書到! 3/19 新書到! 3/14 新書到! 12/12 新書到!
購書流程Q & A站務留言版客服信箱
3ds MaxMayaRhinoAfter EffectsSketchUpZBrushPainterUnity
PhotoShopAutoCadMasterCamSolidWorksCreoUGRevitNuke
C#CC++Java遊戲程式Linux嵌入式PLCFPGAMatlab
駭客資料庫搜索引擎影像處理FluentVR+ARANSYS深度學習
單晶片AVROpenGLArduinoRaspberry Pi電路設計CadenceProtel
HadoopPythonStm32CortexLabview手機程式AndroidiPhone
可查書名,作者,ISBN,3dwoo書號
詳細書籍分類

持續演進的Cloud Native:云原生架構下微服務最佳實踐

( 簡體 字)
作者:王啟軍類別:1. -> 程式設計 -> 雲計算
譯者:
出版社:電子工業出版社持續演進的Cloud Native:云原生架構下微服務最佳實踐 3dWoo書號: 50155
詢問書籍請說出此書號!

缺書
NT售價: 395

出版日:10/1/2018
頁數:316
光碟數:0
站長推薦:
印刷:黑白印刷語系: ( 簡體 版 )
加入購物車 加到我的最愛
(請先登入會員)
ISBN:9787121351204
作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 
(簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證)
作者序:

譯者序:

前言:



架構沒有絕對的對與錯
在技術的領域里,并不存在“上帝”。沒有人的每句話都是對的,沒有人的所有思想都能被別人所接受。
我經常在公司范圍內培訓,首先是灌輸架構思想和解決方案,然后會在實戰演練中模擬一個比較簡單的業務場景,把所有人分成4個團隊,每個團隊大概有10個人。結果發現,每個團隊最終形成的架構圖總有很大差異,很難評價一個團隊的做法是對是錯。例如,是要拆分為3個服務,還是5個服務,他們有各自的理由,除非比較明顯的問題,否則你很難以一個理由去否定另一個理由。原因只是各個團隊站在了不同的維度綜合判斷、權衡,形成了自己認為滿意的架構方案。因此,架構沒有絕對的對與錯,只是在不同的角度做出的決定而已。
架構很難被衡量
每個公司的管理層都希望盡可能地去衡量架構的先進性,希望認清差距,向著好的架構方向不斷演進。然而架構很難被衡量,須同時具備差距特別明顯、制定指標的人能力達到一定高度、業務場景比較接近這三條才有可能衡量。當然我們可以去制定一些指標,這些指標應該是參考性的,作為一個自檢項,而不是評價標準。從這個角度看,并不是符合Cloud Native就是好的,不符合就是差的,當不符合時,你的理由是什么?你站在問題的哪個角度?
Martin Fowler曾說:“優秀的技術人員的觀點勝過任何度量,盡管它是主觀的。”
因為你無法統一每個人關注的點,以及對各自關注的點的重視程度,所以架構很難被衡量。
架構需要持續演進
在傳統企業中,架構設計是一個很重要且很耗費時間的過程,需要經過很多輪審核,架構文檔動輒幾百頁,而且這個文檔絕對不能有沒考慮到的問題,必須面面俱到、接近完美。例如,目前系統還沒有用戶,就要為未來1千萬的用戶耗費精力解決性能問題,而且軟件永遠有你想象不到的問題發生。實際上我們描述的是一種靜止的架構,這種架構每次變更都需要耗費巨大的成本。如果此時恰好出現了一個基于敏捷思想的競爭對手,則會形成一種鮮明的對比,他們不去考慮太長時間之后的事,出現什么問題就解決什么問題,因為有可能一年以后這個項目死了,也有可能用戶人數突破1億,系統需要進行大規模重構。總之,未來是不確定的。可見,架構是錘煉出來的,而不僅是設計出來的。
反應速度是傳統企業的硬傷,這不是通過加班就能解決的。可以看一下互聯網巨頭們每年的發布次數,動輒每年發布幾百萬乃至上千萬次,每個服務每天都在發生變化,每周可能都會上線。在如今這個快速發展的世界里,你無法依賴一個人去做所有的決策。這就需要發揮所有成員的主觀能動性,也就是說,架構應該交給一線決策。回到前面提到的問題,服務怎么拆分更好?我想只有深入了解需求、場景、目標甚至自身條件之后才能做出決策。并且,架構的演進不是一蹴而就的,而是一個長期發展的過程。
變革需要堅決
歷史上的變革大多阻力重重,因為一旦變革就意味著打破原有的“默契”,打破原有的“潛規則”,而“頑固派”通常是原有文化的受益者,他們通常不會反對變革,而是通過“我們不能完全照抄,要走出適合我們的路”來促成妥協。如果變革過程中遇到任何風吹草動,就更會給“頑固派”各種理由“走自己的路”。這也就是為什么我們熟知世界領先IT企業的技術、研發流程和企業文化,而就是學不會的原因。
這時候需要的是企業領導者的果斷、堅決。只要方向沒錯,就要堅持,決不動搖。下面這段話是馬云對劉振飛(阿里技術保障部負責人)關于阿里云內部爭議的回復,反映了一個領導者在企業變革過程中起到的作用。
在王堅加入阿里之前,我跟教授(指曾鳴)討論公司的未來,覺得云計算和大數據代表未來,對國家和社會的發展有長遠的意義,所以我們要干,這是第一點。但是怎么做云計算、大數據?我們誰也不知道。現在來了個人叫王堅,他說:“我知道怎么做”,為什么不支持呢?這是第二點。第三點,即使萬一做失敗了,那也沒關系,咱們的人倒下70%,還有30%活著,咱們活下來的人打掃戰場,換個方向繼續干,總要把它做出來。
寫代碼不同于搬磚
如果是搬磚,那么效率高的人和效率低的人之間的差距不會太大,因此每個人每天的工資都是相對固定的。但是在如今這個知識爆炸的時代,對于從事軟件行業的群體來說,效率高者的工作效率比效率低者的可能高出幾十倍、幾百倍,優秀的人能寫出更高質量的代碼,能夠預測問題。而在這個行業越是優秀的人才越是稀缺,因此很多互聯網公司都愿意花大價錢去招一些更優秀的人。
優秀的人不愿意來,不一定是因為錢。花錢雇傭優秀的人是一方面,怎樣管理這些人又是另外一方面,用管理搬磚者的方式來管理他們是不行的,管理優秀的人需要給予他們更多的信任,需要營造一種公開透明、自由高效的環境。
關于本書
為什么會出現Cloud Native這個概念呢?無論是云化、平臺化,還是微服務架構,又或者是敏捷開發、自動化,都只是描述了幾個點,而Cloud Native更像是一個面,通過它把這些點都關聯起來了。某幾個點做得很好而忽略了其他點通常會走入誤區。例如,某些團隊只關注服務拆分,而忽略了工具、組織對微服務的影響,最終效果并不理想。又如,要提升系統的可用性,只是從技術的角度去考慮是不夠的,還要考慮如何通過自動化測試提升可用性,如何通過Code Review提升可用性,以及當故障發生時如何快速修復。我希望通過個人的工作經歷以書的方式傳遞一些這方面的經驗教訓。
本書分別從架構、研發流程、團隊文化三個角度全面論述Cloud Native,因為只有三方面配合才能達到理想的效果。我見到過無數失敗的案例,絕大多數都是因為考慮得比較片面,例如單純從架構角度進行變革,或者單純從研發流程角度變革。我們希望模仿Google、Facebook、Amazon、Netflix等領先企業,但是往往高估了架構的影響力,而低估了研發流程和團隊文化的影響力。實際上,研發流程和團隊文化對架構有著非常重要的影響。本書以Cloud Native的起源、訴求及組成開始,全面描述了Cloud Native的各個方面。從架構角度闡述了如何實施微服務架構,如何構建敏捷基礎設施及平臺服務。同時,從可用性、可擴展性、性能、一致性等角度描述了微服務架構中產生的問題及解決方案。最后,分別描述了Cloud Native下的研發流程和團隊文化。
本書比較適合技術管理者、架構師和有一定基礎的技術人員閱讀,特別是傳統軟件企業的技術領導者,以及希望向互聯網公司轉型的或者轉型失敗的企業技術領導者。此書將幫助這些人少走彎路。還有一些比較有經驗的高級研發人員,閱讀此書也利于系統掌握Cloud Native的關鍵技能。無論如何,都希望此書能給你帶來較好的體驗,使你獲得啟發。
書中的內容大多來自我的工作經驗,不免存在遺漏及錯誤,歡迎指正。讀者可以直接發送郵件到我的郵箱,在此提前表示感謝。
感謝工作中的各位同事、生活中的各位好友,正是他們的支持和鼓勵,才讓本書完成。更要感謝我的家人,特別是我的妻子和女兒,是她們的擁抱和燦爛的笑容讓我堅定了信念。

王啟軍




輕松注冊成為博文視點社區用戶,掃碼直達本書頁面。
? 提交勘誤:您對書中內容的修改意見可在 提交勘誤 處提交,若被采納,將獲贈博文視點社區積分(在您購買電子書時,積分可用來抵扣相應金額)。
? 交流互動:在頁面下方 讀者評論 處留下您的疑問或觀點,與我們和其他讀者一同學習交流。
內容簡介:

云化架構是一個全新概念,包含微服務、十二因子、敏捷基礎設施和持續交付這些新老熱點。而Cloud Native則是目前實現云化架構最有希望的技術解決方案,其建筑在傳統Cloud的三層(IaaS、PaaS、SaaS)概念之上,其中敏捷基礎設施對應IaaS部分,微服務則可以對應PaaS和SaaS部分。本書內容基于Cloud Native原理展開,重點描述云化架構的組成部分,及其相關理論和實踐。本書來自作者在實際工作的經驗積累,內容既有經典理論,又有豐富的實戰案例,更不乏關鍵問題的完整解決方案。


目錄:

第1章 綜述 1
1.1 Cloud Native的起源 1
1.2 Cloud Native的組成 4
1.3 Cloud Native背后的訴求 5
1.4 如何衡量Cloud Native的能力 5
1.5 Cloud Native的原則 6
第2章 微服務架構 11
2.1 微服務架構的起源 11
2.2 為什么采用微服務架構 12
2.2.1 單體架構與微服務架構 12
2.2.2 什么時候開始微服務架構 14
2.2.3 如何決定微服務架構的拆分粒度 14
2.3 微服務設計原則 15
2.4 微服務架構實施的先決條件 17
2.4.1 研發環境和流程上的轉變 17
2.4.2 拆分前先做好解耦 18
2.5 微服務劃分模式 20
2.5.1 基于業務復雜度選擇服務劃分方法 20
2.5.2 基于數據驅動劃分服務 21
2.5.3 基于領域驅動劃分服務 22
2.5.4 從已有單體架構中逐步劃分服務 23
2.5.5 微服務拆分策略 24
2.5.6 如何衡量服務劃分的合理性 25
2.6 微服務劃分反模式 26
2.7 微服務API設計 28
2.7.1 優秀API的設計原則 28
2.7.2 服務間通信——RPC 28
2.7.3 序列化——Protobuf 30
2.7.4 服務間通信——RESTful 33
2.7.5 通過Swagger實現RESTful 36
2.7.6 通過Spring Boot、Springfox、Swagger實現RESTful 41
2.7.7 HTTP協議的進化——HTTP/2 46
2.7.8 HTTP/2和Protobuf的組合——gRPC 48
2.8 微服務框架 53
2.9 基于Dubbo框架實現微服務 54
2.10 基于Spring Cloud框架實現微服務 58
2.11 服務發現場景下的ZooKeeper與Etcd 67
2.12 微服務部署策略 68
2.12.1 服務獨享數據庫 69
2.12.2 服務獨享虛擬機/容器 70
2.13 為什么總覺得微服務架構很別扭 70
第3章 敏捷基礎設施及公共基礎服務 73
3.1 傳統基礎設施面臨的挑戰 73
3.2 什么是敏捷基礎設施 74
3.3 基于容器的敏捷基礎設施 75
3.3.1 容器VS虛擬機 76
3.3.2 安裝Docker 77
3.3.3 部署私有Docker Registry 79
3.3.4 基于Spring Boot、Maven、Docker構建微服務 79
3.3.5 基于docker-compose管理容器 84
3.4 基于公共基礎服務的平臺化 85
3.5 監控告警服務 86
3.5.1 監控數據采集 87
3.5.2 監控數據接收模式 87
3.5.3 通過時間序列數據庫存儲監控數據 88
3.5.4 開源監控系統實現Prometheus 88
3.5.5 通過Prometheus和Grafana監控服務 90
3.6 分布式消息中間件服務 96
3.6.1 分布式消息中間件的作用 97
3.6.2 業界常用的分布式消息中間件 98
3.6.3 Kafka的設計原理 99
3.6.4 為什么Kafka性能高 100
3.6.5 Kafka的數據存儲結構 102
3.6.6 如何保證Kafka不丟消息 104
3.6.7 Kafka跨數據中心場景集群部署模式 106
3.7 分布式緩存服務 108
3.7.1 分布式緩存的應用場景 109
3.7.2 業界常用的分布式緩存Memcached 110
3.7.3 業界常用的分布式緩存——Redis 111
3.7.4 Redis常用的分布式緩存集群模式 112
3.7.5 基于Codis實現Redis分布式緩存集群 116
3.8 分布式任務調度服務 118
3.8.1 通過Tbschedule實現分布式任務調度 119
3.8.2 通過Elastic-Job實現分布式任務調度 123
3.9 如何生成分布式ID 126
3.9.1 UUID 126
3.9.2 SnowFlake 127
3.9.3 Ticket Server 128
3.9.4 小結 129
第4章 可用性設計 130
4.1 綜述 130
4.1.1 可用性和可靠性的關系 130
4.1.2 可用性的衡量標準 131
4.1.3 什么降低了可用性 131
4.2 逐步切換 132
4.2.1 影子測試 132
4.2.2 藍綠部署 133
4.2.3 灰度發布/金絲雀發布 134
4.3 容錯設計 135
4.3.1 消除單點 136
4.3.2 特性開關 136
4.3.3 服務分級 137
4.3.4 降級設計 138
4.3.5 超時重試 139
4.3.6 隔離策略 152
4.3.7 熔斷器 153
4.4 流控設計 157
4.4.1 限流算法 157
4.4.2 流控策略 159
4.4.3 基于Guava限流 160
4.4.4 基于Nginx限流 162
4.5 容量預估 163
4.6 故障演練 164
4.7 數據遷移 165
4.7.1 邏輯分離,物理不分離 166
4.7.2 物理分離 166
第5章 可擴展性設計 168
5.1 加機器能解決問題嗎 168
5.2 橫向擴展 169
5.3 AKF擴展立方體 170
5.4 如何擴展長連接 172
5.5 如何擴展數據庫 175
5.5.1 X軸擴展——主從復制集群 175
5.5.2 Y軸擴展——分庫、垂直分表 176
5.5.3 Z軸擴展——分片(sharding) 177
5.5.4 為什么要帶拆分鍵 182
5.5.5 分片后的關聯查詢問題 183
5.5.6 分片擴容(re-sharding) 184
5.5.7 精選案例 187
5.6 如何擴展數據中心 190
5.6.1 兩地三中心和同城多活 190
5.6.2 同城多活 191
5.6.3 異地多活 192
第6章 性能設計 194
6.1 性能指標 195
6.2 如何樹立目標 195
6.3 如何尋找平衡點 196
6.4 如何定位瓶頸點 197
6.5 服務通信優化 198
6.5.1 同步轉異步 198
6.5.2 阻塞轉非阻塞 199
6.5.3 序列化 200
6.6 通過消息中間件提升寫性能 201
6.7 通過緩存提升讀性能 202
6.7.1 基于ConcurrentHashMap實現本地緩存 203
6.7.2 基于Guava Cache實現本地緩存 204
6.7.3 緩存的常用模式 205
6.7.4 應用緩存的常見問題 207
6.8 數據庫優化 208
6.8.1 通過執行計劃分析瓶頸點 208
6.8.2 為搜索字段創建索引 209
6.8.3 通過慢查詢日志分析瓶頸點 210
6.8.4 通過提升硬件能力優化數據庫 211
6.9 簡化設計 212
6.9.1 轉移復雜度 212
6.9.2 從業務角度優化 212
第7章 一致性設計 214
7.1 問題起源 214
7.2 基礎理論 215
7.2.1 什么是分布式事務 216
7.2.2 CAP定理 218
7.2.3 BASE理論 219
7.2.4 Quorum機制(NWR模型) 219
7.2.5 租約機制(Lease) 220
7.2.6 狀態機(Replicated State Machine) 221
7.3 分布式系統的一致性分類 222
7.3.1 以數據為中心的一致性模型 223
7.3.2 以用戶為中心的一致性模型 226
7.3.3 業界常用的一致性模型 229
7.4 如何實現強一致性 230
7.4.1 兩階段提交 230
7.4.2 三階段提交(3PC) 231
7.5 如何實現最終一致性 232
7.5.1 重試機制 232
7.5.2 本地記錄日志 233
7.5.3 可靠事件模式 233
7.5.4 Saga事務模型 235
7.5.5 TCC事務模型 237
7.6 分布式鎖 238
7.6.1 基于數據庫實現悲觀鎖和樂觀鎖 239
7.6.2 基于ZooKeeper的分布式鎖 241
7.6.3 基于Redis實現分布式鎖 242
7.7 如何保證冪等性 244
7.7.1 冪等令牌(Idempotency Key) 244
7.7.2 在數據庫中實現冪等性 246
第8章 未來值得關注的方向 247
8.1 Serverless 247
8.1.1 什么是Serverless 247
8.1.2 Serverless的現狀 248
8.1.3 Serverless的應用場景 249
8.2 Service Mesh 250
8.2.1 什么是Service Mesh 250
8.2.2 為什么需要Service Mesh 252
8.2.3 Service Mesh的現狀 253
8.2.4 Istio架構分析 255
第9章 研發流程 258
9.1 十二因子 258
9.2 為什么選擇DevOps 261
9.3 自動化測試 263
9.3.1 單元測試 263
9.3.2 TDD 264
9.3.3 提交即意味著可測試 265
9.4 Code Review 265
9.4.1 Code Review的意義 265
9.4.2 Code Review的原則 266
9.4.3 Code Review的過程 267
9.5 流水線 267
9.5.1 持續交付 267
9.5.2 持續部署流水線 268
9.5.3 基于開源打造流水線 268
9.5.4 Amazon的流水線 271
9.5.5 開發人員自服務 271
9.6 為什么需要AIOps 272
9.7 基于數據和反饋持續改進 273
9.8 擁抱變化 274
9.9 代碼即設計 274
第10章 團隊文化 276
10.1 為什么團隊文化如此重要 276

10.2 組織結構 278
10.2.1 團隊規模導致的問題 278
10.2.2 康威定律 278
10.2.3 扁平化的組織 279
10.2.4 獨裁的管理方式還是民主的管理方式 280
10.2.5 民主的團隊如何做決策 282
10.3 環境氛圍 282
10.3.1 公開透明的工作環境 282
10.3.2 學習型組織 283
10.3.3 減少正式的匯報 284
10.3.4 高效的會議 284
10.3.5 量化指標致死 286
10.4 管理風格 287
10.4.1 下屬請假你會拒絕嗎 287
10.4.2 為什么你招不到你想要的人 288
10.4.3 得到了所有人的認可,說明你并不是一個好的管理者 291
10.4.4 盡量避免用自己的權力去做決策 291
10.4.5 一屋不掃也可助你“蕩平天下” 292
10.4.6 如何留下你想要的人 293
10.5 經典案例 294
10.5.1 Instagram的團隊文化 294
10.5.2 Netflix的團隊文化 294
序: