-- 會員 / 註冊 --  
 帳號:
 密碼:
  | 註冊 | 忘記密碼
3/26 新書到! 3/19 新書到! 3/14 新書到! 12/12 新書到!
購書流程Q & A站務留言版客服信箱
3ds MaxMayaRhinoAfter EffectsSketchUpZBrushPainterUnity
PhotoShopAutoCadMasterCamSolidWorksCreoUGRevitNuke
C#CC++Java遊戲程式Linux嵌入式PLCFPGAMatlab
駭客資料庫搜索引擎影像處理FluentVR+ARANSYS深度學習
單晶片AVROpenGLArduinoRaspberry Pi電路設計CadenceProtel
HadoopPythonStm32CortexLabview手機程式AndroidiPhone
可查書名,作者,ISBN,3dwoo書號
詳細書籍分類

微服務架構與實踐(第2版)

( 簡體 字)
作者:王磊,馬博文,張琦類別:1. -> 程式設計 -> 綜合
譯者:
出版社:電子工業出版社微服務架構與實踐(第2版) 3dWoo書號: 50981
詢問書籍請說出此書號!

缺書
NT售價: 540

出版日:4/1/2019
頁數:516
光碟數:0
站長推薦:
印刷:黑白印刷語系: ( 簡體 版 )
加入購物車 加到我的最愛
(請先登入會員)
ISBN:9787121349942
作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 
(簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證)
作者序:

譯者序:

前言:

推薦序
10 多年前,對云計算提出的口號是“能夠像水電一樣,通過網絡為全社會提供公共計算服務”。現在,計算服務化已經不再是口號,而是成為了現實。整個IT 行業的商業模式從賣產品轉向賣服務,這也就意味著,傳統的面向產品的應用服務架構,也需要向面向服務的應用架構轉型。
云計算技術的基本思路是將IT 資源集中起來,利用虛擬化技術,讓更多的用戶能夠共享資源,從而提高資源的利用率,降低服務成本。但用這種做法的同時也隨之帶來了一些新的技術挑戰,比如如何設計新架構以適應海量并發用戶和多樣性的用戶需求等,這導致云計算及其應用日益復雜。
軟件工程師解決復雜性的核心思路的方法一直就是將架構功能模塊化。云計算讓軟件服務化,微服務就是在云服務的基礎上,讓軟件進一步模塊化,以服務的方式提供更好的靈活性。
從微服務概念的提出,到近幾年大家談云必談微服務,及CloudNative 將微服務作為應用架構的事實標準可以看出,微服務架構正在成為應用架構設計的主流模式。
但是,通過業界幾年的案例和實踐來看,微服務架構的落地也與其他技術的落地類似,是個循序漸進的演進過程。它不僅包括架構解耦,還涉及測試機制、部署運維、工程實踐、團隊協作等多方面,這些因素相輔相成,共同影響著如何高質量、快速地交付業務。
本書的幾位作者王磊、馬博文、張琦,是國內較早接觸微服務、DevOps 以及實現微服務框架的架構師、實踐者,可以說本書是集方法論、指南與實踐經驗為一體的指導書籍。
本書的第一部分以理論基礎為主,主要介紹了應用軟件架構的發展歷史,闡述了微服務架構的本質,并剖析了微服務架構未來的演進趨勢,即Serverless 和Service Mesh;第二部分介紹了微服務生態系統、微服務架構的關鍵技術、微服務實施參考模型以及重要的落地實踐。所謂“光說不練假把式”,對于一本技術書來說,“show me the code”是重要的環節;在第三部分中,本書基于Apache 的微服務開源框架ServiceComb 以及華為云ServiceStage,完整地搭建了案例系統,并詳細地闡述了從服務的分析、設計、開發,到測試、部署及運維端到端的內容。
感謝本書的幾位作者將寶貴的經驗分享出來,祝本書的讀者們能夠享受微服務架構的帶來的種種樂趣。
中國信息通信研究院云大所所長 何寶宏博士
2018 年11 月23 日

通過這幾年在項目中實踐微服務,為客戶提供微服務咨詢,我越來越肯定所謂“微服務(Micro Service)”其實一點都不“微”!這非Martin Fowler 定義之過。他所定義的概念,突出了設計每個獨立服務時要分解的粒度,但對于整個架構風格而言,實踐微服務并不如概念所表現的那樣舉重若輕,然后“輕而易舉”。一個微服務從誕生到最后完成使命,經歷了設計、開發、測試、上線運行到下線,其貫穿了整個生命周期。每個環節都有方方面面的因素需要考量,如設計原則的遵守、通信機制的選擇、數據一致性的保障、健康狀態的監控與跟蹤,乃至于服務的配置、測試與運維,還有對企業的組織結構進行改革,使之與微服務架構風格相匹配,等等。
我們還能說微服務是小而美嗎?
為什么還有這么多企業對其趨之若鶩呢?個人認為,微服務是結構與規模的權衡。當兩者不可兼得時,選擇降低規模以應對業務復雜度的增長,犧牲結構來換取對復雜系統的控制。觀察前面提及的諸多考量要素,是否都屬于技術實現的范疇呢?對于軟件系統的實現者而言,我們無法決定業務復雜度的增長,但卻可以將技術復雜度掌控在自己手中。因此,微服務利用“分而治之”的思想減小了系統的規模,使得每個微服務的開發者不用面對復雜的業務邏輯,即使業務發生了變化,在如此小規模的“微”服務中,我們也能輕松面對——最壞的情況也就是重寫一個微服務!
這種分解帶來規模減小的同時,引入的卻是分布式系統固有的技術復雜度。這種復雜度依舊挑戰著編程的極限。但我們對于未來卻不再是茫然不可知了,微服務將業務實現的難題轉向了基礎設施的難題,進而成為整個軟件行業面對微服務的共同“焦慮點”。終于,我們能夠拋開具體業務的束縛了!面對這共同的“焦慮點”,一些技術先行者開發了公共的微服務平臺與框架,以圖解決基礎設施的問題,于是就有了Netflix OSS、Spring Cloud、Service Fabric、ServiceComb、Istio 等微服務框架。而云端的PaaS 與容器化技術又解決了服務部署、服務編排、服務監控等基礎問題。面向業務的微服務開發者們,就可以面對真正的小而美的“微”服務了。
分解業務復雜度、控制技術復雜度為業界“擁抱”微服務的根本原因。
分解業務復雜度,是服務設計要解決的問題;控制技術復雜度,則提升到系統工程的高度,需要考慮團隊組織、框架選型、部署運維等微服務全生命周期的每個環節。幸運的是,王磊、馬博文和張琦的這本書全面地回答了這兩方面的問題。我極為認同書中提到的“微服務生態系統”這一概念。以“生態系統”為名,就能夠讓大家在看到微服務之“微”
的同時,還能重視微服務“不微”的另一面。面對微服務的應用開發人員,我們希望隱藏它“不微”的一面。然后將這背后的苦活兒、累活兒、臟活兒交給架構的設計者,微服務平臺的實現者,讓他們去構造和打磨內部精巧細微的零部件與支撐平臺。
從“不微”進入到“微”,是從宏觀世界進入微觀世界,整個過程其實是一個艱巨的架構設計過程。無論是在新項目中“擁抱”微服務架構,還是將遺留的單塊架構遷移到微服務架構,都需要慎重,在微服務的優勢與不足中取得良好的平衡。“To be or not to be”,這是個問題。而王磊兄結合自己這數年來實踐微服務架構的心得體會,總結了“微服務實施
參考模型”,通過適用性評估、成熟度參考與度量指標,讓選擇的難題迎刃而解。這是本書的一大創見!
從計算機的發展歷史來看,微服務是一個新生產物,但它不是從石頭縫里突然蹦出來的,它的設計思想其實是分布式系統與SOA 的延續,同時又汲取了DevOps、持續集成、持續交付等工程實踐,并借著云計算和容器化的春風開始了它的馳騁之旅。因此,要做好微服務架構,既需要在業務和技術方面鉆研得夠深,又需要具有涵蓋整個生命周期的廣博知識,但兩者很難兼得,但本書的內容恰恰在這兩方面都得到了很好的體現。我想,這一方面得益于本書已是第2 版,在前一版全面介紹微服務架構的基礎之上,是一次體系化的精進,內容臻于成熟。同時又依賴于王磊兄在ThoughtWorks、華為親身經歷的眾多大型項目,收獲了大量實踐微服務架構的經驗。
微服務是與時俱進的。從Martin Fowler 提出“微服務”概念至今,不過三、四年時間,這其中已經誕生了許多能“呼風喚雨”的平臺和框架。在軟件設計領域,實現技術瞬息萬變,唯有設計思想方能歷久彌新。幸運的是,本書既通過實戰案例為你提供了微服務落地的參考。同時又高屋建瓴地對微服務架構思想進行了全方位的梳理。本書通過合理巧妙的章節分布與匠心獨運的內容編排,同時兼顧了“微”與“不微”,專與博,變與不變,真可以說是一本“貪心”之作,但對于讀者而言,不正是一壺可以貪杯的佳釀嗎?
架構編碼實踐者 張逸
2018 年11 月12 日于成都

我和王磊老師是在 ThoughtWorks 的同事。2014 年,我們一起在幫助當時的客戶實施微服務改造,我們在不同的項目上實踐著微服務。那個時候的“微服務”對我來說僅僅是“把應用中的一部分用Restful API 調用,并且通過持續部署的方式部署到生產環境上”。
當我還對微服務的落地懵懵懂懂時,王磊老師已經帶領一個團隊開始規模化地實踐微服務了。他把所遇到的問題和技術實踐系統地總結下來,這就是《微服務架構與實踐》(第1 版)一書。作為當時國內較早的微服務領域的書籍,它揭開了微服務的帷幕,將完整的微服務技術和實踐展現在我面前,使我知道原來我所了解的僅僅是微服務的冰山一角。
在接下來的幾年里,我將自己所在項目的經驗推廣到了其他項目上,開始了我的“DevOps 和微服咨詢”生涯,這段時間也正是微服務在中國開始流行起來的時候。在微服務的理論和實踐在國內不斷深入的同時,新的技術和挑戰也在不斷出現。在我們最早實現微服務時,還不存在 Spring Cloud“全家桶”,也沒有 Kubernetes 這樣的容器編排工具。當時能夠獲取的資源可能就是Netflix 提供的開源項目(當然,現在其中一部分已經不存在了,比如Asgard)。然而,國外的微服務實踐經驗對于國內而言,可借鑒的部分十分有限。而國內的微服務實踐,往往側重于工具技術的應用,卻缺乏了方法論層面的指導。
作為微服務在國內的先驅者和探索者,王磊老師在微服務領域中不斷地總結和探索,繼續完善著微服務的理論和實踐,在近幾年指導并參與了更多的微服務改造項目,獲得了更多的實踐經驗,并總結出了系統的微服務實踐方法論。這些內容就融合在了這本《微服務架構與實踐》(第2 版)中。
了解第1 版的朋友,可能會發現第2 版比第1 版“增容”不少,不光更新了第1 版中相關的內容,使得體系更加清晰,而且還介紹了微服務的業界發展,如 Serverless 和Service Mesh。不過,我認為最重要的內容是本書中對“微服務實施參考模型”的梳理。微服務的實施就像在探險,“當你沒有方向的時候,貿然行動可能是最危險的”。就像王磊老師在書中描述的那樣,微服務的實施“不僅僅是架構的拆分,還涉及團隊協作、工程實踐、基礎設施、部署運維等多個方面,這些因素相輔相成,互相依賴,共同影響著如何高質量、快速的交付業務。”
對此我深有體會。架構的演進,不光是技術的升級,還有隨之帶來的組織結構和工程實踐等多方面問題,這些都是決定微服務實施成敗的關鍵因素。如果忽略了其他因素的相互作用,就很容易在微服務的實踐中被多方莫名的阻力困住,難以前行。書中提出的“微服務實施參考模型”就像一張地圖,將微服務實施的全貌展現了出來。它匯聚了眾多微服務實踐者和應用的智慧,解決了“從哪開始”、“到哪里去”和“如何去”這三個關鍵的問題,并且把可能遇到的問題標注在了這張“地圖”中。
如果你已經陷入微服務改造的泥沼,希望本書可以給你指明前行的方向。如果你是微服務的初學者,本書的第3 部分“實戰篇”則給了你一個理論結合實踐,去完整“體驗微服務”的機會。這部分通過案例,讓你對從架構設計、技術選型開始,到使整個微服務完整地落地有深入的了解。如果你還沒有完整的微服務實施經歷,千萬不要錯過這個部分。
我依然記得第一次在項目上完成微服務改造時,那種完成架構和工程實踐的美好感受,始終留存在我的心里。在這幾年里,雖然服務著不同的客戶、不同的技術棧、不同的項目,但每當我迷茫的時候,都會回味第一次完成微服務架構改造的那種架構之美。希望你也能通過《微服務架構與實踐》(第2 版)體驗微服務的架構之美。讓你在迷茫時回歸初心,找到前行的方向。
愿架構之美與你同在。
埃森哲技術咨詢經理 顧宇
2018 年11 月11 日

