寫給中文版讀者的話

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ā)的基礎。

第三，關注微服務的本質(zhì)，即服務的分解和定義，而不是技術，如容器和其他工具。

第四，確保你的服務松耦合，并且可以獨立開發(fā)、測試和部署，不要搞成分布式單體（Distributed Monolith），那將會是巨大的災難。

第五，也是最重要的，不能只是在技術上采用微服務架構。擁抱DevOps的原則和實踐，在組織結構上實現(xiàn)跨職能的自治團隊，這必不可少。

還必須記住：實現(xiàn)微服務架構并不是你的目標。你的目標是加速大型復雜應用程序的開發(fā)。

最后，我要感謝中國的所有客戶，讓我有機會與你們探討微服務。我還要感謝那些讓我能夠討論技術而不用學說中文（這可比微服務難多了）的同傳翻譯。我希望你會喜歡閱讀這本書，它會教你如何成功開發(fā)微服務。我期待著再次訪問中國，與我的讀者見面，幫助更多企業(yè)客戶實施微服務架構。

Chris Richardson

2019年2月13日

前　　言

我最喜歡的格言之一是：

未來已經(jīng)到來，只是還沒有平均分布。

威廉·吉布森，科幻小說作家

這句話的實質(zhì)是在說，新的想法和技術需要一段時間才能通過社區(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)控和管理組件依賴于維護內(nèi)存狀態(tài)的復雜事件處理（CEP）引擎，所以我們無法運行應用程序的多個實例！這是個令人尷尬的事實，但我可以說的是，我是一名軟件開發(fā)人員，就讓我這個無辜的碼農(nóng)來指出這些問題吧。

顯然，單體架構無法滿足應用程序的需求，但替代方案是什么？在eBay 和亞馬遜等公司，軟件界已經(jīng)開始逐漸嘗試一些新東西。例如，亞馬遜在 2002 年左右開始逐步從單體架構遷移（https://plus.google.com/110981030061712822816/posts/AaygmbzVeRq）。新架構用一系列松散耦合的服務取代了單體。服務由亞馬遜稱為兩個比薩的團隊所維護：團隊規(guī)模小到兩個比薩餅就能讓所有人吃飽。

亞馬遜采用這種架構來加快軟件開發(fā)速度，以便公司能夠更快地進行創(chuàng)新并贏得競爭。結果令人印象深刻：據(jù)報道，亞馬遜平均每11.6秒就能夠?qū)⒋�碼的更改部署到生產(chǎn)環(huán)境中！

2010年年初，當我轉(zhuǎn)向其他項目之后，我終于領悟了軟件架構的未來。那時我正在讀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ū)慢慢擴散。但是，這種對未來的看法可能與日常現(xiàn)實截然不同。如今，業(yè)務關鍵型企業(yè)應用程序通常是由大型團隊開發(fā)的大型單體應用。雖然軟件版本不經(jīng)常更新，但每次更新都會給所涉及的參與人員帶來巨大的痛苦。IT經(jīng)常難以跟上業(yè)務需求。大家都很想知道如何采用微服務架構來解決所有這些問題。

本書的目標就是回答這個問題。它將使讀者對微服務架構、它的好處和弊端，以及應該何時使用微服務架構有一個很好的理解。書中描述了如何解決我們將面臨的眾多架構設計挑戰(zhàn)，包括如何管理分布式數(shù)據(jù)，還介紹了如何將單體應用程序重構為微服務架構。但本書并不是鼓吹微服務架構的宣言。相反，它的內(nèi)容圍繞著一系列模式進行展開。模式是在特定上下文中發(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 對書的內(nèi)容提出了細致和建設性的意見，我將永遠感激不盡。我還要感謝 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)參與過的所有會議和聚會的組織者及與會者，他們給了我大量的機會，讓我介紹和調(diào)整我關于微服務的想法。我要感謝我在世界各地的咨詢和培訓客戶，讓我有機會幫助他們將我關于微服務的想法付諸實踐。

我還要感謝 Eventuate 公司的同事 Andrew、Valentin、Artem和Stanislav對 Eventuate 產(chǎn)品和開源項目的貢獻。

最后，我要感謝妻子 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)驗和概括總結出的信息用清晰的方式表述出來。現(xiàn)在，他把關于微服務的這些抽象整理成了這本書。可以說，這是廣大微服務相關工作人員的福音。在這本書里，不僅有微服務領域已經(jīng)識別出來的問題、解決思路和解決方案，也有相應的代碼例子。這就使得高度抽象的內(nèi)容有了非常具體的表現(xiàn)，可以幫助我們在遇到問題之前就了解可能的潛在問題；有些代碼例子甚至是可以直接使用的。這種知行合一的能力，是我欽佩 Chris 的又一個重要原因，也是我向大家推薦這本書的理由之二：這本書可以幫助微服務相關人員構建知行合一的能力。

在一次關于架構的關鍵是什么的討論中，我們和 Chris 很快達成了共識：架構就是取舍，進而架構師就是做出取舍的人。大家都認同，做架構的人的特征之一應該是Independent（獨立），這也是我選擇做獨立解決方案進而設計產(chǎn)品的重要原因。在我們看來，只有獨立才有可能讓我們在做架構設計時做出中立和獨特的方案。面對問題時，大多數(shù)人會希望有人可以給出正確的建議，但是多數(shù)時候，困擾人們的不是什么才是正確的，而是取舍之間。這正是我推薦這本書的理由之三：這是一本可以幫你在設計微服務架構時做出取舍的書，它能在你處理微服務相關問題左右為難的時候給你提供參考和建議。

我們生活在一個高速發(fā)展的時代，微服務領域的技術、產(chǎn)品、模式日新月異，我們非常有幸參與和見證這個時代的發(fā)展。我們從解決昨天的問題里走出來，又走向更多的問題。在這個過程中，我們解決的問題的規(guī)模和復雜度都是成倍提升的。相信很多和我一樣喜歡體驗這種從無到有的過程、喜歡親手解決問題的成就感、喜歡用獨立思維去面對問題的人，都會喜歡這本書。在此，再次對 Chris Richardson 先生表示感謝，他為這個領域貢獻了寶貴的知識財富。

蔡　書

獨立顧問，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)型依賴技術創(chuàng)新。美國風險投資機構 Work-Bench 在《2018 企業(yè)軟件調(diào)研年報》中推論：以微服務為代表的云原生技術是幫助企業(yè)實現(xiàn)有效數(shù)字化轉(zhuǎn)型的唯一技術途徑。數(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 能力的第一步，往往是對已有應用架構進行現(xiàn)代化微服務改造，而如何進行微服務拆分、設計微服務邏輯、實現(xiàn)微服務治理等實操問題成為很大的挑戰(zhàn)。

本書英文原作由微服務權威架構師 Chris Richardson 先生所著。書中既包含了微服務的原理、原則，又包含了實際落地中的架構設計模式；既包含可舉一反三的理念和概念，也包含類似領域驅(qū)動設計、Saga 實現(xiàn)事務操作、CQRS 構建事件驅(qū)動系統(tǒng)等具體可套用的范式。本書可以幫助讀者把傳統(tǒng)的單體巨石型應用循序漸進地改造為微服務架構，從微服務的拆分，微服務架構下業(yè)務邏輯的設計以及事務、API、通信等的實現(xiàn)，一直到微服務系統(tǒng)的測試與生產(chǎn)上線，幫助讀者建立從無到有的完整微服務系統(tǒng)搭建的生命周期。

本書譯者在云計算、云原生與微服務領域有多年實踐經(jīng)驗和建樹，譯文既精確地還原了原著的內(nèi)容，又結合譯者自身的理解，讓中文版本更加通俗易懂。雖身在云計算行業(yè)多年，我在通讀譯著后依然受益匪淺。相信本書對于企業(yè) CIO 推動公司數(shù)字化轉(zhuǎn)型戰(zhàn)略、軟件開發(fā)者提升自身技術架構功力，以及云原生愛好者以微服務切入最新的云原生體系，都有著極其重要的實踐指導意義。

張　鑫

才云科技CEO

譯　者　序

2012年年初，我有幸加入了VMware公司的Cloud Foundry團隊，與 Chris Richardson、Patrick Chanezon、Josh Long等業(yè)界大咖共事，在全球范圍內(nèi)開展 Cloud Foundry 開發(fā)者社區(qū)和生態(tài)建設工作。7年前，云計算的市場格局與現(xiàn)在大為不同。那時，IaaS 正高歌猛進，PaaS 的價值仍舊備受質(zhì)疑，十二原則還不為人所知，云端分布式系統(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)站，專注微服務架構的咨詢和培訓工作，我也曾為他牽線搭橋，使他有機會為國內(nèi)的企業(yè)客戶提供咨詢服務。

經(jīng)過這些年的發(fā)展，微服務已經(jīng)成為軟件領域的新寵，國外Netflix、Amazon的成功案例，國內(nèi)數(shù)字化轉(zhuǎn)型的一波波浪潮，推動著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日