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