認識王磊的時候,我剛到華為公司開始著手華為微服務框架ServiceComb 的開源工作,而恰逢他內部指導多個團隊落地微服務架構。微服務架構的落地需要框架的支持,而微服務框架的推廣需要實踐作為指導。這樣我們一拍即合,開始密切的合作。
在《微服務架構與實踐》(第2 版)的撰寫過程中,我見證了ServiceComb 進入Apache孵化的全過程。目前,ServiceComb 已從Apache 基金會孵化器“畢業”并正式成為高級項目,而《微服務架構與實踐》(第2 版)這本書也即將出版,我應邀寫下這篇序作為紀念。
傳統的單體應用模塊內的耦合程度很高,可謂牽一發動全身。為了應對業務的快速發展,降低業務組件的耦合方式,大家開始把應用中的各個模塊按照微服務的方式進行拆分,各服務以獨立進程方式進行部署,服務之間跨越網絡進行通信。雖然云化和容器化的大量采用簡化了服務的部署和運維, 但也隨之帶來了很多挑戰,如無法預先知道服務實例的地址、不能假設服務一直都是可用的、需要根據系統運行調整服務負載,而這些也正是微服
務框架需要面臨的挑戰。
業界微服務框架一般會從兩個視角來解決這類問題:一個是從開發視角;另一個是從運維視角。從開發視角,會將微服務架構的過程中所涉及的服務發現、負載均衡,容錯熔斷、限流降級,以及監控等環節,通過框架封裝,使應用構建變得簡單、高效;從運維視角,關注的則是網絡層面的問題,通過接管服務間的網絡請求,解決微服務架構帶來的服務注冊發現、熔斷、容錯、服務動態路由以及系統監控的問題。
ServiceComb 源于華為云的微服務引擎CSE,它沉淀了華為內多個項目的高性能、低延時的能力,旨在幫助用戶完成服務的快速開發以及云上工作。通過閱讀《微服務架構與實踐》(第2 版),讀者不僅可以系統化地學習微服務架構的落地思路,也可以通過使用ServiceComb 框架,結合華為云所提供的工具,實現服務的持續集成、自動布署,以及服務治理方案。
愿大家在《微服務架構與實踐》(第2 版)的陪伴下開啟美好的微服務探索之旅。
華為開源能力中心技術專家 姜寧
2018 年12 月7 日

