架構(gòu)有時候挺難捉摸的——人們不斷提出新想法，這些想法在沒有任何背景或者細(xì)微差別的情況下快速成為主流“實(shí)現(xiàn)方式”；而迫于尋求架構(gòu)改進(jìn)之法的行業(yè)則盲目跟進(jìn)，不假思索地全盤接受。

在這股大有問題的風(fēng)潮中，微服務(wù)正是最新一代弄潮兒。可微服務(wù)到底哪里好，我們又為什么要使用微服務(wù)？是時候?qū)@個問題追根溯源了。

圖片

1.究其根本，微服務(wù)號稱能帶來……

很多好東西！

• 可擴(kuò)展性：能把代碼拆分成更小的部分，各自獨(dú)立開發(fā)、測試、部署和更新。
• 專注：讓開發(fā)者專注于解決業(yè)務(wù)問題和業(yè)務(wù)邏輯。
• 可用性：后端數(shù)據(jù)必須始終可用于各種設(shè)備。
• 簡單性：簡化大型企業(yè)級應(yīng)用程序的開發(fā)。
• 響應(yīng)能力：讓分布式應(yīng)用程序得以擴(kuò)展，從而響應(yīng)不斷變化的事務(wù)負(fù)載。
• 可靠性：復(fù)制的服務(wù)器分組可在發(fā)生故障時繼續(xù)保持運(yùn)行，從而消除單點(diǎn)故障。即使發(fā)生故障，運(yùn)行中的應(yīng)用程序也可恢復(fù)至良好狀態(tài)。

這些聽著都挺耳熟，但這六條說法其實(shí)各有來歷：兩條來自微服務(wù)文獻(xiàn)  （博文、論文等），兩條來自20年前的EJB文獻(xiàn)，兩條來自O(shè)racle Tuxedo——一項(xiàng)四十多年前的技術(shù)。各位朋友分得清它們的真實(shí)歸屬嗎？

換句話說，咱們這個行業(yè)其實(shí)一直在用同樣的炒作方法，同樣的宣傳伎倆。

不記得過去的人，注定要重蹈覆轍。

——George Santanyana，《理性的生活》（1905年）[1]

說起微服務(wù)這邊的炒作，一篇企業(yè)博文[2]列出了選擇微服務(wù)的十大理由：

• 能普及大數(shù)據(jù)最佳實(shí)踐。微服務(wù)天然適用于數(shù)據(jù)管道架構(gòu)，符合大數(shù)據(jù)的收集、攝取、處理和交付方式。數(shù)據(jù)管道中的各個步驟都會以微服務(wù)的形式處理各項(xiàng)小任務(wù)。
• 相對易于構(gòu)建和維護(hù)。微服務(wù)的用途單一，這種設(shè)計(jì)意味著其能以較小的團(tuán)隊(duì)構(gòu)建和維護(hù)。各個團(tuán)隊(duì)可以跨職能組建，同時也能專注于解決方案中的微服務(wù)子集。
• 支持更高代碼質(zhì)量。將整體解決方案模塊化為離散組件，有助于應(yīng)用開發(fā)團(tuán)隊(duì)每次專注于一小部分內(nèi)容，從而簡化整個編碼和測試過程。
• 簡化了跨團(tuán)隊(duì)協(xié)調(diào)流程。與以往涉及重量級進(jìn)程間通信協(xié)議的傳統(tǒng)面向服務(wù)架構(gòu)（SOA）不同，微服務(wù)使用事件流技術(shù)降低了集成門檻。
• 支持實(shí)時處理。微服務(wù)架構(gòu)的核心是發(fā)布/訂閱框架，能夠支持實(shí)時數(shù)據(jù)處理以提供即時輸出與洞察。
• 有助于快速增長。微服務(wù)使得代碼和數(shù)據(jù)能夠重用模塊化架構(gòu)，輕松部署更多數(shù)據(jù)驅(qū)動的用例和解決方案，借此增加業(yè)務(wù)價(jià)值。
• 能帶來更多產(chǎn)出。數(shù)據(jù)通常會以不同方式呈現(xiàn)給不同受眾；微服務(wù)簡化了為各最終用戶提取數(shù)據(jù)的方式。
• 易于評估應(yīng)用程序生命周期中的更新。高級分析環(huán)境，包括那些用于機(jī)器學(xué)習(xí)的分析環(huán)境，往往需要相應(yīng)方法來根據(jù)新建模型評估原有計(jì)算模型。微服務(wù)架構(gòu)中的A/B和多變量測試使用戶能夠輕松驗(yàn)證自己更新后的模型。
• 可實(shí)現(xiàn)規(guī)模伸縮?？缮炜s性不僅有助于提供更多容量，也能輕松凸顯出擴(kuò)展瓶頸，之后在各微服務(wù)層級上解決這些瓶頸。
• 擁有大量流行工具。大數(shù)據(jù)世界中的各種技術(shù)（包括開源社區(qū)成果）在微服務(wù)架構(gòu)中均運(yùn)行良好。Apache Hadoop、Apache Spark、NoSQL數(shù)據(jù)庫和各類流分析工具皆可用于微服務(wù)。

宣傳材料看得夠多了，下面我們一一對這些說法進(jìn)行甄別，只是這回要從真實(shí)技術(shù)的角度出發(fā)：

• 能普及大數(shù)據(jù)最佳實(shí)踐。自70年代以來，管道和過濾器架構(gòu)就一直是軟件工程中的組成部分。當(dāng)時Unixes提出了幾條原則[3]：讓每個程序做好一件事。如果需要完成一項(xiàng)新工作，別通過添加新“功能”讓舊程序復(fù)雜化，而應(yīng)重新構(gòu)建新程序。應(yīng)將每個程序的輸出看作另一個未知程序的輸入。不要用無關(guān)信息混淆輸出。嚴(yán)格避免使用列式或二進(jìn)制輸入格式，也不要堅(jiān)持使用交互式輸入。
• 相對易于構(gòu)建和維護(hù)。參見以上Unix原則。
• 能支持更高質(zhì)量的代碼。如果一次專注于一小部分有助于提高質(zhì)量，那請參見以上Unix原則。
• 簡化了跨團(tuán)隊(duì)協(xié)調(diào)流程。這一點(diǎn)非常有趣，里面提到“面向服務(wù)架構(gòu)”（SOA）……往往涉及重量級進(jìn)程間通信協(xié)議——比如說JSON over HTTP？或者說，這是指一切SOA都需要SOAP、WSDL、XML Schema和WS-*完整規(guī)范集？諷刺的是，微服務(wù)并沒有以任何方式阻止使用這些“重量級”協(xié)議，某些微服務(wù)甚至建議使用gRPC——一種跟IIOP非常相似的二進(jìn)制協(xié)議，它來自CORBA，屬于SOAP、WSDL、XML Schema和WS-*完整規(guī)范集等“重量級”協(xié)議的前身。
• 支持實(shí)時處理。實(shí)時處理其實(shí)并不是什么新鮮事物，多數(shù)此類系統(tǒng)確實(shí)需要用發(fā)布/訂閱或者“事件總線”模型來實(shí)現(xiàn)，但跟微服務(wù)架構(gòu)沒什么必要聯(lián)系。
• 有助于快速增長?！爸赜媚K化架構(gòu)”——好吧，大家還記得有多少事物都在以“重用”為賣點(diǎn)嗎？編程語言當(dāng)然是其一（OOP、函數(shù)式語言、過程語言），還有庫、框架等等……也許有一天，大家會在忍無可忍下表示“去他的重用，我們不在乎”。
• 能帶來更多產(chǎn)出。“數(shù)據(jù)集通常會以不同方式呈現(xiàn)給不同受眾”，這說的不是SAP的Crystal Reports嗎？
• 易于評估應(yīng)用程序生命周期中的更新。機(jī)器學(xué)習(xí)和高級分析環(huán)境需要“根據(jù)新建模型評估現(xiàn)有計(jì)算模型”……聽著挺熱門的，但其實(shí)并沒表達(dá)出什么實(shí)質(zhì)內(nèi)容。
• 可實(shí)現(xiàn)規(guī)模伸縮。這就有點(diǎn)好笑了，EJB、事務(wù)性中間件處理（比如Tuxedo）和大型機(jī)，誰不能實(shí)現(xiàn)規(guī)模伸縮？
• 擁有大量流行工具。我得說一句，行業(yè)中的每次重大炒作都少不了工具的捧場，特別是在實(shí)在沒什么可宣傳的時候?？赡艽蟛糠肿x者朋友沒經(jīng)歷過CASE的時代，但至少對UML有所耳聞吧？

而且聰明的朋友可能已經(jīng)注意到，上面大概一半的觀點(diǎn)都在強(qiáng)調(diào)共通的主題——創(chuàng)建和維護(hù)更小、更獨(dú)立的代碼和數(shù)據(jù)“塊”，讓各塊間相互版本化，使用共同的輸入和輸出以實(shí)現(xiàn)整體系統(tǒng)集成。這就好像……

2.究其根本，我們在微服務(wù)中發(fā)現(xiàn)的是……

模塊。

沒錯，大量的低級“模塊”。這個誕生自1970年代的概念，一直是大部分編程語言的核心。也可能更早，只是很多舊語言并沒有把相同的設(shè)計(jì)理念概括成“模塊”這個表達(dá)。

比如在CLR（C#、F#、Visual Basic等）中，它被稱為“程序集”；在JVM（Java、Kotlin、Clojure、Scala、Groovy等）上，則被稱為“JAR”或“包”；在我們熟悉的操作系統(tǒng)動態(tài)鏈接庫上也有它的身影（比如Windows上的DLL，Unix上的so或a，還有MacOS那隱藏在/Library目錄下的Frameworks）。

無論如何，它們都服務(wù)于相同的目標(biāo)：創(chuàng)造一個獨(dú)立構(gòu)建、管理、版本控制和部署的代碼單元，以供重復(fù)使用。

考慮到模塊的這一實(shí)際定義，我們引用一篇計(jì)算機(jī)科學(xué)基礎(chǔ)論文中的表述：

項(xiàng)目工作的明確定義與細(xì)分，保障了系統(tǒng)的模塊化。每個任務(wù)都將形成一個獨(dú)立的、不同于其他的程序模塊。在實(shí)現(xiàn)時，每個模塊及其輸入/輸出都經(jīng)過明確定義，與其他系統(tǒng)的預(yù)期接口不會混淆。在檢查開始前，先對各個任務(wù)進(jìn)行同步以避免調(diào)度問題。最終，系統(tǒng)會以模塊化形式進(jìn)行維護(hù)；系統(tǒng)錯誤和缺陷可被追溯至特定的系統(tǒng)模塊，從而限制錯誤搜索的具體范圍。

以上內(nèi)容來自David Parnas撰寫的開創(chuàng)性論文《On the Criteria To Be Used in Decomposing Systems into Modules[4]》，文章是在50多年前的1971年寫成的。這里提出的明確定義“獨(dú)立的、不同于其他的程序模塊”已經(jīng)涵蓋了微服務(wù)的約半數(shù)優(yōu)勢，就是說同樣的方法我們已經(jīng)用了50年之久。

所以，何必要為微服務(wù)而激動不已？

畢竟微服務(wù)的實(shí)質(zhì)跟微服務(wù)、服務(wù)甚至是分布式系統(tǒng)，根本就沒有關(guān)系。

圖片

3.微服務(wù)的實(shí)質(zhì)，在于……

組織清晰度。

亞馬遜是最早公開討論微服務(wù)概念的企業(yè)之一，但他們自己并沒有特別積極地運(yùn)用這種新架構(gòu)。畢竟為什么要瞎折騰呢，DBA團(tuán)隊(duì)得做相應(yīng)的架構(gòu)變更、QA需要開發(fā)新測試來發(fā)現(xiàn)bug、基礎(chǔ)設(shè)施團(tuán)隊(duì)得采購新一批服務(wù)器、UX團(tuán)隊(duì)則要為演示創(chuàng)建原型。這些都是額外的負(fù)擔(dān)，也代表著現(xiàn)實(shí)阻力。

在這種情況下，開發(fā)團(tuán)隊(duì)根本就沒法順利推進(jìn)自己預(yù)想的架構(gòu)調(diào)整。而以上提到的各個部門，只是普通IT團(tuán)隊(duì)中各類職能（分析、開發(fā)、設(shè)計(jì)、測試、數(shù)據(jù)管理、部署、管控等）的小縮影。

要想實(shí)際推動，則要么保證現(xiàn)有團(tuán)隊(duì)能找到不同的技術(shù)組合，要么硬性要求每位團(tuán)隊(duì)成員都具備完整的技能集（即所謂「全棧開發(fā)者」），可這無疑會大大增加招聘難度。另外，團(tuán)隊(duì)還需要對自己的生產(chǎn)中斷事件負(fù)責(zé)，每位成員都得隨叫隨到——這些都會體現(xiàn)在薪酬待遇和法律影響上。當(dāng)然，如果真能打通這些關(guān)節(jié)要害，那各個團(tuán)隊(duì)確實(shí)能夠獨(dú)立構(gòu)建自己的工件，于是生產(chǎn)力水平將一路飆升、再無阻礙。

可這種只有理論可行性的事情，真能實(shí)現(xiàn)嗎？

4.在微服務(wù)當(dāng)中，我們還發(fā)現(xiàn)了……

分布式計(jì)算謬誤。

有些朋友可能不太熟悉，這里的謬誤來自Peter Deutsch在80年代給Sun的同事們做的演講。1994年，Ann Wolrath和Jim Waldo的開創(chuàng)性論文《A Note on Distributed Computing[5]》則再次提及。

“無論如何定義「正確」，分布式系統(tǒng)都很難在性能、可靠性和可擴(kuò)展性方面真正正確?！保ㄋ缮⒔忉專?/p>

當(dāng)我們將系統(tǒng)拆分成運(yùn)行在單一操作系統(tǒng)節(jié)點(diǎn)上的內(nèi)存模塊時，即使是在五十年前，跨進(jìn)程或庫邊界進(jìn)行數(shù)據(jù)傳遞的成本也可以忽略不計(jì)。但當(dāng)我們開始跨網(wǎng)絡(luò)線路傳遞數(shù)據(jù)時（也是目前大多數(shù)微服務(wù)的通行作法），則通信的延遲會瞬間提升五到七個數(shù)量級。這不僅僅要求我們向網(wǎng)絡(luò)添加更多節(jié)點(diǎn)來“擴(kuò)展”，同時也令整個系統(tǒng)快速惡化。

沒錯，通過將微服務(wù)托管在同一臺機(jī)器上、加載到運(yùn)行各獨(dú)立微服務(wù)容器化鏡像的虛擬機(jī)集群內(nèi)，確實(shí)能降低不同服務(wù)間的相互影響。（例如使用Docker Compose或Kubernetes托管一組Docker容器。）但這種方式會增加虛擬機(jī)進(jìn)程邊界間的延遲（因?yàn)槲覀儽仨氉裱邔幽Ｐ鸵?guī)則，即使其中某些層可以完全模擬，產(chǎn)生的延遲仍無法忽視），而且會在各獨(dú)立節(jié)點(diǎn)上引發(fā)運(yùn)行可靠性問題。

更糟糕的是，還沒等我們切實(shí)解決分布式計(jì)算謬誤，那邊又冒出了與之相關(guān)但又獨(dú)立存在的新麻煩：企業(yè)計(jì)算謬誤[6]。

5.探究微服務(wù)的核心，我們最好能……

重新思考自己的需求。

真有必要把問題拆分成一個個獨(dú)立實(shí)體嗎？用托管在Docker容器里的獨(dú)立進(jìn)程就能做到這一點(diǎn)，或者也可以在遵循標(biāo)準(zhǔn)化API約定或者其他選項(xiàng)的應(yīng)用程序服務(wù)器中引入獨(dú)立模塊。

這是個有成熟解的問題，過去20年來已經(jīng)有無數(shù)種技術(shù)能夠?qū)崿F(xiàn)，包括servlet、ASP.NET、Ruby、Python、C++，甚至是聞?wù)哳^痛的Perl。其中的關(guān)鍵，是如何建立起易于理解的集成和通信約定的通用架構(gòu)基礎(chǔ)。

我們要不要減少開發(fā)團(tuán)隊(duì)面對的依賴項(xiàng)？認(rèn)真觀察這些依賴項(xiàng)，再跟合作伙伴共同確定可以把其中哪些做做整合。如果組織不想打破結(jié)構(gòu)體系中“以技能為中心”的指導(dǎo)思路（就是把員工明確劃分成「數(shù)據(jù)庫組」、「基礎(chǔ)設(shè)施組」、「QA組」和「開發(fā)組」等），那也至少要嘗試建立一個邊界相對模糊的報(bào)告結(jié)構(gòu)，把每位成員視為團(tuán)隊(duì)“矩陣”里的一個元素。

而且最重要的是，一定要保證團(tuán)隊(duì)對自己正在構(gòu)建的內(nèi)容擁有清晰認(rèn)知，保證他們能輕松向他人解釋自己服務(wù)/微服務(wù)/模塊的核心意義。關(guān)鍵是給團(tuán)隊(duì)以方向和目標(biāo)、達(dá)成目標(biāo)的自主權(quán)，同時輔以必要的鼓勵和引導(dǎo)。

這就是事情的真相。你想要微服務(wù)？不，你想要的只是模塊。

圖片

相關(guān)鏈接：

1. https://americanart.si.edu/artwork/those-who-cannot-remember-past-are-condemned-repeat-it-george-santayana-life-reason-1905
2. https://www.integrella.com/expertise/microservices/
3. https://en.wikipedia.org/wiki/Unix_philosophy
4. https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf
5. https://scholar.harvard.edu/files/waldo/files/waldo-94.pdf
6. http://blogs.newardassociates.com/blog/2016/enterprise-computing-fallacies.html