第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

序：架構沒有的對與錯

在技術的領域裡，並不存在“上帝”。沒有人的每句話都是對的，沒有人的所有思想都能被別人所接受。

我經常在公司範圍內培訓，首先是灌輸架構思想和解決方案，然後會在實戰演練中模擬一個比較簡單的業務場景，把所有人分成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），在此提前表示感謝。

感謝工作中的各位同事、生活中的各位好友，正是他們的支持和鼓勵，纔讓本書完成。更要感謝我的家人，特別是我的妻子和女兒，是她們的擁抱和燦爛的笑容讓我堅定了信念。

推薦序一：雲端應用時代之光

寫書殊為不易，分享精神更是難能可貴。我一直堅定地認為，能把自己的技術經驗寫成一本公開出版的技術書籍是件非常了不起的事，因此對寫書的朋友總會肅然起敬，對創作了多本技術書籍的朋友更是高山仰止。啟軍是我在當當時的同事，我對他的獨到思維和行動力印像深刻，作為架構師他推動了產品線架構的演化升級，這樣的同事令人興奮。如今他從一線實踐經驗出發，結合行業主流技術發展趨勢總結出自己的繫統思考。具體而言，啟軍為雲原生技術架構體繫著書立說，在IT技術的浪潮之巔做布道師，給了我一個大大的驚喜。與這樣努力的朋友為伍，我哪敢不持續學習和成長呢？

雲原生架構是IT技術在雲計算時代的進化升級，標志著雲端應用進入成熟階段。技術的價值是高效穩定、快速響應、驅動甚至引領業務發展，避免疊見層出，以及減少工作量。成規模的繫統和團隊需要與之匹配的技術體繫。雲計算興起之時，有人說：“未來技術人員會分成兩種，一種是構建雲的，另一種是基於雲構建應用的”。那時還沒有成熟的雲解決方案，對雲計算的暢想也隻能局限於原有的技術產品。如今雲計算時代已經到來，應運而生並經過時間錘煉的雲原生技術是這個時代的熱點，因此技術人員隻有與時俱進、更新技能，纔能走向未來。

架構持續演進，技術也會更新換代，也許幾年後書中的許多名詞都會成為歷史，而書中所介紹的架構處理方法和思考問題的角度依然有借鋻意義。互聯網時代的IT技術一直在加速演進，多種產品協同形成體繫，技術人員進階需要掌握整套技術棧。通過本書，我們不僅能夠掌握雲原生的各個關鍵組件，更能理解架構設計的思想，掌握技術架構持續演進的過程，以及其與團隊文化、研發流程的共存互生的關繫。從開發編碼晉級到架構設計，需要提升認知、開闊視野，相信會有很多同道中人，在多年後回首來時的路，會想起這本書對自己的幫助，想起那些在字裡行間有所得的剎那，心中暗喜，轉身昂首闊步向前！

——史海峰
公眾號“IT民工閑話”作者

推薦序二

我有幸和啟軍共事一年多，總是被他對工作的執著和敏銳的技術洞察力深深震撼。啟軍在技術分享時說過一句話“有人告訴你答案，但沒人代替你思考”，這句話引發了大家的共鳴，而他對業務的思考十分全面，推動了公司整體架構水平的持續提升。本書中提到的分布式UUID、JOB 調度、消息隊列和集群緩存，不僅依然在高效平穩地運行，而且幫助公司架構從基礎組件演進到了雲平臺，並對外提供平臺級服務。這充分展現了啟軍對架構持續演進的前瞻性。啟軍對業務端服務的剝離和抽像使得上百萬數量級的商品變價可以實時實現，時效性和高可用在啟軍的設計中體現得淋漓盡致，這些在書中都有介紹。

啟軍耿直的工作作風和開放的心態，使得大家與他的合作都非常高效。各服務場景自己驗證壓力情況，破壞性測試恢復機制，如何做平衡方案，本書也都有詳細介紹。這本書真正體現了實踐的價值，為架構的持續演進做了鋪路石，更為依然奮鬥在雲原生路上的朋友們提供了實踐指南。不論是剛開始接觸業務開發的同學，還是已經有多年實戰經驗的專家，閱讀本書都會有醍醐灌頂之感。

——劉利川
當當高級技術總監

本書總結了作者的工作經驗，望讀者在借鋻技術細節的同時，也不忘作者的初心：微服務架構是持續演進的，更是一種開發文化的體現。

——徐振中 Netflix 架構師

以往的雲原生編程書籍尚未形成雲原生的理論體繫，也缺少雲原生的*實踐，而本書分別從架構、研發流程、團隊文化三個角度論述雲原生，可以為企業或組織從單體架構過度到雲原生架構提供*實踐，更加具有現實的指導意義。

——宋淨超
《雲原生Java》譯者、螞蟻金服架構師

啟軍在書中提到“好的架構是錘煉出來的，而不僅僅是設計出來的。”對這句話我深信不疑，也一直這樣踐行。錘煉一個好的架構需要掌握非常豐富的知識，一本好書可以加快成長速度。啟軍是我非常敬佩的架構專家，Cloud Native 是一個非常大的概念，他能把這個概念講得明白、清晰、透徹，可見其功力之深厚。我堅信它一定是讀者們期盼已久的讀物。

——黃勇
《架構探險》作者、特贊科技 CTO

在實施微服務時，*容易犯的錯誤就是，隻關注微服務技術框架本身，而丟失了全局觀。如果沒有配套的微服務流水線、基礎設施自動化，以及對應的服務化團隊和組織結構轉型，那麼微服務帶來的收益很難達到預期。本書從全局視角出發，高屋建瓴，涵蓋了 CloudNative 的關鍵技術，以及衍生出的工具、團隊文化等關鍵要素，對於開展雲原生業務的企業和組織具有極高的參考和學習價值。

——李林鋒
《分布式服務框架原理與實踐》作者、華為消費者雲微服務架構師

萬事萬物應該盡量簡單，而不是更簡單。從單體架構演進到雲原生架構所帶來的技術變革，都是為了解決快速變化的業務帶來的不確定性問題。簡而言之，有什麼樣的業務就有什麼樣的技術與其相適應。但是僅僅知道這樣一個簡單的結論，並不能指導我們解決工作中遇到的實際問題。本書比較全面地介紹了微服務架構演進的原則與實踐，闡述了分布式架構帶來的數據一致性問題的解決方案。希望本書能幫助讀者解決不同的業務場景下遇到的實際問題。

——萬金
《DevOps 實施手冊：在多級 IT 企業中使用 DevOps》譯者，曾在 IBM、華為和 ThoughtWorks從事 DevOps 的實施與推廣工作

啟軍有著豐富的軟件開發和管理經驗，對軟件開發架構設計有自己獨到的見解，書中的內容都是他從十幾年的工作中獲得的實戰經驗。這*是一本值得認真閱讀的好書，我強烈力薦！

——馬寶輝
亞馬遜中國數據工程師

雲原生（Cloud Native）由 Pivotal 公司於 2013 年提出之後，先後開源了雲原生的 Java開發框架 Spring Boot 和 Spring Cloud，隨後 Google 在 2015 年成立了 CNCF，使其受到越來越廣泛的關注。雲原生不僅僅是研發技能或架構設計，它的本質是一種模式，它要求雲原生應用滿足可用性和伸縮性，具備自動化部署和管理能力，可隨處運行，並且能夠通過

持續集成及持續交付工具提高研發、測試與發布的效率。本書細致地將雲原生的理念、所需技術、研發流程及團隊文化融合在一起，能夠幫助讀者快速準確地理解雲原生的精髓。

——張亮
*金融數據研發負責人、開源分布式數據庫中間件 Sharding-Sphere 的負責人