[美] 克里斯·理查森(Chris Richardson) 著,喻勇 譯
適讀人群 :本書的重點是架構(gòu)和開發(fā),適合負責開發(fā)和交付軟件的任何人(例如開發(fā)人員、架構(gòu)師、 CTO等)閱讀。示例代碼使用Java語言和Spring框架
本書由世界十大軟件架構(gòu)師之一、微服務架構(gòu)的先驅(qū)、Java開發(fā)者社區(qū)的意見領(lǐng)袖Chris Richardson親筆撰寫,旨在幫助架構(gòu)師和程序員學會使用微服務架構(gòu)成功開發(fā)應用程序。書中描述了如何解決我們將面臨的眾多架構(gòu)設(shè)計挑戰(zhàn),包括如何管理分布式數(shù)據(jù),還介紹了如何將單體應用程序重構(gòu)為微服務架構(gòu),涵蓋44個架構(gòu)設(shè)計模式,系統(tǒng)解決服務拆分、事務管理、查詢和跨服務通信等難題。本書并不是鼓吹微服務架構(gòu)的宣言,作者既介紹了微服務的原理、原則,又詳細講解了實際落地中的架構(gòu)設(shè)計模式,將使你理解微服務架構(gòu)、它的好處和弊端,以及應該何時使用微服務架構(gòu)。本書將幫助你建立微服務的全局視野,并學會在紛繁復雜的情況下做出正確的架構(gòu)選擇和取舍。
本書將教會你如何開發(fā)和部署生產(chǎn)級別的微服務架構(gòu)應用。這套寶貴的架構(gòu)設(shè)計模式建立在數(shù)十年的分布式系統(tǒng)經(jīng)驗之上,Chris還為開發(fā)服務添加了新的模式,并將它們組合成可在真實條件下可靠地擴展和執(zhí)行的系統(tǒng)。本書不僅僅是一個模式目錄,還提供了經(jīng)驗驅(qū)動的建議,以幫助你設(shè)計、實現(xiàn)、測試和部署基于微服務的應用程序。
本書包含:
●如何(以及為什么)使用微服務架構(gòu)
●服務拆分的策略
●事務管理和查詢相關(guān)的模式
●高效的測試策略
●包括容器和Serverless在內(nèi)的部署模式
本書專為熟悉標準企業(yè)應用程序架構(gòu)的開發(fā)人員編寫,使用Java語言和Spring框架編寫所有示例代碼。
成功地開發(fā)基于微服務架構(gòu)的應用軟件,需要掌握一系列全新的架構(gòu)思想和實踐。在這本獨特的書籍中,世界十大軟件架構(gòu)師之一、微服務架構(gòu)先驅(qū)Chris Richardson收集、分類并解釋了44個架構(gòu)設(shè)計模式,這些模式用來解決諸如服務拆分、事務管理、查詢和跨服務通信等難題。
本書的目標是讓架構(gòu)師和程序員學會使用微服務架構(gòu)成功開發(fā)應用程序。
書中不僅討論了微服務架構(gòu)的好處,還描述了它們的弊端。讀者將掌握如何在使用單體架構(gòu)和使用微服務架構(gòu)之間做出正確的權(quán)衡。
【誰應該閱讀本書】
本書的重點是架構(gòu)和開發(fā),適合負責開發(fā)和交付軟件的任何人(例如開發(fā)人員、架構(gòu)師、CTO 等)閱讀。
本書側(cè)重于解釋微服務架構(gòu)的設(shè)計模式和其他概念。無論讀者使用何種技術(shù)棧,我的目標都是讓你們可以輕松讀懂這本書。你只需要熟悉企業(yè)應用程序架構(gòu)和設(shè)計的基礎(chǔ)知識即可。特別是,需要了解三層架構(gòu)、Web 應用程序設(shè)計、關(guān)系型數(shù)據(jù)庫、使用消息和基于 REST 的進程間通信,以及應用程序安全性的基礎(chǔ)知識等概念。本書的代碼示例使用 Java 和 Spring 框架。為了充分利用它們,讀者應該對 Spring 框架有所了解。
【本書內(nèi)容安排】
本書由13章組成。
●第1章描述了所謂“單體地獄”的癥狀,當單體應用程序超出其架構(gòu)時會出現(xiàn)這種問題,這可以通過采用微服務架構(gòu)來規(guī)避。這一章還概述了微服務架構(gòu)模式語言,這也是本書大部分內(nèi)容的主題。
●第2章解釋了為什么軟件架構(gòu)很重要,描述了可用于將應用程序分解為服務集合的模式,并解釋了如何克服在此過程中遇到的各種障礙。
●第3章介紹了微服務架構(gòu)中強大的進程間通信的幾種模式,解釋了為什么異步和基于消息的通信通常是最佳選擇。
●第4章介紹如何使用 Saga 模式維護服務間的數(shù)據(jù)一致性。Saga 是通過傳遞異步消息的方式進行協(xié)調(diào)的一系列本地事務。
●第5章介紹如何使用領(lǐng)域驅(qū)動設(shè)計(DDD)的聚合和領(lǐng)域事件等模式為服務設(shè)計業(yè)務邏輯。
●第6章以第5章為基礎(chǔ),解釋了如何使用事件溯源模式開發(fā)業(yè)務邏輯,事件溯源模式是一種以事件為中心的設(shè)計思路,用來構(gòu)建業(yè)務邏輯和持久化領(lǐng)域?qū)ο蟆?/p>
●第7章介紹如何使用API組合模式或命令查詢職責隔離(CQRS)模式,這兩個模式用來實現(xiàn)查詢分散在多個服務中的數(shù)據(jù)。
●第8章介紹了處理來自各種外部客戶端請求的外部 API 模式,例如移動應用程序、基于瀏覽器的 JavaScript 應用程序和第三方應用程序。
●第9章是關(guān)于微服務自動化測試技術(shù)的兩章中的第一章,介紹了重要的測試概念,例如測試金字塔,描述了測試套件中每種測試類型的相對比例,還展示了如何編寫構(gòu)成測試金字塔基礎(chǔ)的單元測試。
●第10章以第9章為基礎(chǔ),描述了如何在測試金字塔中編寫其他類型的測試,包括集成測試、消費者契約測試和組件測試等。
●第11章介紹了開發(fā)生產(chǎn)就緒服務的各個方面,包括安全性、外部化配置模式和服務可觀測性模式。服務可觀測性模式包括日志聚合、應用指標和分布式追蹤。
●第12章介紹了可用于部署服務的各種部署模式,包括虛擬機、容器和 Serverless 模式。還介紹了使用服務網(wǎng)格的好處,服務網(wǎng)格是在微服務架構(gòu)中處理服務間通信的一個網(wǎng)絡軟件層。
●第13章介紹了如何通過采用絞殺者(Strangler)模式逐步將單體架構(gòu)重構(gòu)為微服務架構(gòu),絞殺者模式是指以服務形式實現(xiàn)新功能,從單體中提取模塊將其轉(zhuǎn)換為服務。
在學習這些章節(jié)的過程中,讀者將了解微服務架構(gòu)的不同方面。
克里斯·理查森(Chris Richardson)
世界十大軟件架構(gòu)師之一,《POJOS in Action》等技術(shù)名著的作者,也是著名開源項目 Cloud Foundry 和 Eventuate 的創(chuàng)始人。他的研究領(lǐng)域包括微服務架構(gòu)設(shè)計、分布式數(shù)據(jù)管理、事件驅(qū)動的應用架構(gòu)、領(lǐng)域驅(qū)動設(shè)計、持續(xù)交付、Spring 框架、Scala、NoSQL 數(shù)據(jù)庫等。
喻勇
在技術(shù)圈馳騁多年,曾擔任過微軟技術(shù)布道師,VMware Cloud Foundry生態(tài)建設(shè)負責人,并有幸引領(lǐng)了國內(nèi)容器技術(shù)的創(chuàng)業(yè)浪潮。目前定居加拿大,關(guān)注微服務架構(gòu)、云原生應用等領(lǐng)域。
Chris與喻勇曾在VMware全球開發(fā)者關(guān)系團隊共事多年,現(xiàn)在他們合作為國內(nèi)企業(yè)客戶提供微服務相關(guān)的咨詢和培訓服務,他們的中文網(wǎng)站是:www.chrisrichardson.cn
“全面概述了團隊在轉(zhuǎn)向微服務時面臨的挑戰(zhàn),以及針對這些問題的、經(jīng)過行業(yè)檢驗的解決方案。”
——Tim Moore,Lightbend
“系統(tǒng)性地闡述了一個重要的架構(gòu)領(lǐng)域。”
——Simeon Leyzerzon,Excelsior Software
“一本可靠的手冊,可以加快你遷移到這個基于云的現(xiàn)代架構(gòu)的速度?!?/p>
——John Guthrie,Dell/EMC
“可幫你理解微服務方法并在現(xiàn)實生活中使用它?!?/p>
——Potito Coluccelli,Bizmatica Econocom
“喻勇翻譯的這本書是近幾年我所看到的眾多論述微服務架構(gòu)書籍中好的一本。該書圍繞微服務的架構(gòu)設(shè)計,深入淺出地介紹了微服務與SOA等其他架構(gòu)的區(qū)別,軟件系統(tǒng)服務的拆分策略,微服務的同步和異步通信模式,如何使用微服務進行事務管理,如何在微服務架構(gòu)中設(shè)計業(yè)務邏輯。同時詳細描述了微服務架構(gòu)中的測試和生產(chǎn)部署策略。該書所總結(jié)出的架構(gòu)經(jīng)驗對設(shè)計微服務架構(gòu)有很好的指導作用,建議軟件研發(fā)人員認真研讀?!?/p>
——陳斌,易寶支付CTO
“這本書里,不僅有微服務領(lǐng)域已經(jīng)識別出來的問題、解決思路和解決方案,也有相應的代碼例子。這本書可以幫助微服務相關(guān)人員構(gòu)建知行合一的能力……這是一本可以幫你在設(shè)計微服務架構(gòu)時做出取舍的書,它能在你處理微服務相關(guān)問題“左右為難”的時候給你提供參考和建議?!?/p>
——蔡書,獨立顧問,PolarisTech聯(lián)合創(chuàng)始人
“書中既包含了微服務的原理、原則,又包含了實際落地中的架構(gòu)設(shè)計模式;既包含可舉一反三的理念和概念,也包含類似領(lǐng)域驅(qū)動設(shè)計、Saga實現(xiàn)事務操作、CQRS構(gòu)建事件驅(qū)動系統(tǒng)等具體可套用的范式……相信本書對于企業(yè)CIO推動公司數(shù)字化轉(zhuǎn)型戰(zhàn)略、軟件開發(fā)者提升自身技術(shù)架構(gòu)功力,以及云原生愛好者以微服務切入新的云原生體系,都有著極其重要的實踐指導意義?!?/p>
——張鑫,才云科技CEO
●第1章逃離單體地獄/1
1.1邁向單體地獄的漫長旅程/2
1.1.1FTGO應用程序的架構(gòu)/3
1.1.2單體架構(gòu)的好處/4
1.1.3什么是單體地獄/4
1.2為什么本書與你有關(guān)/7
1.3你會在本書中學到什么/8
1.4拯救之道:微服務架構(gòu)/8
1.4.1擴展立方體和服務/9
1.4.2微服務架構(gòu)作為模塊化的一種形式/11
1.4.3每個服務都擁有自己的數(shù)據(jù)庫/12
1.4.4FTGO的微服務架構(gòu)/12
1.4.5微服務架構(gòu)與SOA的異同/14
1.5微服務架構(gòu)的好處和弊端/15
1.5.1微服務架構(gòu)的好處/15
1.5.2微服務架構(gòu)的弊端/17
1.6微服務架構(gòu)的模式語言/19
1.6.1微服務架構(gòu)并不是“銀彈”/20
1.6.2模式和模式語言/21
1.6.3微服務架構(gòu)的模式語言概述/24
1.7微服務之上:流程和組織/29
1.7.1進行軟件開發(fā)和交付的組織/30
1.7.2進行軟件開發(fā)和交付的流程/31
1.7.3采用微服務架構(gòu)時的人為因素/32
●第2章服務的拆分策略/34
2.1微服務架構(gòu)到底是什么/35
2.1.1軟件架構(gòu)是什么,為什么它如此重要/35
2.1.2什么是架構(gòu)的風格/37
2.1.3微服務架構(gòu)是一種架構(gòu)風格/40
2.2為應用程序定義微服務架構(gòu)/43
2.2.1識別系統(tǒng)操作/45
2.2.2根據(jù)業(yè)務能力進行服務拆分/50
2.2.3根據(jù)子域進行服務拆分/53
2.2.4拆分的指導原則/54
2.2.5拆分單體應用為服務的難點/56
2.2.6定義服務API/59
●第3章微服務架構(gòu)中的進程間通信/63
3.1微服務架構(gòu)中的進程間通信概述/64
3.1.1交互方式/64
3.1.2在微服務架構(gòu)中定義API/66
3.1.3API的演化/67
3.1.4消息的格式/69
3.2基于同步遠程過程調(diào)用模式的通信/70
3.2.1使用REST/71
3.2.2使用gRPC/74
3.2.3使用斷路器模式處理局部故障/75
3.2.4使用服務發(fā)現(xiàn)/78
3.3基于異步消息模式的通信/82
3.3.1什么是消息傳遞/83
3.3.2使用消息機制實現(xiàn)交互方式/84
3.3.3為基于消息機制的服務API創(chuàng)建API規(guī)范/86
3.3.4使用消息代理/87
3.3.5處理并發(fā)和消息順序/91
3.3.6處理重復消息/92
3.3.7事務性消息/93
3.3.8消息相關(guān)的類庫和框架/97
3.4使用異步消息提高可用性/99
3.4.1同步消息會降低可用性/99
3.4.2消除同步交互/101
●第4章使用Saga管理事務/106
4.1微服務架構(gòu)下的事務管理/107
4.1.1微服務架構(gòu)對分布式事務的需求/108
4.1.2分布式事務的挑戰(zhàn)/109
4.1.3使用Saga模式維護數(shù)據(jù)一致性/109
4.2Saga的協(xié)調(diào)模式/113
4.2.1協(xié)同式Saga/113
4.2.2編排式Saga/117
4.3解決隔離問題/121
4.3.1缺乏隔離導致的問題/122
4.3.2Saga模式下實現(xiàn)隔離的對策/123
4.4OrderService和CreateOrderSaga的設(shè)計/127
4.4.1OrderService類/128
4.4.2CreateOrderSaga的實現(xiàn)/129
4.4.3OrderCommandHandlers類/136
4.4.4OrderServiceConfiguration類/138
●第5章微服務架構(gòu)中的業(yè)務邏輯設(shè)計/141
5.1業(yè)務邏輯組織模式/142
5.1.1使用事務腳本模式設(shè)計業(yè)務邏輯/143
5.1.2使用領(lǐng)域模型模式設(shè)計業(yè)務邏輯/144
5.1.3關(guān)于領(lǐng)域驅(qū)動設(shè)計/146
5.2使用聚合模式設(shè)計領(lǐng)域模型/146
5.2.1模糊邊界所帶來的問題/147
5.2.2聚合擁有明確的邊界/149
5.2.3聚合的規(guī)則/150
5.2.4聚合的顆粒度/152
5.2.5使用聚合設(shè)計業(yè)務邏輯/153
5.3發(fā)布領(lǐng)域事件/154
5.3.1為什么需要發(fā)布變更事件/154
5.3.2什么是領(lǐng)域事件/155
5.3.3事件增強/155
5.3.4識別領(lǐng)域事件/156
5.3.5生成和發(fā)布領(lǐng)域事件/157
5.3.6消費領(lǐng)域事件/161
5.4KitchenService的業(yè)務邏輯/162
5.5OrderService的業(yè)務邏輯/167
5.5.1Order聚合/169
5.5.2OrderService類/173
●第6章使用事件溯源開發(fā)業(yè)務邏輯/176
6.1使用事件溯源開發(fā)業(yè)務邏輯概述/177
6.1.1傳統(tǒng)持久化技術(shù)的問題/177
6.1.2什么是事件溯源/179
6.1.3使用樂觀鎖處理并發(fā)更新/186
6.1.4事件溯源和發(fā)布事件/186
6.1.5使用快照提升性能/188
6.1.6冪等方式的消息處理/189
6.1.7領(lǐng)域事件的演化/190
6.1.8事件溯源的好處/192
6.1.9事件溯源的弊端/193
6.2實現(xiàn)事件存儲庫/194
6.2.1EventuateLocal事件存儲庫的工作原理/195
6.2.2Eventuate的Java客戶端框架/198
6.3同時使用Saga和事件溯源/201
6.3.1使用事件溯源實現(xiàn)協(xié)同式Saga/203
6.3.2創(chuàng)建編排式Saga/203
6.3.3實現(xiàn)基于事件溯源的Saga參與方/205
6.3.4實現(xiàn)基于事件溯源的Saga編排器/208
●第7章在微服務架構(gòu)中實現(xiàn)查詢/212
7.1使用API組合模式進行查詢/213
7.1.1findOrder()查詢操作/213
7.1.2什么是API組合模式/214
7.1.3使用API組合模式實現(xiàn)findOrder()查詢操作/215
7.1.4API組合模式的設(shè)計缺陷/216
7.1.5API組合模式的好處和弊端/219
7.2使用CQRS模式/220
7.2.1為什么要使用CQRS/220
7.2.2什么是CQRS/223
7.2.3CQRS的好處/226
7.2.4CQRS的弊端/227
7.3設(shè)計CQRS視圖/228
7.3.1選擇視圖存儲庫/229
7.3.2設(shè)計數(shù)據(jù)訪問模塊/230
7.3.3添加和更新CQRS視圖/232
7.4實現(xiàn)基于AWSDynamoDB的CQRS視圖/233
7.4.1OrderHistoryEventHandlers模塊/234
7.4.2DynamoDB中的數(shù)據(jù)建模和查詢設(shè)計/235
7.4.3OrderHistoryDaoDynamoDb類/239
●第8章外部API模式/244
8.1外部API的設(shè)計難題/245
8.1.1FTGO移動客戶端API的設(shè)計難題/246
8.1.2其他類型客戶端API的設(shè)計難題/248
8.2APIGateway模式/250
8.2.1什么是APIGateway模式/250
8.2.2APIGateway模式的好處和弊端/256
8.2.3以Netflix為例的APIGateway/257
8.2.4APIGateway的設(shè)計難題/258
8.3實現(xiàn)一個APIGateway/260
8.3.1使用現(xiàn)成的APIGateway產(chǎn)品或服務/261
8.3.2開發(fā)自己的APIGateway/262
8.3.3使用GraphQL實現(xiàn)APIGateway/269
●第9章微服務架構(gòu)中的測試策略(上)/282
9.1微服務架構(gòu)中的測試策略概述/284
9.1.1什么是測試/284
9.1.2微服務架構(gòu)中的測試挑戰(zhàn)/289
9.1.3部署流水線/295
9.2為服務編寫單元測試/296
9.2.1為實體編寫單元測試/298
9.2.2為值對象編寫單元測試/299
9.2.3為Saga編寫單元測試/300
9.2.4為領(lǐng)域服務編寫單元測試/302
9.2.5為控制器編寫單元測試/303
9.2.6為事件和消息處理程序編寫單元測試/305
●第10章微服務架構(gòu)中的測試策略(下)/308
10.1編寫集成測試/308
10.1.1針對持久化層的集成測試/311
10.1.2針對基于REST的請求/響應式交互的集成測試/312
10.1.3針對發(fā)布/訂閱式交互的集成測試/316
10.1.4針對異步請求/響應式交互的集成契約測試/320
10.2編寫組件測試/324
10.2.1定義驗收測試/325
10.2.2使用Gherkin編寫驗收測試/326
10.2.3設(shè)計組件測試/328
10.2.4為FTGO的OrderService編寫組件測試/330
10.3端到端測試/334
10.3.1設(shè)計端到端測試/335
10.3.2編寫端到端測試/335
10.3.3運行端到端測試/336
●第11章開發(fā)面向生產(chǎn)環(huán)境的微服務應用/338
11.1開發(fā)安全的服務/339
11.1.1傳統(tǒng)單體應用程序的安全性/340
11.1.2在微服務架構(gòu)中實現(xiàn)安全性/343
11.2設(shè)計可配置的服務/349
11.2.1使用基于推送的外部化配置/350
11.2.2使用基于拉取的外部化配置/352
11.3設(shè)計可觀測的服務/353
11.3.1使用健康檢查API模式/355
11.3.2使用日志聚合模式/357
11.3.3使用分布式追蹤模式/358
11.3.4使用應用程序指標模式/361
11.3.5使用異常追蹤模式/364
11.3.6使用審計日志模式/365
11.4使用微服務基底模式開發(fā)服務/367
11.4.1使用微服務基底/368
11.4.2從微服務基底到服務網(wǎng)格/368
●第12章部署微服務應用/371
12.1部署模式:編程語言特定的發(fā)布包格式/374
12.1.1使用編程語言特定的發(fā)布包格式進行部署的好處/376
12.1.2使用編程語言特定的發(fā)布包格式進行部署的弊端/377
12.2部署模式:將服務部署為虛擬機/378
12.2.1將服務部署為虛擬機的好處/380
12.2.2將服務部署為虛擬機的弊端/380
12.3部署模式:將服務部署為容器/381
12.3.1使用Docker部署服務/383
12.3.2將服務部署為容器的好處/385
12.3.3將服務部署為容器的弊端/386
12.4使用Kubernetes部署FTGO應用程序/386
12.4.1什么是Kubernetes/386
12.4.2在Kubernetes上部署RestaurantService/389
12.4.3部署APIGateway/392
12.4.4零停機部署/393
12.4.5使用服務網(wǎng)格分隔部署與發(fā)布流程/394
12.5部署模式:Serverless部署/402
12.5.1使用AWSLambda進行Serverless部署/403
12.5.2開發(fā)Lambda函數(shù)/404
12.5.3調(diào)用Lambda函數(shù)/404
12.5.4使用Lambda函數(shù)的好處/405
12.5.5使用Lambda函數(shù)的弊端/406
12.6使用AWSLambda和AWSGateway部署RESTful服務/406
12.6.1AWSLambda版本的RestaurantService/407
12.6.2把服務打包為ZIP文件/411
12.6.3使用Serverless框架部署Lambda函數(shù)/412
●第13章微服務架構(gòu)的重構(gòu)策略/415
13.1重構(gòu)到微服務需要考慮的問題/416
13.1.1為什么要重構(gòu)單體應用/416
13.1.2絞殺單體應用/417
13.2將單體應用重構(gòu)為微服務架構(gòu)的若干策略/420
13.2.1將新功能實現(xiàn)為服務/420
13.2.2隔離表現(xiàn)層與后端/422
13.2.3提取業(yè)務能力到服務中/423
13.3設(shè)計服務與單體的協(xié)作方式/429
13.3.1設(shè)計集成膠水/430
13.3.2在服務和單體之間維持數(shù)據(jù)一致性/434
13.3.3處理身份驗證和訪問授權(quán)/438
13.4將新功能實現(xiàn)為服務:處理錯誤配送訂單/440
13.4.1DelayedDeliveryService的設(shè)計/441
13.4.2為DelayedDeliveryService設(shè)計集成膠水/442
13.5從單體中提取送餐管理功能/444
13.5.1現(xiàn)有的送餐管理功能/444
13.5.2DeliveryService概覽/446
13.5.3設(shè)計DeliveryService的領(lǐng)域模型/447
13.5.4DeliveryService集成膠水的設(shè)計/450
13.5.5修改FTGO單體使其能夠與DeliveryService交互/451
【寫給中文版讀者的話】
7年前,我?guī)е鴮γ朗澈图夹g(shù)的熱情,開始了我的首次中國之旅。在那之前,我對中國的美食和軟件社區(qū)都知之甚少。7年之后,經(jīng)過多次中國之行,我對這兩者都有了深刻的認識:我愛上了地道的中國菜,也對中國的軟件開發(fā)者印象深刻。
2012年我首次訪問中國,參加我在VMware公司的同事Frank舉辦的幾場開發(fā)者會議。我一口氣在北京和上海做了好幾場演講,包括云計算、Cloud Foundry、Node.js、Spring、NoSQL數(shù)據(jù)庫,當然,還有微服務。我與2000多位參加會議的來賓討論Cloud Foundry,這次旅行讓我意識到中國開發(fā)者社區(qū)的規(guī)模和熱情,也讓我有機會品嘗了地道的中國菜。我甚至還忙里偷閑,在北京參加了一天中餐烹飪課程。
2013年,F(xiàn)rank再次邀請我來到北京,參加中國首場SpringOne大會,發(fā)表關(guān)于微服務和NoSQL的演講。這次旅行的亮點是訪問豆瓣和百度,這是我與中國科技公司的第一次近距離接觸。他們的規(guī)模和創(chuàng)新技術(shù)都給我留下了非常深刻的印象。在這次旅行中,我參觀了北京奧林匹克公園,回憶了曾在這里舉行的2008年北京奧運會開幕式。我也抓住機會,繼續(xù)“進修”中餐烹飪課程。
這次大會結(jié)束后不久,我離開VMware公司,再次走上了創(chuàng)業(yè)的道路。我搭建了microservices.io網(wǎng)站,撰寫了大量的文章和課件,搭乘我鐘愛的United Airlines,為世界各地的客戶提供微服務架構(gòu)咨詢和培訓服務。我還創(chuàng)立了eventuate.io公司,發(fā)布了用于微服務架構(gòu)的數(shù)據(jù)訪問框架。這些工作促成了我和Frank的再度合作,我有幸在2016年4月和8月再次訪問中國。從那以后,我在中美之間多次往返,幫助中國的企業(yè)客戶實施微服務架構(gòu)。這些公司的業(yè)務多種多樣,包括保險、汽車制造、電信和企業(yè)軟件。地域上的跨度,也從北京和上海延伸到了深圳、武漢和杭州。在這些旅行中,我愛上了烤魚、新疆菜和蒙古菜。
中國企業(yè)和開發(fā)者對微服務架構(gòu)的熱情讓我印象深刻。但如同我給所有客戶的忠告一樣,我想對本書的讀者說:
第一,要記住微服務不是解決所有問題的萬能“銀彈”。
第二,編寫整潔的代碼和使用自動化測試至關(guān)重要,因為這是現(xiàn)代軟件開發(fā)的基礎(chǔ)。
第三,關(guān)注微服務的本質(zhì),即服務的分解和定義,而不是技術(shù),如容器和其他工具。
第四,確保你的服務松耦合,并且可以獨立開發(fā)、測試和部署,不要搞成分布式單體(Distributed Monolith),那將會是巨大的災難。
第五,也是最重要的,不能只是在技術(shù)上采用微服務架構(gòu)。擁抱DevOps的原則和實踐,在組織結(jié)構(gòu)上實現(xiàn)跨職能的自治團隊,這必不可少。
還必須記?。簩崿F(xiàn)微服務架構(gòu)并不是你的目標。你的目標是加速大型復雜應用程序的開發(fā)。
最后,我要感謝中國的所有客戶,讓我有機會與你們探討微服務。我還要感謝那些讓我能夠討論技術(shù)而不用學說中文(這可比微服務難多了)的同傳翻譯。我希望你會喜歡閱讀這本書,它會教你如何成功開發(fā)微服務。我期待著再次訪問中國,與我的讀者見面,幫助更多企業(yè)客戶實施微服務架構(gòu)。
Chris Richardson
2019年2月13日
【中文版序一】
良馬難乘,然可以任重致遠;良才難令,然可以致君見尊。
—墨子
曾經(jīng)有一個客戶把他們遇到的微服務問題列出來給我看,當時我覺得頭緒萬千但又無從說起,于是想到了墨子的這句話。
如果現(xiàn)在有人問我這個問題,那么我會推薦他們一邊看Chris Richardson的這本書,一邊在實踐中嘗試和體驗各種模式的優(yōu)勢與特點,然后大家一起討論遇到的問題并提出解決思路。
大概從五六年前開始,我在工作中越來越多地談到了微服務,并參與了一些客戶應用的微服務改造,其中不乏成功的例子,當然也有沒達到預期的情況。隨著網(wǎng)絡基礎(chǔ)設(shè)施的高速發(fā)展,以及越來越多的企業(yè)和組織需要通過互聯(lián)網(wǎng)提供服務,在考慮構(gòu)建可以支持海量請求以及多變業(yè)務的軟件平臺時,微服務架構(gòu)成為多數(shù)人的首選。微服務架構(gòu)的出現(xiàn)是符合事物發(fā)展規(guī)律的:當問題足夠大、有足夠多的不確定性因素時,人們習慣把大的問題拆分成小的問題,通過分割、抽象和重用小而可靠的功能模塊來構(gòu)建整體的方案。但是當這些小的、可重用的部分越來越多時,又會出現(xiàn)新的問題。在相似的階段,人們遇到的問題通常也是相似的,這個時候我們需要一些共識,需要用一些通用的詞匯來描述問題以及解題思路和方案,這也是人們知識的總結(jié)。微服務模式就是這樣一種總結(jié)和概括,是一種可以通用的共識,用于描述微服務領(lǐng)域中的問題及解決方案、方法和思路。這是我向大家推薦這本書的理由之一:討論微服務的時候,這本書提供了必要的共同語言。
在和Chris交流時,我深深地被他高度的思維能力所折服,尤其是對問題的深刻理解和對解決思路的高度抽象。與有敏銳思維且有高度抽象能力的人討論問題是件快樂的事情,他總是能把自己的經(jīng)驗和概括總結(jié)出的信息用清晰的方式表述出來。現(xiàn)在,他把關(guān)于微服務的這些抽象整理成了這本書??梢哉f,這是廣大微服務相關(guān)工作人員的福音。在這本書里,不僅有微服務領(lǐng)域已經(jīng)識別出來的問題、解決思路和解決方案,也有相應的代碼例子。這就使得高度抽象的內(nèi)容有了非常具體的表現(xiàn),可以幫助我們在遇到問題之前就了解可能的潛在問題;有些代碼例子甚至是可以直接使用的。這種知行合一的能力,是我欽佩Chris的又一個重要原因,也是我向大家推薦這本書的理由之二:這本書可以幫助微服務相關(guān)人員構(gòu)建知行合一的能力。
在一次關(guān)于“架構(gòu)的關(guān)鍵是什么”的討論中,我們和Chris很快達成了共識:架構(gòu)就是取舍,進而架構(gòu)師就是做出取舍的人。大家都認同,做架構(gòu)的人的特征之一應該是“Independent”(獨立),這也是我選擇做獨立解決方案進而設(shè)計產(chǎn)品的重要原因。在我們看來,只有獨立才有可能讓我們在做架構(gòu)設(shè)計時做出中立和獨特的方案。面對問題時,大多數(shù)人會希望有人可以給出“正確的”建議,但是多數(shù)時候,困擾人們的不是“什么才是正確的”,而是“取舍之間”。這正是我推薦這本書的理由之三:這是一本可以幫你在設(shè)計微服務架構(gòu)時做出取舍的書,它能在你處理微服務相關(guān)問題左右為難的時候給你提供參考和建議。
我們生活在一個高速發(fā)展的時代,微服務領(lǐng)域的技術(shù)、產(chǎn)品、模式日新月異,我們非常有幸參與和見證這個時代的發(fā)展。我們從解決昨天的問題里走出來,又走向更多的問題。在這個過程中,我們解決的問題的規(guī)模和復雜度都是成倍提升的。相信很多和我一樣喜歡體驗這種從無到有的過程、喜歡親手解決問題的成就感、喜歡用獨立思維去面對問題的人,都會喜歡這本書。在此,再次對ChrisRichardson先生表示感謝,他為這個領(lǐng)域貢獻了寶貴的知識財富。
蔡書
獨立顧問,PolarisTech聯(lián)合創(chuàng)始人
【中文版序二】
國際數(shù)據(jù)公司(IDC)研究表明,2018~2021年間,全球數(shù)字化轉(zhuǎn)型方面的直接支出將達到5.9萬億美元。埃森哲(Accenture)指出,目前在中國僅有7%的企業(yè)成功地實現(xiàn)了數(shù)字化轉(zhuǎn)型,而這些成功轉(zhuǎn)型的公司,它們的業(yè)績復合增長率是尚未轉(zhuǎn)型的同行企業(yè)的5倍之多。
數(shù)字化轉(zhuǎn)型依賴技術(shù)創(chuàng)新。美國風險投資機構(gòu)Work-Bench在《2018企業(yè)軟件調(diào)研年報》中推論:以微服務為代表的云原生技術(shù)是幫助企業(yè)實現(xiàn)有效數(shù)字化轉(zhuǎn)型的唯一技術(shù)途徑。數(shù)字化轉(zhuǎn)型背景下客戶的預期越來越高,需要企業(yè)的線上業(yè)務能快速迭代滿足動態(tài)的市場需求,并能彈性擴展應對業(yè)務的突發(fā)式增長;而微服務由于其敏捷靈活等特性成了滿足這些訴求的最佳答案。因此,微服務可成為企業(yè)進行數(shù)字化轉(zhuǎn)型的強力催化劑。
微服務的概念雖然直觀易懂,但“細節(jié)是魔鬼”,微服務在實操落地的環(huán)節(jié)中存在諸多挑戰(zhàn)。我們在為企業(yè)提供PaaS、人工智能、云原生平臺等數(shù)字化轉(zhuǎn)型解決方案時也發(fā)現(xiàn),企業(yè)實現(xiàn)云原生,并充分利用PaaS能力的第一步,往往是對已有應用架構(gòu)進行現(xiàn)代化微服務改造,而如何進行微服務拆分、設(shè)計微服務邏輯、實現(xiàn)微服務治理等實操問題成為很大的挑戰(zhàn)。
本書英文原作由微服務權(quán)威架構(gòu)師ChrisRichardson先生所著。書中既包含了微服務的原理、原則,又包含了實際落地中的架構(gòu)設(shè)計模式;既包含可舉一反三的理念和概念,也包含類似領(lǐng)域驅(qū)動設(shè)計、Saga實現(xiàn)事務操作、CQRS構(gòu)建事件驅(qū)動系統(tǒng)等具體可套用的范式。本書可以幫助讀者把傳統(tǒng)的單體巨石型應用循序漸進地改造為微服務架構(gòu),從微服務的拆分,微服務架構(gòu)下業(yè)務邏輯的設(shè)計以及事務、API、通信等的實現(xiàn),一直到微服務系統(tǒng)的測試與生產(chǎn)上線,幫助讀者建立從無到有的完整微服務系統(tǒng)搭建的生命周期。
本書譯者在云計算、云原生與微服務領(lǐng)域有多年實踐經(jīng)驗和建樹,譯文既精確地還原了原著的內(nèi)容,又結(jié)合譯者自身的理解,讓中文版本更加通俗易懂。雖身在云計算行業(yè)多年,我在通讀譯著后依然受益匪淺。相信本書對于企業(yè)CIO推動公司數(shù)字化轉(zhuǎn)型戰(zhàn)略、軟件開發(fā)者提升自身技術(shù)架構(gòu)功力,以及云原生愛好者以微服務切入最新的云原生體系,都有著極其重要的實踐指導意義。
張鑫
才云科技CEO
【譯者序】
2012年年初,我有幸加入了VMware公司的CloudFoundry團隊,與ChrisRichardson、PatrickChanezon、JoshLong等業(yè)界大咖共事,在全球范圍內(nèi)開展CloudFoundry開發(fā)者社區(qū)和生態(tài)建設(shè)工作。7年前,云計算的市場格局與現(xiàn)在大為不同。那時,IaaS正高歌猛進,PaaS的價值仍舊備受質(zhì)疑,“十二原則”還不為人所知,云端分布式系統(tǒng)的架構(gòu)演化也正“摸著石頭過河”。在這個時候,ChrisRichardson率先在業(yè)界提出了“FunctionalDecomposition”(功能性拆分)的概念,提出云計算環(huán)境下的分布式軟件,應該按照功能性拆分的方式進行架構(gòu)重構(gòu)。這個想法與稍后業(yè)界公認的“微服務”概念不謀而合。
在VMware公司工作期間,以及之后各自的創(chuàng)業(yè)經(jīng)歷中,我跟Chris保持著良好的個人關(guān)系和工作合作關(guān)系。Chris是一個風趣、博學、經(jīng)驗豐富的架構(gòu)師,他在軟件行業(yè)有將近30年的經(jīng)驗,在Java社區(qū)更是享有盛名。在離開VMware公司后,他建立了microservices.io網(wǎng)站,專注微服務架構(gòu)的咨詢和培訓工作,我也曾為他牽線搭橋,使他有機會為國內(nèi)的企業(yè)客戶提供咨詢服務。
經(jīng)過這些年的發(fā)展,微服務已經(jīng)成為軟件領(lǐng)域的新寵,國外Netflix、Amazon的成功案例,國內(nèi)數(shù)字化轉(zhuǎn)型的一波波浪潮,推動著PaaS廠商和開發(fā)者深度關(guān)注微服務。大家圍繞著微服務展開了大量的討論。在這個過程中,我們認識到,雖然很多企業(yè)客戶視微服務如救命稻草,但微服務并不能解決一切問題。很多客戶,亦盲從于各種廠商的“忽悠”,著力建設(shè)底層基礎(chǔ)設(shè)施。
面對這些迷茫,Chris曾對我說,軟件的架構(gòu)設(shè)計,就是選擇和取舍。面對圍繞微服務的眾多雜音,開發(fā)者和架構(gòu)師應該具備選擇和取舍的能力,應該站在比較高的角度俯瞰全局、權(quán)衡利弊,做出正確的架構(gòu)和技術(shù)選擇。這也是最初Chris寫作本書的動機之一:為架構(gòu)師提供一個微服務的全局視野,并教會架構(gòu)師如何在紛繁復雜的情況下做出正確的架構(gòu)選擇和取舍。
本書英文版的寫作開始于2017年春天,2018年10月正式出版。在英文版出版后,我集中利用兩個多月的時間完成了中文版的翻譯工作。這是一本30萬字的大部頭,Chris曾數(shù)次對英文版做出較大的結(jié)構(gòu)性修改。為了確保中文版的一致性和準確性,并且以最快速度翻譯出版,中文版初稿完成后,先后經(jīng)歷了7輪修改潤色和校對。在后期校對階段,我邀請了數(shù)位好友幫助把關(guān),他們是:薛江波、王天青、季奔牛、劉果、蔡書、張鑫、張揚、黃雨婷、毛艷玲。我特別感謝這些朋友,因為他們細致地校對了所有翻譯稿,幫我找到并修正了大量足以讓我“晚節(jié)不?!钡牡图夊e誤。蔡書和張鑫還在繁忙的創(chuàng)業(yè)工作之余細讀整本書,并撰寫了推薦序。
本書的中文版出版后,我將與Chris重啟針對中國市場的微服務咨詢和培訓業(yè)務。為此,我們發(fā)布了中文網(wǎng)站www.chrisrichardson.cn,并有針對性地設(shè)計了微服務培訓和技術(shù)咨詢的服務項目。我們期待與讀者面對面交流的機會。
喻勇
2019年2月14日
【前 言】
我很喜歡的格言之一是:
未來已經(jīng)到來,只是還沒有平均分布。
—威廉·吉布森,科幻小說作家
這句話的實質(zhì)是在說,新的想法和技術(shù)需要一段時間才能通過社區(qū)傳播開來并被廣泛采用。我發(fā)現(xiàn)并深入關(guān)注微服務的故事,就是新思想緩慢擴散的一個極好例子。這個故事始于 2006 年,當時受到 AWS 布道師一次演講的啟發(fā),我開始走上了一條最終導致我創(chuàng)建早期 Cloud Foundry 的道路,它與今天的 Cloud Foundry 唯一相同的是名稱。Cloud Foundry 采用平臺即服務(PaaS)模式,用于在 EC2 上自動部署 Java 應用程序。與我構(gòu)建的其他每個企業(yè)級 Java 應用程序一樣,我的 Cloud Foundry 采用了單體架構(gòu),它由單個 Java Web 應用程序(WAR)文件構(gòu)成。
將初始化、配置、監(jiān)控和管理等各種復雜的功能捆綁到一個單體架構(gòu)中,這給開發(fā)和運維都帶來了挑戰(zhàn)。例如,你無法在不測試和重新部署整個應用程序的情況下更改它的用戶界面。因為監(jiān)控和管理組件依賴于維護內(nèi)存狀態(tài)的復雜事件處理(CEP)引擎,所以我們無法運行應用程序的多個實例!這是個令人尷尬的事實,但我可以說的是,我是一名軟件開發(fā)人員,就讓我這個無辜的碼農(nóng)來指出這些問題吧。
顯然,單體架構(gòu)無法滿足應用程序的需求,但替代方案是什么?在eBay 和亞馬遜等公司,軟件界已經(jīng)開始逐漸嘗試一些新東西。例如,亞馬遜在 2002 年左右開始逐步從單體架構(gòu)遷移(https://plus.google.com/110981030061712822816/posts/AaygmbzVeRq)。新架構(gòu)用一系列松散耦合的服務取代了單體。服務由亞馬遜稱為“兩個比薩”的團隊所維護:團隊規(guī)模小到兩個比薩餅就能讓所有人吃飽。
亞馬遜采用這種架構(gòu)來加快軟件開發(fā)速度,以便公司能夠更快地進行創(chuàng)新并贏得競爭。結(jié)果令人印象深刻:據(jù)報道,亞馬遜平均每11.6秒就能夠?qū)⒋a的更改部署到生產(chǎn)環(huán)境中!
2010年年初,當我轉(zhuǎn)向其他項目之后,我終于領(lǐng)悟了軟件架構(gòu)的未來。那時我正在讀Michael T. Fisher和Martin L. Abbott 撰寫的《The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise》(Addison-Wesley Professional,2009)。該書中的一個關(guān)鍵思想是擴展立方體,如第2章所述,它是一個用于擴展應用程序的三維模型。由擴展立方體定義的 Y 軸擴展功能將應用程序功能分解為服務。事后來看,這是顯而易見的,但對我來說,這是一個讓我醍醐灌頂?shù)臅r刻!如果將 Cloud Foundry 設(shè)計為一組服務,我本可以解決兩年前面臨的挑戰(zhàn)!
2012年4月,我首次就這種架構(gòu)方法發(fā)表了題為“Decomposing Applications for Scalability and Deployability”的演講(www.slideshare.net/chris.e.richardson/decomposing-applications-for-scalability-and-deployability-april-2012)。當時,這種架構(gòu)并沒有一個被普遍接受的名稱。我有時稱它為模塊化多語言架構(gòu),因為服務可以用不同的語言編寫。
未來還沒有平均分布的另一個佐證是,微服務這個詞在 2011 年的軟件架構(gòu)研討會上被用來描述這種架構(gòu)(https://en.wikipedia.org/wiki/Microservices)。當我聽到 Fred George 在 Oredev 2013 上發(fā)表演講時,我第一次遇到這個詞,我立刻喜歡上了它!
2014年1月,我創(chuàng)建了https://microservices.io 網(wǎng)站,以記錄我遇到的與微服務有關(guān)的架構(gòu)和設(shè)計模式。在 2014 年 3 月,James Lewis 和 Martin Fowler 發(fā)表了一篇關(guān)于微服務的博客文章(https://martinfowler.com/articles/microservices.html)。隨著微服務這個術(shù)語被廣泛傳播,這篇博客文章使整個軟件社區(qū)開始圍繞微服務這個新概念展開更進一步的思考和行動。
小型、松散耦合的團隊快速可靠地開發(fā)和運維微服務的思想正在通過軟件社區(qū)慢慢擴散。但是,這種對未來的看法可能與日?,F(xiàn)實截然不同。如今,業(yè)務關(guān)鍵型企業(yè)應用程序通常是由大型團隊開發(fā)的大型單體應用。雖然軟件版本不經(jīng)常更新,但每次更新都會給所涉及的參與人員帶來巨大的痛苦。IT經(jīng)常難以跟上業(yè)務需求。大家都很想知道如何采用微服務架構(gòu)來解決所有這些問題。
本書的目標就是回答這個問題。它將使讀者對微服務架構(gòu)、它的好處和弊端,以及應該何時使用微服務架構(gòu)有一個很好的理解。書中描述了如何解決我們將面臨的眾多架構(gòu)設(shè)計挑戰(zhàn),包括如何管理分布式數(shù)據(jù),還介紹了如何將單體應用程序重構(gòu)為微服務架構(gòu)。但本書并不是鼓吹微服務架構(gòu)的宣言。相反,它的內(nèi)容圍繞著一系列模式進行展開。模式是在特定上下文中發(fā)生的問題的可重用解決方案。模式的優(yōu)點在于,除了描述解決方案的好處之外,還描述了成功實施解決方案時必須克服的弊端和問題。根據(jù)我的經(jīng)驗,在選擇解決方案時,這種客觀性會帶來更好的決策。我希望你會喜歡閱讀這本書,它會教你如何成功開發(fā)基于微服務架構(gòu)的應用程序。
更多建議: