送書！《鳳凰架構(gòu)：構(gòu)建可靠的大型分布式系統(tǒng)》

構(gòu)成大規(guī)模系統(tǒng)的每一個部件都可以是不可靠的，會出錯，會老朽，甚至是消亡，如何讓不可靠部件構(gòu)成的系統(tǒng)持續(xù)保持可靠性，本書將給你答案：

《鳳凰架構(gòu)：構(gòu)建可靠的大型分布式系統(tǒng)》

超級暢銷書《深入理解Java虛擬機》作者周志明最新力作，國內(nèi)多位架構(gòu)專家聯(lián)袂推薦，從架構(gòu)演進、架構(gòu)設(shè)計思維、分布式技術(shù)、不可變基礎(chǔ)設(shè)施、技術(shù)方法論5個維度全面探索如何構(gòu)建可靠的大型分布式系統(tǒng)。

“Phoenix”（鳳凰）這個詞在東方的技術(shù)書中不常用，但在西方的軟件工程讀物中，尤其是在關(guān)于敏捷、DevOps話題的作品中時常出現(xiàn)。軟件工程小說《鳳凰項目》講述了徘徊在死亡邊緣的鳳凰項目在精益方法下浴火重生的故事；Martin Fowler在詮釋“持續(xù)交付”時，曾多次提到“Phoenix Server”（鳳凰服務(wù)器，取其能夠“涅槃重生”之意）與“Snowflake Server”（雪花服務(wù)器，取其“世界上沒有相同的兩片雪花”之意）的優(yōu)劣比對。也許是東西方文化的差異，盡管有“失敗是成功之母”這樣的諺語，但我們東方人的骨子里更注重的還是一次把事做對、做好，盡量別出亂子；而西方人則要“更看得開”一些，把出錯看作正常甚至是必需的發(fā)展過程，只要出了問題能夠兜底使其重回正軌便好。

在軟件工程里，任何產(chǎn)品的研發(fā)，如果持續(xù)時間很長，人總免不了疏忽、犯錯，導(dǎo)致代碼存在缺陷，電腦宕機崩潰，網(wǎng)絡(luò)堵塞中斷……如果一項工程需要大量的人員共同研發(fā)某個大規(guī)模的軟件產(chǎn)品，并使其分布在網(wǎng)絡(luò)中的大量的服務(wù)器節(jié)點中同時運行，隨著項目規(guī)模增大、運作時間變長，其必然會受到墨菲定律的無情打擊。

為了得到高質(zhì)量的軟件產(chǎn)品，我們是應(yīng)該把精力更多地集中在提升其中每一個人員、過程、產(chǎn)出物的能力和質(zhì)量上？還是應(yīng)該把更多精力放在整體流程和架構(gòu)上？

筆者對這個問題先給一個“和稀泥”式的回答：這兩者都重要。前者重術(shù)，后者重道；前者更多與編碼能力相關(guān)，后者更多與軟件架構(gòu)相關(guān)；前者主要由開發(fā)者個體的水平?jīng)Q定，后者主要由技術(shù)決策者的水平?jīng)Q定。

然而，筆者也必須強調(diào)此問題的另外一面：這兩者的理解路徑和抽象程度是不一樣的。如何學(xué)習(xí)一項具體的語言、框架、工具，譬如Java、Spring、Vue.js等，是相對具象的，不論其蘊含的內(nèi)容多少，復(fù)雜程度高低，它至少是能看得見、摸得著的。而如何學(xué)習(xí)某一種風(fēng)格的架構(gòu)方法，譬如單體、微服務(wù)、服務(wù)網(wǎng)格、無服務(wù)、云原生等，則是相對抽象的，談?wù)撍鼈兛赡芤媾R“一千個人眼中有一千個哈姆雷特”的困境。談這方面的話題，若要言之有物，就不能是單純的經(jīng)驗陳述。回到這些架構(gòu)根本的出發(fā)點和問題上，筆者認(rèn)為，真正去使用這些不同風(fēng)格的架構(gòu)方法來實現(xiàn)某些需求，解決某些問題，然后在實踐中觀察它們的異同優(yōu)劣，會是一種很好的也許是最好的講述方式。筆者想說一下這些架構(gòu)，而且想說得透徹明白，就需要代碼與文字的配合，于是便有了這本書，以及與它配套的實踐項目。

可靠的系統(tǒng)

讓我們再來思考一個問題，構(gòu)建一個大規(guī)模但依然可靠的軟件系統(tǒng)，是否可行？

這個問題聽起來的第一感覺也許會有點荒謬。如果這個事情從理論上來說就是根本不可能的，那我們這些軟件開發(fā)人員在瞎忙活些什么？但你再仔細(xì)想想，前面才提到的“墨菲定律”和在“大規(guī)模”這個前提下必然會遇到各種“不靠譜”的人員、代碼、硬件、網(wǎng)絡(luò)等因素，從中能得出一個聽起來頗為合理的推論：如果一項工作要經(jīng)過多個“不靠譜”的過程相互協(xié)作完成，其中的誤差應(yīng)會不斷累積疊加，導(dǎo)致最終結(jié)果必然不能收斂穩(wěn)定。

