相關商品
商品簡介
作者簡介
序
目次
商品簡介
雲化架構是一個全新概念，包含微服務、十二因子、敏捷基礎設施和持續交付這些新老熱點。而Cloud Native則是目前實現雲化架構最有希望的技術解決方案，其建築在傳統Cloud的三層（IaaS、PaaS、SaaS）概念之上，其中敏捷基礎設施對應IaaS部分，微服務則可以對應PaaS和SaaS部分。本書內容基於Cloud Native原理展開，重點描述雲化架構的組成部分，及其相關理論和實踐。本書來自作者在實際工作的經驗積累，內容既有經典理論，又有豐富的實戰案例，更不乏關鍵問題的完整解決方案。
作者簡介
王啟軍，目前就職于華為公司架構部，負責華為公司的Cloud Native、微服務架構推進落地，前後參與了華為手機祥雲4.0、物聯網IoT 2.0的架構設計。曾任當當架構師，主導電商平臺架構設計，包括訂單、支付、價格、庫存、物流等。曾就職於搜狐，負責手機微博的研發。十餘年的技術歷練，也曾作為技術負責人帶領過近百人的團隊。公眾號“奔跑中的蝸牛”的作者。
序
序
架構沒有絕對的對與錯
在技術的領域裡，並不存在“上帝”。沒有人的每句話都是對的，沒有人的所有思想都能被別人所接受。
我經常在公司範圍內培訓，首先是灌輸架構思想和解決方案，然後會在實戰演練中模擬一個比較簡單的業務場景，把所有人分成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的關鍵技能。無論如何，都希望此書能給你帶來較好的體驗，使你獲得啟發。
書中的內容大多來自我的工作經驗，不免存在遺漏及錯誤，歡迎指正。讀者可以直接發送郵件到我的郵箱（41309975@qq.com），在此提前表示感謝。
感謝工作中的各位同事、生活中的各位好友，正是他們的支持和鼓勵，才讓本書完成。更要感謝我的家人，特別是我的妻子和女兒，是她們的擁抱和燦爛的笑容讓我堅定了信念。
王啟軍
輕鬆註冊成為博文視點社區用戶（www.broadview.com.cn），掃碼直達本書頁面。
? 提交勘誤：您對書中內容的修改意見可在 提交勘誤 處提交，若被採納，將獲贈博文視點社區積分（在您購買電子書時，積分可用來抵扣相應金額）。
? 交流互動：在頁面下方 讀者評論 處留下您的疑問或觀點，與我們和其他讀者一同學習交流。
頁面入口：http://www.broadview.com.cn/35120
架構沒有絕對的對與錯
在技術的領域裡，並不存在“上帝”。沒有人的每句話都是對的，沒有人的所有思想都能被別人所接受。
我經常在公司範圍內培訓，首先是灌輸架構思想和解決方案，然後會在實戰演練中模擬一個比較簡單的業務場景，把所有人分成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的關鍵技能。無論如何，都希望此書能給你帶來較好的體驗，使你獲得啟發。
書中的內容大多來自我的工作經驗，不免存在遺漏及錯誤，歡迎指正。讀者可以直接發送郵件到我的郵箱（41309975@qq.com），在此提前表示感謝。
感謝工作中的各位同事、生活中的各位好友，正是他們的支持和鼓勵，才讓本書完成。更要感謝我的家人，特別是我的妻子和女兒，是她們的擁抱和燦爛的笑容讓我堅定了信念。
王啟軍
輕鬆註冊成為博文視點社區用戶（www.broadview.com.cn），掃碼直達本書頁面。
? 提交勘誤：您對書中內容的修改意見可在 提交勘誤 處提交，若被採納，將獲贈博文視點社區積分（在您購買電子書時，積分可用來抵扣相應金額）。
? 交流互動：在頁面下方 讀者評論 處留下您的疑問或觀點，與我們和其他讀者一同學習交流。
頁面入口：http://www.broadview.com.cn/35120
目次
目 錄
第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 Re
第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 Re
您曾經瀏覽過的商品
購物須知
大陸出版品因裝訂品質及貨運條件與台灣出版品落差甚大，除封面破損、內頁脫落等較嚴重的狀態，其餘商品將正常出貨。
特別提醒：部分書籍附贈之內容(如音頻mp3或影片dvd等)已無實體光碟提供，需以QR CODE 連結至當地網站註冊“並通過驗證程序”，方可下載使用。
無現貨庫存之簡體書，將向海外調貨：
海外有庫存之書籍，等候約45個工作天;
海外無庫存之書籍，平均作業時間約60個工作天，然不保證確定可調到貨，尚請見諒。
為了保護您的權益，「三民網路書店」提供會員七日商品鑑賞期(收到商品為起始日)。
若要辦理退貨，請在商品鑑賞期內寄回，且商品必須是全新狀態與完整包裝(商品、附件、發票、隨貨贈品等)否則恕不接受退貨。