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