2014 年,隨著Martin Fowler 和James Lewis 合著的《Microservice》一文的公開,微服務的概念被業界所接受,并逐漸變成架構設計的主流模式。從那時開始,ThoughtWorks 作為微服務架構的主要推動機構,就一直在海內外幫助企業導入微服務架構,針對遺留系統進行微服務和服務化改造。在這一過程中我們認識到,無論是國內還是國外的企業,對微服務的認知從一開始的模糊不清,已經逐漸變得清晰而明朗。高內聚、松耦合的架構設計思想,配合以輕量級的API 實現技術,使得開發工作從原來的統一步調的大團隊開發模式,逐漸向小團隊、自助步調的開發模式演進。在過去的四年時間里,許多企業圍繞如何能夠更好地發揮微服務架構的優勢,如何能夠使得團隊能力與微服務架構的要求相匹配,一直在不斷地探索,各種微服務框架、技術平臺也在技術社區中“你方唱罷我登場”。開發團隊在選擇不同的技術平臺時,也逐漸陷入兩難的境地。
自從2000 年以后,企業對軟件開發過程的訴求,從瀑布時代的“穩定”和“可預期”,逐漸過渡到了對于業務響應能力的追求。實現這一目標最簡單的方法(最起碼看起來是)是從管理思路和研發過程角度下手。敏捷、持續交付、DevOps 等過程管理手段逐漸被業界所接受。回想一下,2010 年前后,當軟件行業大規模地開展敏捷轉型的時候,500 人以上的團隊是很常見的。這500 人要基于統一的代碼庫、統一的發布節奏、統一的持續集成(CI)流水線來“排兵布陣”。為了應對這樣的問題,各種所謂規模化敏捷方案的實施框架開始在企業中被推廣和使用。LeSS、SAFe,甚至大規模的Kanban,都是定位于解決大規模開發團隊實時敏捷轉型問題。但是隨著時間的推移,很多團隊發現僅從管理和技術實踐角度入手去解決響應力的問題,會帶來一定的副作用。在我曾經參與的一個項目中,200 人的團隊被劃分成若干個特性團隊(Feature Team),每個特性團隊從Web 界面一直做到固件(Firmware)層。但是代碼庫還是一個統一的Repo,包含了Java 和C 語言代碼。團隊在需求劃分、持續集成、自動化測試方面都遇到了不少的困難,并且一個典型問題是,同樣一個業務邏輯,由于不同的特性團隊的實施,最終在代碼庫中形成了五個不同的實現方式。通過靜態代碼掃描工具完全無法發現這樣的“重復代碼”,而當業務規則發生變化時,團隊要付出很多精力去找到并修改代碼庫中所有相關代碼。
早在微服務出現之前,業界已經希望通過模塊化和模型驅動的方式,來解決架構方面的問題。2003 年,《領域驅動設計》一書出版。作者Eric 希望通過一種合理的建模手段,能夠幫助團隊更清晰地劃分職責的邊界,使業務模型能夠和技術實現模型統一,從而解決大規模復雜系統的研發問題。但是領域驅動設計(DDD,Domain-Driven Design)這一概念的提出,在技術社區里面一直是曲高和寡。除了個別公司在導入DDD 的思想和方法,大部分企業不僅沒有嘗試使用DDD,甚至連這一概念都不曾聽聞。但這一情況在微服務架構出現之后發生了顯著變化。
微服務架構不僅要求產品從系統架構的層面將原來的單體架構拆分開,同時也要求在團隊的層面,依據“康威定律”進行團隊的重組。團隊、系統、開發庫拆分以后,很多系統仍然需要在所有微服務之間進行端到端的“聯調、聯測”來保證質量,這樣做無法讓團隊可以根據自己微服務的需要來自行決定發布頻率。以Pact 為代表的“契約測試工具”的出現,很好地解決了這一問題。在契約被滿足的條件下,端到端的測試的工作量可以被最大程度地降低,降低到僅僅覆蓋關鍵用戶旅程的水平。各個微服務可以按照自己的頻率來發布,服務內的特性也可以做到獨立發布。用這樣的方法,產品實現了從原來的統一的大版本發布的模式向服務級小版本發布模式的過渡。由于微服務的粒度更小,在一個服務的范圍內來確保和守護領域模型也變得可行。
至此,團隊還有兩個問題亟待解決:第一個是如何有效地識別服務的邊界;第二個是大量的微服務被開發出來以后,如何有效地進行運維和演進。針對第一個問題業界已經達成共識,領域驅動設計當中的戰略層建模是一種十分有效的識別服務邊界的方法。基于限界上下文來構建微服務,可以使團隊最大程度地利用微服務架構所帶來的好處。同時,
DevOps 已經是業界針對第二個問題的標準答案。依托開源社區的不斷貢獻,以及各大廠商對于微服務平臺孜孜不倦的研發努力,目前市場上已經有很多種工具和平臺,可以幫助開發團隊以最快的速度將微服務的代碼部署到生產環境上。同時,完備的監控工具也實時地將生產系統上的各種信息反饋給開發團隊,從而讓開發團隊能夠針對線上的情況實時做出決策并且安全執行。
隨著容器技術和云技術的不斷發展,基礎設施和計算資源被更好地抽象,進而為微服務技術的不斷演進提供了可能。兩年以前,對于微服務平臺的選擇基本上只有Spring Cloud一種。但是到了今天,各大廠商都推出了自己的微服務工具,不僅支持了Spring Cloud 當中原有的功能,而且還提供了類似Service Mesh 等技術,使團隊可以進一步將原有單一技術棧的微服務系統,逐步演進成多語言的微服務系統。可以相信,在未來的很長一段時間里,會有更多的新技術支撐微服務的快速開發,除了為開發者提供更好的開發體驗。同時也會提供更好的彈性基礎設施,使應用系統對于業務響應能力的追求邁上一個新的臺階。
我認識王磊的時候,他擔任ThoughtWorks 的咨詢顧問。在ThoughtWorks 這樣一個社區性質的公司內部,王磊是很有影響力的。王磊當時所參與的項目,是ThoughtWorks 全球較早采用微服務架構的幾個項目之一。在這一項目上,客戶實現了契約測試工具Pact,并開源給整個技術社區使用,而王磊也將自己的經驗和感悟寫成《微服務架構與實踐》(第1版)一書。這也是我們在為客戶提供咨詢時,一本經常被提到的推薦讀物。在經過幾年的打磨和探索,結合業界的技術趨勢和工程實踐,王磊出版的這本《微服務架構與實踐》(第2 版),相信對很多希望和正在采用微服務架構的技術人員、架構師而言,是一本很有幫助的讀物。
DDD China 聯合發起人/ThoughtWorks 首席咨詢師 王威
2018 年11 月13 日

時至今日,隨著云計算、大數據、人工智能等技術的迅猛發展,企業數字化轉型的步伐也正在加速。越來越多的企業已不是在探討要不要做數字化轉型,而是在探索和踐行數字化之路。企業希望通過數字化轉型實現業務上的敏捷、智能、高效。敏捷是指既包括商業模式快速更替,也包括產品研發快速迭代;智能是指實現業務的快速創新;高效是指實現業務的有效和高速運轉。
企業的業務系統要實現“敏捷、智能、高效”,其面臨的關鍵挑戰是如何構建和駕馭一個強大而復雜的分布式系統。微服務和容器等云原生技術近幾年蓬勃發展,有專家學者認為微服務和容器是企業數字化轉型下大型分布式系統和技術的戰略選擇。通過微服務的架構設計,將整個系統拆分成若干個小而獨立自治的微服務,從應用架構層面實現應用的靈活性,讓“開發”的輪子快起來;容器技術實現了對運行環境更小力度、更輕量化地控制,從而使得應用程序運行標準化和具有伸縮性。
非常有幸受邀寫此推薦序,在此結合自己近幾年在華為從事的業務:進行微服務化的技術探索、高性能企業級微服務框架CSE 設計、ServiceComb 開源,以及華為云微服務云應用平臺ServiceStage 在支撐企業微服務轉型的經驗,與大家分享一些經驗。
首先,企業通過微服務化后,業務提升的效果非常顯著,業務上線周期大大縮短,周期從年縮短到月,從月縮短到周,甚至是天,這解決了“需求落地慢”的難題。同時也解決了傳統“煙囪”架構,諸如“多應用孤立”、“多數據打通難”等難題,進而也解決了業務層面的問題,如“政策落地慢”、“業務監管難”、“用戶體驗差”等難題。
其次,微服務轉型之路可以說是一個系統性工程,它涉及企業的系統架構、組織、流程等方面的變革和創新。這需要我們下定決心,包括我們的業務“一把手”和技術專家;當然,心急吃不了熱豆腐,微服務架構技術支持分步而做,分期演進。
再次,就是微服務框架選型,當前開源的微服務框架有很多,對于選擇哪個框架不用糾結,因為沒有完美的框架,選擇合適的框架就好了。架構的開放性、多語言支持、性能、負載均衡、灰度發布、微服務治理能力等都是考慮因素。
最后,“專業的人干各自專業的事”,云時代的應用是相互依存的,“Service on Service”的方式是快速構建企業應用的捷徑,建議我們企業的開發人員更聚焦業務的“痛點”分析、微服務設計、開發、上線,實現業務的快速創新。
行動是成功的起點,相信本書能夠給你帶來一段美好的微服務之旅。
華為云PaaS 解決方案總監 饒爭光
2018 年11 月25 日

自序
2014 年,微服務架構的概念在國外剛興起,國內提及并付諸實踐的人還并不多。我基于在ThoughtWorks 工作期間對海外某大型房產平臺的微服務改造的經驗,撰寫了本書的第1 版,介紹了微服務架構的概念、背景以及優缺點,并通過一個遺留系統微服務改造的案例,闡述了微服務的理論和相關實踐。
技術的發展日新月異,微服務現在已經從一個“流行語”落地到了諸多互聯網公司及傳統企業。在技術大會上,討論的議題不再是微服務的概念、優缺點,而是落地的場景、相關實踐以及如何應對大規模服務化帶來的挑戰等。另外,隨著持續交付、DevOps 理念被廣泛地接受,Kubernetes、云基礎設施的成熟,以及Service Mesh 等概念的興起,實現微服務的方式正在發生快速的變化。
近幾年,在幫助數個團隊將其產品遷移到微服務架構后,我深切地感受到:微服務的落地不僅僅只是架構解耦,還涉及工程實踐、部署運維、團隊協作等多個方面,這些因素相輔相成,共同影響著如何高質量、快速地交付業務價值。同時,我也發現:有些朋友對微服務的期望過高,將其視為解決現有架構痛點、消除技術債務、提升團隊能力的“銀彈”。加上社區對微服務的熱捧,導致他們過于迫切地希望大刀闊斧地進行改造,而忽略了演進的過程。實際上,由于存在業務模式、技術積累、組織結構等差異性,微服務改造,尤其對于存量系統龐大的組織而言,很難一蹴而就。另外,市面上出版了諸多與微服務架構相關的書籍,但對實施和演進過程做系統化梳理的并不多。隨著微服務架構在更多企業的落地,我認為如何系統化地演進和落地微服務將成為一大挑戰。
因此,我萌發了更新原書的想法。首先是與讀者分享在過去幾年中我在數個團隊中落地微服務的心得——書中的設計模式以及工程實踐,大多數是來自我對親歷實踐的梳理,其中的參考模型幫助我指導了多個團隊有效地推進遺留系統的改造。其次,基于熱心讀者的反饋,也對本書的開發語言以及技術框架(使用Java 作為開發語言,基于微服務開源框架ServiceComb 構建樣例)進行了更新。另外,還介紹了微服務架構在業界的最新發展,包括微服務與Serverless 以及Service Mesh 等的關系。
最后,感謝我的妻子曉麗和兒子錦熙,沒有你們的支持和鼓勵,我不可能完成這項工作。感謝摯友馬博文、張桐、趙國慶一直以來的支持和幫助,你們對本書的服務化測試、部署運維提供了諸多思路。感謝華為的同事,你們積極參與審校并提出了寶貴建議。這些同事(排名不分先后)包括:饒爭光、張琦、姜寧、陳弘、劉珊珊、吳繼敏、崔毅華、張龍春、田曉亮、周天、閆敏之。感謝電子工業出版社的張春雨和負責本書審校工作的編輯們,本書能夠出版,離不開你們一絲不茍的工作態度和敬業精神。
由于時間倉促及作者水平有限,書中難免有疏漏之處,在此敬請廣大讀者批評指正。2018 年7 月1 日于西安

2011 年入職ThoughtWorks 后,我一直在澳洲一家房地產在線廣告公司工作,負責交付項目,配合客戶逐步實施敏捷開發、持續集成、自動化測試、藍綠部署、持續交付、微服務化、云化、容器化、Serverless,我所在企業的組織結構也從職能型組織結構演進為類似Spotify 的敏捷性組織結構。
在這個過程中,首先完成了將系統從瀑布式開發改進為敏捷式開發,將持續集成、TDD、自動化測試等推廣到整個組織中。現在我依然記得當年實現Cucumber 測試做數據準備以及在CI 上修復環境的痛苦。這些痛苦換來的好處是,每個迭代(兩周)的產出都可以部署到生產環境中。隨后,服務可以通過“藍綠部署”的方式實現“零宕機時間”部署,這樣自動化部署的任務可以很容易地集成到交付流水線中。
這些工程實踐的應用,就像是鋪就了一條高速公路,讓后面的微服務改造變得異常順利。同時,由于部署已經自動化,基礎設施管理權限和能力也下放到了全功能團隊中,對運維管理的監控、日志聚合也都采取比較合理的方案,微服務數量增加而帶來的維護成本,由全功能團隊承擔,分攤在每個人身上的on-call 時間很少。
維護成本低帶來的好處是,微服務拆分的粒度可以非常小,小到只有一個接口。這些微服務設計和實現的經驗,也讓客戶后來可以自如地采用Serverless 部署微服務。
基于這些實際的微服務演進經歷,在開始構想本書時,我們對應地為微服務參考模型的每個維度添加了自身曾經經歷過的,或者一些業界的工程實踐的案例,為讀者在實施微服務時,提高每個維度下的成熟度提供參考。
在參與本書撰寫期間,大概半年多都幾乎每天凌晨1 點左右休息。特別感激我的愛人王嘉能一直支持我,她雖然擔心我的身體健康,但更能理解本書對我的重要意義。
借此機會,感謝曾經在剛開始工作時給予我無限幫助的文靜、聰明姐、吳少、黃拓和姜鵬。感謝現在團隊的同事王磊、桐桐、國慶對我的幫助。同時,也感謝曾經一起工作過的朋友們,沒有他們的幫助和影響,我無法對本書做出這些貢獻,書中的很多實踐案例也是來自他們的智慧和啟發。
I feel so grateful to work with all of you: JP who coached me in coding and swearing, Trent who led me into the DevOps world, Cos who gave me comprehensive guidance to become a qualified DevOps, Jeol who set an example of an outstanding tech leader, and Clayton who inspired me to think big in the data pipeline spike. My heartfelt thanks also go to Collins, Mike Williams, and other REA personnel who helped me and gave me enlightening ideas without any reservation. I’m an introvert and not good at rhetoric, but right here is the best opportunity for me todeliver my greatest gratitude with all my readers as witnesses.
最后,祝愿各位讀者能在閱讀本書的過程中有所收益,既可以形成自己的微服務理論體系,也能將實踐應用在具體項目中。
馬博文
2018 年7 月5 日于西安

隨著互聯網對各個行業的深度滲透,它對行業的改變除了使行業有了新的業務形式,還有對業務更新節奏的提速。近兩年在與處于各種不同行業的朋友的交流中,感受最深的一點就是“這世界變化太快了”。如果前兩年這種“快”的影響還只在互聯網領域,那么現在幾乎所有的行業都已經被裹挾到這個浪潮中來了。而“微服務”便是在這樣的大勢之下應運而生,由前兩年互聯網公司的“玩具”轉變為被更多企業級IT 系統所接受和嘗試東西。
IT 領域的技術更新節奏是十分迅速的,自本書第1 版出版以來,隨著容器技術、DevOps技術的蓬勃發展,“適應業務高速變化的系統架構”已經成長了很多。Kubernetes 的火爆,將容器技術帶入了復雜的企業級系統中,對有狀態的服務的支持,對復雜應用的編排能力,讓更多的人們認識到,不是所有的應用都可以簡單到無狀態,“農場散養模式”也不一定適合所有類型的應用。Service Mesh 的微服務實現形式的發展,讓大家認識到,終于有人開始認為傳統的微服務實現方式還是不夠快;而單一語言開發、單一協議通信也并不能滿足很多實際的需求。在“簡單為王”的另一面,人們終于認識到這個世界本就不是那么簡單的。互聯網褪去了前期的浮華,終于讓整個行業和技術的發展進入到“不落兩邊”的境界。而正是這種技術發展的趨勢,讓越來越多的企業級應用開始選擇和使用微服務架構。本書的前兩篇建立在我們對企業級應用的微服務實踐上,著重講解在這個過程中使用到的種種技術。
然而任何一個曾經嘗試過在自己的項目中使用過“微服務”的讀者都應該有所感受,“微服務”總是看上去很美,做起來卻又“冷暖自知”了。在我參與過的幾個微服務項目中,業務架構師在一開始的期望總是想讓我一下就告訴他,他的系統怎么做就可以一下就變成微服務架構,可以享受微服務帶來的種種好處,但是實際情況卻是,不存在這種“速成”的方法。其實從開發流程、組織形式、工具選用、架構方式、實現技術等各個階段,無不屬于微服務的范疇。即便是微服務拆分,也在種種理論之下要充分結合本業務、本系統的實際情況逐步進行。所以本書在“實踐篇”中花大篇幅向讀者展示了一個以微服務架構構建的系統的始末。從理論的實踐到工具的選用,再到各個環節的實施,這是希望讀者在此基礎上可以引發對實踐的思考,并能夠進一步以此為啟發,自己可以對微服務架構和技術有所領悟。
我衷心地希望本書的讀者可以從中獲益,了解微服務架構,掌握微服務架構,自己實踐微服務架構。這便是作為IT 從業人員在“搬磚”之外能得到的最大慰藉了。
張琦
2018 年9 月1 日于北京

