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

在這股大有問題的風潮中，微服務正是最新一代弄潮兒。可微服務到底哪里好，我們又為什么要使用微服務？是時候對這個問題追根溯源了。

圖片

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

很多好東西！

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

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

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

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

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

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

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

宣傳材料看得夠多了，下面我們一一對這些說法進行甄別，只是這回要從真實技術的角度出發：

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

而且聰明的朋友可能已經注意到，上面大概一半的觀點都在強調共通的主題——創建和維護更小、更獨立的代碼和數據“塊”，讓各塊間相互版本化，使用共同的輸入和輸出以實現整體系統集成。這就好像……

2.究其根本，我們在微服務中發現的是……

模塊。

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

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

無論如何，它們都服務于相同的目標：創造一個獨立構建、管理、版本控制和部署的代碼單元，以供重復使用。

考慮到模塊的這一實際定義，我們引用一篇計算機科學基礎論文中的表述：

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

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

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

畢竟微服務的實質跟微服務、服務甚至是分布式系統，根本就沒有關系。

圖片

3.微服務的實質，在于……

組織清晰度。

亞馬遜是最早公開討論微服務概念的企業之一，但他們自己并沒有特別積極地運用這種新架構。畢竟為什么要瞎折騰呢，DBA團隊得做相應的架構變更、QA需要開發新測試來發現bug、基礎設施團隊得采購新一批服務器、UX團隊則要為演示創建原型。這些都是額外的負擔，也代表著現實阻力。

在這種情況下，開發團隊根本就沒法順利推進自己預想的架構調整。而以上提到的各個部門，只是普通IT團隊中各類職能（分析、開發、設計、測試、數據管理、部署、管控等）的小縮影。

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

可這種只有理論可行性的事情，真能實現嗎？

4.在微服務當中，我們還發現了……

分布式計算謬誤。

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

“無論如何定義「正確」，分布式系統都很難在性能、可靠性和可擴展性方面真正正確。”（松散解釋）

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

沒錯，通過將微服務托管在同一臺機器上、加載到運行各獨立微服務容器化鏡像的虛擬機集群內，確實能降低不同服務間的相互影響。（例如使用Docker Compose或Kubernetes托管一組Docker容器。）但這種方式會增加虛擬機進程邊界間的延遲（因為我們必須遵循七層模型規則，即使其中某些層可以完全模擬，產生的延遲仍無法忽視），而且會在各獨立節點上引發運行可靠性問題。

更糟糕的是，還沒等我們切實解決分布式計算謬誤，那邊又冒出了與之相關但又獨立存在的新麻煩：企業計算謬誤[6]。

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

重新思考自己的需求。

真有必要把問題拆分成一個個獨立實體嗎？用托管在Docker容器里的獨立進程就能做到這一點，或者也可以在遵循標準化API約定或者其他選項的應用程序服務器中引入獨立模塊。

這是個有成熟解的問題，過去20年來已經有無數種技術能夠實現，包括servlet、ASP.NET、Ruby、Python、C++，甚至是聞者頭痛的Perl。其中的關鍵，是如何建立起易于理解的集成和通信約定的通用架構基礎。

我們要不要減少開發團隊面對的依賴項？認真觀察這些依賴項，再跟合作伙伴共同確定可以把其中哪些做做整合。如果組織不想打破結構體系中“以技能為中心”的指導思路（就是把員工明確劃分成「數據庫組」、「基礎設施組」、「QA組」和「開發組」等），那也至少要嘗試建立一個邊界相對模糊的報告結構，把每位成員視為團隊“矩陣”里的一個元素。

而且最重要的是，一定要保證團隊對自己正在構建的內容擁有清晰認知，保證他們能輕松向他人解釋自己服務/微服務/模塊的核心意義。關鍵是給團隊以方向和目標、達成目標的自主權，同時輔以必要的鼓勵和引導。

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

圖片

相關鏈接：

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