這個問題也并非杞人憂天、庸人自擾式的瞎操心，計算機之父馮·諾依曼在20世紀(jì)40年代末期，曾經(jīng)花費大約兩年時間，研究這個問題并且得出了一個理論—自復(fù)制自動機（Self-Reproducing Automata）。這個理論以機器應(yīng)該如何從基本的部件中構(gòu)造出與自身相同的另一臺機器引出，其目的并不是想單純地模擬或者理解生物體的自我復(fù)制，也并不是想簡單地制造自我復(fù)制的計算機，而是想回答一個理論問題：如何用一些“不可靠”部件構(gòu)造出一個可靠的系統(tǒng)。

當(dāng)時自復(fù)制自動機的藝術(shù)表示（圖片來自維基百科）

自復(fù)制自動機恰好就是一個最好的用“不可靠”部件構(gòu)造可靠系統(tǒng)的例子。這里，“不可靠”部件可以理解為構(gòu)成生命的大量細(xì)胞，甚至是分子。由于熱力學(xué)擾動、生物復(fù)制差錯等因素干擾，這些分子本身并不可靠。但是生命系統(tǒng)之所以可靠，恰是因為它可以使用“不可靠”部件來完成遺傳迭代。這其中的關(guān)鍵點便是承認(rèn)細(xì)胞等零部件可能會出錯，某個具體的零部件可能會崩潰消亡，但在存續(xù)生命的微生態(tài)系統(tǒng)中其后代一定會出現(xiàn)，重新代替該零部件，實現(xiàn)它的作用，以維持系統(tǒng)的整體穩(wěn)定。在這個微生態(tài)里，每一個部件都可以看作一只“不死鳥”（Phoenix），它會老邁，又能涅槃重生。

架構(gòu)的演進

從大型機（Mainframe）、原始分布式（Distributed）、大型單體（Monolithic）、面向服務(wù)（Service-Oriented）、微服務(wù)（Microservice）、服務(wù)網(wǎng)格（Service Mesh）到無服務(wù)（Serverless）等，技術(shù)架構(gòu)確實呈現(xiàn)出“從大到小”的發(fā)展趨勢。近年來，自微服務(wù)興起以后，涌現(xiàn)出各類文章去總結(jié)、贊美微服務(wù)帶來的種種好處，諸如簡化部署、邏輯拆分更清晰、便于技術(shù)異構(gòu)、易于伸縮拓展以提供更高的性能等，這些當(dāng)然都是重要優(yōu)點和動力。可是，如果不拘泥于特定系統(tǒng)或特定某個問題，以更宏觀的角度來看，前面所列的種種好處都只能算是“錦上添花”，是屬于讓系統(tǒng)“活得更好”的動因，肯定比不上系統(tǒng)如何“確保生存”的需求更關(guān)鍵、更貼近本質(zhì)。在筆者看來，架構(gòu)演變最重要的驅(qū)動力，或者說這種“從大到小”的變化趨勢的最根本驅(qū)動力，始終都是為了方便某個服務(wù)能夠順利地“死去”與“重生”。個體服務(wù)的生死更迭，是關(guān)系到整個系統(tǒng)能否可靠存續(xù)的關(guān)鍵因素。

舉個例子，某企業(yè)中應(yīng)用的單體架構(gòu)的Java系統(tǒng)，其更新、升級都必須要有固定的停機計劃，必須在特定的時間窗口內(nèi)才能按時開始，且必須按時結(jié)束。如果出現(xiàn)了非計劃的宕機，那便是生產(chǎn)事故。但是軟件的缺陷不會遵循定下的停機計劃來“安排時間出錯”。為了應(yīng)對缺陷與變化，做到不停機地檢修，Java曾經(jīng)制定了OSGi和JVMTI Instrumentation等復(fù)雜的HotSwap方案，以實現(xiàn)“給奔跑中的汽車更換輪胎”這種匪夷所思卻又無可奈何的需求。而在微服務(wù)架構(gòu)的視角下，所謂系統(tǒng)檢修，不過只是一次在線服務(wù)更新而已，先停掉1/3的機器，升級新的軟件版本，再有條不紊地導(dǎo)流、測試、做金絲雀發(fā)布，一切都顯得如此理所當(dāng)然、平淡尋常。在無服務(wù)架構(gòu)的視角下，我們甚至都不需要關(guān)心服務(wù)所運行的基礎(chǔ)設(shè)施，連機器是哪臺都不必知道，停機升級就更無須關(guān)注了。

流水不腐。有老朽，有消亡，有重生，有更迭，才是生態(tài)運行的合理規(guī)律。設(shè)想一下，如果你的系統(tǒng)中的每個部件都符合“Phoenix”的特性，哪怕其中某些部件采用了由“極不靠譜”的人員所開發(fā)的“極不靠譜”的程序，哪怕存在嚴(yán)重的內(nèi)存泄漏問題，哪怕最多只能服務(wù)三分鐘就會崩潰，只要在整體架構(gòu)設(shè)計有恰當(dāng)且自動化的錯誤熔斷、服務(wù)淘汰和重建機制，從系統(tǒng)外部來觀察，架構(gòu)仍然有可能表現(xiàn)出穩(wěn)定和健壯的服務(wù)能力。

鳳凰架構(gòu)

在企業(yè)軟件開發(fā)的歷史中，一項新技術(shù)發(fā)布時，常有伴以該技術(shù)開發(fā)的“寵物店”（PetStore）作為演示的傳統(tǒng)（如J2EE PetStore、.NET PetShop、Spring PetClinic等）。在對不同架構(gòu)風(fēng)格的演示中，筆者本也希望能遵循此傳統(tǒng)，卻無奈從來沒養(yǎng)過寵物，遂改行開了書店（Fenix’s Bookstore），里面出售了幾本筆者的著作，算是夾帶一點私貨，同時也避免了使用素材時的版權(quán)隱患。

盡管相信沒有人會誤解，但筆者最后還是多強調(diào)一句，Oracle、Microsoft、Pivotal等公司設(shè)計“寵物店”的目的絕不是為了日后能在網(wǎng)上販賣“寵物”，而是純粹為了演示技術(shù)。所以也請勿以“實現(xiàn)這種學(xué)生畢業(yè)設(shè)計復(fù)雜度的需求，引入如此規(guī)模的架構(gòu)或框架，純屬大炮打蒼蠅，肯定是過度設(shè)計”的眼光來看待接下來的“Fenix’s Bookstore”項目。相反，如果可能的話，筆者會在有新的技術(shù)、框架發(fā)布時，持續(xù)更新，以恰當(dāng)?shù)男问教砑拥巾椖康牟煌姹局校浼夹g(shù)棧可能越來越復(fù)雜。筆者希望把這些新的、不斷發(fā)展的知識，融入已有的知識框架之中，便于自己學(xué)習(xí)、理解、思考，同時能將這些技術(shù)連同自己的觀點和看法分享給更多感興趣的人。

也算是緣分，網(wǎng)名“IcyFenix”是二十多年前筆者從中學(xué)時代開始使用的，它源自暴雪公司的即時戰(zhàn)略游戲《星際爭霸》的Protoss英雄Fenix。如名字預(yù)示的那樣，他曾經(jīng)是Zealot，犧牲后以Dragoon的形式重生，帶領(lǐng)Protoss與刀鋒女王Kerrigan繼續(xù)抗?fàn)帯１M管中學(xué)時期我已經(jīng)篤定自己未來肯定會從事信息技術(shù)相關(guān)的工作，但顯然不可能預(yù)計到二十年后我會寫下這些文字。

所以，既然我們要開始一段關(guān)于“Phoenix”的代碼與故事，那便叫它“鳳凰架構(gòu)”，如何？

這是一本從架構(gòu)視角講解如何構(gòu)建大型分布式系統(tǒng)的著作，是超級暢銷書《深入理解Java虛擬機》的作者周志明多年架構(gòu)和研發(fā)經(jīng)驗的總結(jié)，得到了多位行業(yè)資深架構(gòu)專家的聯(lián)袂推薦。全書共16章，分為演進中的架構(gòu)、架構(gòu)師的視角、分布式的基石、不可變基礎(chǔ)設(shè)施和技術(shù)方法論五部分。

第一部分 演進中的架構(gòu)（第1章）

著重介紹了軟件開發(fā)歷史中多種主流架構(gòu)風(fēng)格出現(xiàn)的契機、解決的問題以及帶來的新缺陷。

第二部分 架構(gòu)師的視角（第2~5章）

總結(jié)了一名架構(gòu)師應(yīng)該在架構(gòu)設(shè)計時思考哪些問題，有哪些主流的解決方案和行業(yè)標(biāo)準(zhǔn)做法，各種方案有什么優(yōu)缺點，不同的解決方法會帶來什么不同的影響，等等。

第三部分 分布式的基石（第6~10章）

重點討論了“不同架構(gòu)風(fēng)格是應(yīng)該在技術(shù)規(guī)范上統(tǒng)一，還是由應(yīng)用系統(tǒng)自行解決”這個問題，給出了解決思路、方法和常見工具。

第四部分 不可變基礎(chǔ)設(shè)施（第11~15章）

重點講解了基礎(chǔ)設(shè)施不變性的目的、原理與實現(xiàn)途徑，包括虛擬化容器、容器間網(wǎng)絡(luò)、持久化存儲、資源與調(diào)度、服務(wù)網(wǎng)格等內(nèi)容。

第五部分 技術(shù)方法論（第16章）

面向技術(shù)決策者集中討論了與分布式、微服務(wù)、架構(gòu)等相關(guān)的理論話題，將解決問題的能力歸納、總結(jié)、升華為方法論。

全書以實踐為導(dǎo)向，一個案例貫穿全書，同時給出了基于Spring Boot、Spring Cloud、Kubernetes、Istio、AWS Lambda 五種架構(gòu)風(fēng)格的樣例工程。