前言
本書的結構
本書一共分為3 個部分,分別是基礎篇、策略篇和實戰篇。基礎篇為第1 章,主要介紹微服務架構相關的基礎知識。該章首先介紹軟件架構的演進史;其次闡述了微服務出現的背景、定義、特征及落地時面臨的挑戰;同時分析了微服務與SOA、Serverless 的關系;最后介紹了微服務領域Service Mesh 的興起。閱讀的重點為理解微服務的本質特征、挑戰并了解Service Mesh。
策略篇包含第2 章至第6 章,主要介紹了微服務生態系統、微服務關鍵技術、微服務實施參考模型以及基于參考模型的實踐,并在本篇最后的部分闡述了遺留系統改造的策略與案例。
第2 章首先介紹了微服務生態系統,并圍繞生態系統闡述微服務實現中涉及的接入層、業務層、支撐層及基礎設施。同時,也強調了開發框架、交付流水線與工程實踐的重要性。閱讀的重點是理解微服務生態系統的核心,系統化地思考微服務架構的演進過程(不僅僅是服務拆分),并在演進中持續提升團隊能力。
第3 章的內容是對第2 章內容的延伸,詳細介紹了微服務的設計(服務劃分策略、服務設計模式、內部實現結構等)、微服務治理(負載均衡、注冊發現、容錯機制等)的原理及方案、服務運維(監控告警、日志聚合等)的實踐等。第3 章內容的重點是微服務的劃分策略、服務設計模式以及服務治理。一直以來,如何有效拆分服務是很多朋友在微服務落地過程中遇到的一大挑戰,希望該部分的內容能為讀者提供一些思路。
第4 章是策略篇的核心內容,詳細介紹了微服務參考模型的3 個方向、8 個維度與5個階段,同時梳理出在微服務落地過程中,如何借助結果類、過程類兩類指標獲取反饋并持續改進。需要注意的是,模型中提到的階段定義以及度量指標,是筆者基于過往的項目經驗所總結,不一定能完全適用于所有項目,希望讀者能在此基礎上,制定適于團隊的參考指標。
第5 章基于參考模型總結了持續交付、部署運維、全功能團隊等多個維度下的工程實踐。雖然該部分的介紹可能涉及一些具體的工具(如RPM、FPM、Koji 等),但建議讀者將把更多的注意力放到實踐本身。工具是具體的,但實踐是普世的。讀者朋友可以基于這些實踐舉一反三,結合不同的工具、平臺助力微服務的落地。
第6 章闡述了遺留系統的不同改造策略及應用場景,并用基于筆者親歷的一個案例闡述了遺留系統的改造思路和服務化演進過程,希望能為正在對遺留系統進行改造的讀者提供啟發。
實戰篇包含第 7 章至第 13 章,在前兩部分的基礎上,基于開源的微服務框架ServiceComb 以及華為云ServiceStage 設計和實現了SockShop 系統,同時基于ServiceStage提供的流水線,將SockShop系統以持續交付的方式部署在公有云上。另外,使用ServiceStage提供的運維服務,對SockShop 系統進行監控、告警和日志聚合。
第7 章介紹了ServiceComb 的特性、原理,注冊中心的設計以及數據一致性解決方案Saga 的設計。讀者既可以學習到如何快速開始實施ServiceComb 項目,也能深層次地了解其背后的設計原理與細節。
第8 章主要介紹了華為云ServiceStage 提供的相關服務。
第9 章分析和設計了SockShop 系統,并進行了服務設計、技術選型以及環境準備,確保在后面的章節中,能快速進行服務的開發、測試、持續集成和自動化部署。
第10 章介紹了使用ServiceComb 和Java Chassis 實現第一個微服務,并搭建端到端的開發、測試、驗證、持續交付流水線,同時應用了多個維度下的工程實踐。
第11 章介紹了如何實現SockShop 系統的其他服務,并通過Service Mesh 的機制,將用戶界面服務接入SockShop系統。
第12 章介紹了SockShop 系統的服務編排。通過使用定義好的TOSCA 模版上,基于ServiceStage 的編排服務,快速地進行SockShop 系統的自動化部署。
第13 章介紹了ServiceStage 提供的APM 相關服務,并基于APM 對SockShop 系統進行運維。

閱讀指南
本書每個部分,甚至很多章節的內容都相對獨立,讀者可以按順序閱讀,也可以選擇不同的章節直接閱讀。我們將讀者對微服務的了解分為三個階段,初學階段、中級階段和高級階段,處于不同階段的讀者可以按照下面的閱讀指南來選擇性地閱讀本書。
? 初學階段:可以先閱讀第1 部分了解微服務相關的基礎知識,然后閱讀第3 部分,嘗試自己動手實現微服務,搭建流水線并部署微服務,有所體會后再回過頭查看第2 部分的內容。
? 中級階段:可以先閱讀第1 部分中微服務的最新進展,如Service Mesh 等,然后閱讀第2 部分的內容,最后選擇性地閱讀第3 部分的內容。
? 高級階段:選擇性地閱讀第1 部分中微服務的最新進展,然后閱讀第2 部分的參考模型以及實踐的章節。如果對ServiceComb 框架感興趣,也可以閱讀該部分的設計與實現。

本書中的DevOps
在本書的基礎篇中,筆者提出微服務的本質是“以縮短交付周期為核心、基于DevOps的演進式架構”,可以看出在微服務的落地過程中,與DevOps 是相輔相成的。另外,在策略篇中,本書提到的很多實踐也是和DevOps 提倡的“CALMS”理念相吻合的。但本書并不是一本探索如何實施DevOps 的書,更多的內容還是從架構、工程以及組織等維度闡述如何有效落地微服務。如果讀者希望系統地學習DevOps,建議參考其他DevOps 類的相關書籍,如《DevOps 實踐指南》或《DevOps 實施手冊》等。

本書的源碼
本書中提到的源碼,可以通過正文后的“資源列表”中的地址獲取。
內容簡介:

微服務架構不僅延續了分布式系統與SOA 的特征,也汲取了DevOps、持續集成、持續交付等工程實踐的成功經驗,并正在借著云計算和容器化的春風開始其馳騁之旅。但是,微服務的落地并不像其概念描述的那樣舉重若輕,它不僅包括架構解耦,還涉及開發測試、部署運維、工程實踐、團隊合作與康威定律等多方面的因素,這些因素相輔相成,共同影響著如何高質量、快速地交付業務價值。本書是在第1 版的基礎之上,基于作者近年來對服務化改造的實戰經驗和思考,并結合業界的技術趨勢進行的一次體系化的精進。全書共分為3 部分,首先闡述了微服務架構的理論基礎。其次介紹了微服務生態系統、實施參考模型以及最佳實踐,并基于真實案例分析了遺留系統的服務化改造策略與應用場景。最后基于Apache 開源社區的微服務框架ServiceComb,設計并實現了案例SockShop 系統,從端到端交付的角度,指導讀者完成服務的設計、開發、測試、流水線,以及自動化部署和運維體系的建立。本書不僅適合架構師、開發人員以及技術管理者閱讀,也適合正在嘗試向微服務架構遷移的團隊或者個人。希望本書能夠在微服務落地的工作中對讀者有所幫助。
目錄:

第1 部分 基礎篇
第1 章 微服務架構綜述 ........... 2
1.1 軟件架構發展歷史 ............ 2
1.2 微服務的誕生背景 ............ 8
1.3 什么是微服務架構 ............ 15
1.4 微服務架構的本質 ............ 23
1.5 微服務架構的特征 ............ 28
1.6 微服務架構不是“銀彈” ............ 34
1.7 微服務架構與SOA ............. 39
1.8 微服務與Serverless ............. 40
1.9 微服務與Service Mesh ........... 46
1.10 小結 .............. 53
第2 部分 策略篇
第2 章 微服務生態系統 ........... 57
2.1 為什么定義生態系統 ............ 57
2.2 微服務生態系統的核心內容 .......... 59
2.3 生態系統的工程實踐 ............ 66
2.4 小結 ............... 73
第3 章 微服務關鍵技術 ........... 74
3.1 服務設計 .............. 74
3.2 服務治理 .............. 116
3.3 服務運維 .............. 131
3.4 小結 .............. 142
第4 章 微服務參考模型 ........... 143
4.1 為什么需要參考模型 ............ 143
4.2 參考模型的核心內容 ............ 144
4.3 如何使用參考模型 ............ 172
4.4 小結 .............. 183
第5 章 基于參考模型的實踐 .......... 184
5.1 微服務團隊 .............. 184
5.2 核心敏捷實踐 .............. 192
5.3 服務設計與實現 ............ 198
5.4 運維管理 .............. 212
5.5 測試管理 .............. 235
5.6 交付流水線 .............. 269
5.7 部署管理實踐 .............. 288
5.8 小結 .............. 333
第6 章 遺留系統的微服務改造 .......... 334
6.1 遺留系統綜述 .............. 334
6.2 遺留系統改造策略 ............ 336
6.3 遺留系統改造場景 ............ 341
6.4 遺留系統改造案例 ............ 347
6.5 小結 .............. 354
第3 部分 實戰篇
第7 章 微服務開發框架ServiceComb ........ 356
7.1 ServiceComb 綜述 ............. 356
7.2 Java Chassis .............. 361
7.3 Go Chassis 詳解 ............. 364
7.4 注冊中心ServiceCenter ............ 365
7.5 數據一致性框架Saga ........... 372
7.6 小結 .............. 376
第8 章 微服務云應用平臺ServiceStage ......... 377
8.1 ServiceStage 綜述 ............ 377
8.2 CCE 云容器引擎服務 ........... 379
8.3 CSE 微服務引擎 ............ 384
8.4 SWR 軟件鏡像倉庫 ............ 386
8.5 AOS 編排服務 ............. 387
8.6 APM 應用性能管理 ............ 389
8.7 小結 .............. 391
第9 章 SockShop 系統分析與設計 .......... 392
9.1 系統綜述 .............. 392
9.2 需求理解與分析 ............ 395
9.3 服務劃分與設計 ............ 396
9.4 架構設計 .............. 401
9.5 基礎設施塔建 .............. 404
9.6 小結 .............. 407
第10 章 實現SockShop 系統的第一個服務 ........ 408
10.1 使用Java Chassis 實現商品服務 .......... 408
10.2 使用Docker-Compose 本地運行服務 ........ 415
10.3 商品服務自動化測試 ............ 416
10.4 搭建交付流水線 ............ 419
10.5 小結 .............. 423
第11 章 實現SockShop 系統的其他服務 ........ 424
11.1 實現用戶服務 ............ 425
11.2 實現購物車服務 ............ 432
11.3 實現訂單服務 ............ 434
11.4 實現支付服務 ............ 437
11.5 實現物流服務 ............ 438
11.6 實現用戶界面服務 ............ 440
11.7 使用Pact 驗證服務 ........... 451
11.8 運行SockShop 系統 ............ 456
11.9 小結 .............. 459
第12 章 部署SockShop 系統 ........... 460
12.1 SockShop 系統的TOSCA 模板 .......... 460
12.2 部署SockShop 系統 ............ 465
第13 章 運維SockShop 系統 ........... 468
13.1 監控告警 .............. 468
13.2 日志聚合 .............. 475
13.3 服務治理 .............. 476
13.4 小結 .............. 479
附錄A ServiceStage 相關概念 .......... 481
附錄B TOSCA 模板介紹 ........... 483
寫在最后 .............. 486
參考文獻 .............. 488
資源列表 .............. 490
序: