作者 | jeanwu

單體和微服務誰是毒瘤？單體、分布式、微服務、SOA到底是什么關系？我的系統該用什么架構？最近終于下定決心研究這個問題并且有所收獲，歡迎一起討論。

一、架構的發展歷程

我堅定的認為要深刻的理解一項技術光靠網上一兩張按照各項維度對比的表格是不夠的，而是要了解這些技術出現的歷史背景：他們的出現到底是解決了什么問題，又帶來了什么新的問題，最后又因何而被淘汰。下面這部分內容參考《鳳凰架構》以及Martin Fowle等人一些文章進行整理，一起來看下歷史的浪潮是如何推動架構的演進。

1.原始分布式時代

首先介紹的是竟然是“分布式”而不是“單體”這有些反常識，然而事實上分布式確實出現的比單體早，“單體”這個名稱是在微服務開始流行之后“事后追認”所形成的概念，在單體出現之前分布式早已流行，并且成果斐然。

1971年Intel公司設計了世界上第一臺微型計算機MCS-4，開創了微型計算機的新時代，計算機逐步從專業的科研設備轉變為企業的生產設備。但是微型計算機用于商業生產面臨一個非常大的問題：計算機硬件有限的運算處理能力，直接限制在單臺計算機上信息系統軟件能夠達到的最大規模。如果你生在這個時代，相信也能自然而然想到這一問題的解決思路：“人多力量大”、”眾人拾柴火焰高“，樸素的真理適用于任何地方，當時高校、研究機構、企等不約而同的開始探索“使用多臺計算機共同協作來支撐同一套軟件系統”的方案，并取得了一系的成果。談分布式必然繞不開遠程調用，所以下面以遠程調用為例談一下這一時期的探索成果有什么局限性，又產生了哪些深淵的影響。

通過多臺計算機分布式協同支撐提升系統規模

大家應該了解“UNIX系統的版本戰爭”這一故事，為了避免相同的“戰爭”重演，負責制定 UNIX 系統技術標準的開放軟件基金會與主流計算機廠商共同制訂了DCE/RPC這一影響深遠的遠程服務調用規范，它也是公認的現代 RPC 鼻祖之一。因為開放軟件基金會本身就負責UNIX 系統技術標準的制定，在這個背景下，DCE/RPC帶著濃厚的UNIX“簡單優先原則”的設計哲學，預設分布式環境中的服務調用、資源訪問等操作盡可能透明，使開發人員不必過于關注他們訪問的方法或資源是位于本地還是遠程。

然而這個過于理想化的目標在當時面臨著太多的技術難題，“遠程調用”與“本地調用”相比復雜程度完全不可同日而語：服務發現、負載均衡、熔斷、隔離、降級、認證、授權等一系列的問題亟待解決。令人敬佩的是面對重重困難，DCE從無到有構建了大量的協議來解決這些問題，真的做到了相對“透明”，但是分布式還有一個致命的問題——網絡所帶來的性能問題。

我們來推演一下：硬件性能不足——>采用分布式服務——>分布式的遠程調用導致性能降低（與解決硬件性能不足的初心相悖）——>通過合并多個請求等方式刻意（開發人員需要意識到自己在寫分布式程序，與DCE透明簡單相悖）降低網絡性能損耗——>人的能力成為軟件規模的約束。這時候分布式從結果來看并不成功，設計向性能妥協讓簡單透明成為一句空話。

當我們玩游戲打BOSS時，喊人解決不了問題還有另外個方法——氪金，20世紀80年代摩爾定律穩定發揮，微型計算機的性能以每兩年即增長一倍的驚人速度提升，既然分布式充滿了矛盾與妥協，那就加錢換更好的機器，單體時代到來。

通過提升單臺計算機性能提升系統規模

2.單體架構時代

在微服務出現之前“單體”都不認為是架構，因為他太“簡單”、太“自然”了，以至于我想找到一本關于單體最佳實踐的書籍都沒有找到?，F在很多書籍把單體當做“毒瘤”，甚至會出現微服務比單體先進的觀點，然而事實上真的如此嗎？

首先，我們先要明確單體是什么：“單體”只是表明系統中主要的過程調用都是進程內通信，不會發生進程間通信，僅此而已。那么進程內調用是罪惡嗎？是毒瘤嗎？那肯定不是的?，F實中不會有人對你說：你這個"Hello, World!"程序不能用單體，因為單體架構是毒瘤。

有個“單體不便于擴展“的論調非常流行，我們著重討論下這個觀點是否準確。我們從性能擴展和功能擴展兩個方便說。先說性能擴展：這太簡單了，把一個服務部署多個副本，前面加一個負載均衡服務器來均分流量，這是不是就實現了擴展？再說功能擴展：縱向上我從來沒見到哪個大型系統代碼是不分層的，用過Spring都知道寫一個服務基本上默認按照MVC模式分層以便于擴展；而橫向上我們也可以從功能等維度拆分為不同模塊（模塊之間不進行通信或者進行少量的通信，注意：拆分模塊不代表不是單體服務，單體服務也不表示系統只有一個模塊），各模塊完全可以獨立迭代。從這個角度來看單體服務在“可擴展”這一點上也不輸與微服務，甚至在開發、調試等方面更優。當前單體服務也有其局限性，比如有個C++實現的系統要實現部分AI功能，明顯Python更有優勢，C++中執行Python雖然可以實現，但是顯然不如微服務獨立一個Python模塊來的優雅。現在回來看“單體服務不便于擴展”這個觀點并不完全正確。

單體也有良好的擴展性

“罪惡的單體”是“大型的單體系統”，而“大單體服務”的主要罪惡在于隔離性。舉一個例子，不小心寫了一個BUG會導致程序崩潰，如果是微服務只會導致一個模塊崩潰，影響的范圍也僅僅是依賴這個模塊的功能，可是如果是單體服務，所有代碼都共享著同一個進程空間，某一處崩潰直接導致整個進程崩潰，那影響的范圍就大了。到這里我們可以簡單的說：單體服務在同一進程更簡單、高效，其代價是損失了隔離能力以及技術擴展性。至于這兩點誰輕誰重不可一概而論，要看你的系統到底是一個小賣店還是一個大超市了。

既然單體和微服務各有優劣，為什么后來微服務潮流滾滾而來？互聯網是不斷發展的，隨著微型計算機的普及，軟件系統的功能越來越多，對應的開發團隊規模也越來越大，我們逐步進入了“大兵團作戰”時代，這時候“墨菲定律”+“黑天鵝事件”對系統可用性影響越來越大。

構建一個大規模但依然可靠的軟件系統非常難。根據墨菲定律可能發生的事（BUG）就一定會發生，再疊加不可預測的“黑天鵝事件”，隨著研發團隊的規模不斷擴大，系統不可用的概率會被無限放大，舉個極端點的例子：假如一個公司有10萬人，每個人寫出系統的可用性都能達到99.999%，可是當他們共同協作寫一個單體服務時，那么系統的可用性就是99.999%的10萬次方，約等于36.8%，這個系統簡直不可用，更何況人是不可靠的，這時候單體服務隔離性差的缺點凸顯。微服務把構筑可靠系統觀點從“追求盡量不出錯”轉變為“出錯是必然”，通過拆分服務以減少異常的影響范圍，關于微服務為什么可以提升系統的可用性可以用一個例子幫助理解：人體系統由一個個的不可靠的細胞（微服務）組成，大多數情況下一個或者一群微服務（細胞）的崩潰并不會影響我們的生命，我們的人體系統就是用不可靠部件構造的可靠的系統例子。

隨著系統規模擴大單體拆分勢不可擋，關于大單體如何拆分前輩們也進行了大量的探索，其中比較有代表性的有三種：

(1) 煙囪式架構：其實這里并沒有什么高深的理論，無非就是隨著系統的迭代，把一個系統拆分多個，拆分后的系統相互獨立沒有業務交互，因此使用這種架構系統又稱為孤島式信息系統，問題是這種情況真的存在嗎，如果存在大概率一開始就設計為兩個系統，既然是兩個系統也就不會放在一個單體里面了，放在一起那必然是因為這兩個系統共享了某些資源的，例如存儲、權限、賬號等等。

(2) 微內核架構：煙囪式架構在實際很少存在，因為拆分后的系統與系統大概率是有資源共享的，既然如此就大方的把數據、資源、公共服務集中到一塊成為一個被所有業務系統共同依賴的核心，具體的業務系統以插件模塊（Plug-in Modules）的形式存在，注意微內核架構核心在于微，核心只負責通用業務邏輯，不包括針對特殊情況、特殊規則或復雜條件處理的自定義代碼，不是插件化實現就一定是微內核架構，比如MySQL只是存儲引擎做成了插件，而MySQL的Server層是核心功能，不能算微內核架構。

這種架構至今仍然存在，Eclipse IDE就是一個典型代表，下載基本的Eclipse產品只會提供一個簡單的編輯器，一旦添加插件它就能變成一個高度可定制和實用的軟件開發工具。當然微內核架構也有其局限性，由于無法預先知道有哪些插件，因此實現一個插件時并不能默認的可以與另一個插件交互，插件只能和內核交互。

目前保險行業也常用微內核架構，由于不同地區、時間、事件索賠規則非常復雜，理賠規則會發展成一個復雜的大泥球，更改一條規則會影響其他規則，開發測試極其麻煩。使用微內核架構模式可以解決其中許多問題：

(3) 事件驅動架構：事件驅動解決了微內核架構插件不能相互交互的問題，子系統之間建立一套事件隊列管道，子系統可以發布消息到隊列，也可以訂閱隊列中的消息。系統之間完全解耦，好的架構歷久彌新，迄今為止電商系統依然有事件驅動架構的影子：下單、支付、發貨、結算，完全是由事件驅動。

圖源Google Cloud

3.SOA架構時代

在原始分布式時代就提到單體和分布式并行發展，單體架構在探索如何拆分、演化到事件驅動架構時，分布式也在曲折發展，SOA即將登上架構的舞臺。

剛接觸到“SOA治理”時我并不是很清楚是到底治理什么，SOA看起來似乎和微服務是一樣的，并沒有感受到明顯區別。SOA（Service-Oriented Architecture）是面向服務的架構……很遺憾定義實在太多了，我沒有找到權威的、明確的解釋，但是通過總結起碼有兩點我覺得是各方達成共識的。

• 面向服務的架構中的“服務”是指包含執行完整的、獨立業務功能所需的代碼和數據的，注意是“代碼”和“數據”，也就是說服務是一個獨立的功能單元，這里的服務和事件驅動架構中的子系統非常類似，要比今天我們所說的微服務中的“服務”粒度要粗的多。
• SOA的目的是復用，并為此制定了一系列標準，服務之間使用公共接口標準和架構模式，因此可以快速整合到新應用中。這讓應用開發人員無需像之前那樣重新開發現有功能，因為有公共的接口標準開發人員也不必了解如何連接現有功能 。

這么看SOA并不是解決新的問題，依然是在解決分布式服務剛被提出時就預見的困難，但是SOA針對這些問題的解決方案更具體、操作性更強，并形成一攬子規范標準，相比前面的煙囪架構、微內核架構、事件驅動架構，SOA就顯得具體的多，舉幾個例子：SOA明確了采用 SOAP 作為遠程調用的協議、明確使用企業服務總線（ESB）來實現各個子系統之間的通信交互等等，從技術角度SOA成功地解決了分布式環境下出現的主要技術問題，那SOA為什么逐步被微服務替代呢？

因為SOA太重了，過于嚴格的一攬子規范定義帶來過度的復雜性，落地成本非常之高。我們以遠程服務調用（Remote Procedure Call，RPC）為例：RPC 出現的最初目的是為了讓調用遠程方法和調用本地方法一樣簡單，直到今天還有人這么認為，實際上今天的大多數 RPC 技術已經不再追求這個目標，因為通信不是無成本的。Andrew Tanenbaum 教授曾在1987年發布一篇論文，核心論點是本地調用與遠程調用當做一樣處理，這是犯了方向性的錯誤，把系統間的調用做成透明，反而會增加程序員工作的復雜度，這個觀點在后幾年一直有爭論，直到大名鼎鼎的Sun公司一眾大佬總結“通過網絡進行分布式運算的八宗罪”該觀點才被廣泛認可，明確RPC是語言層次的特征，而不是系統層次的特征。

既然是RPC是語言層次的特征，編程語言那么多，最理想的是有一套統一的規范來解決RPC中如何表示數據、傳遞數據、確定方法三個基本問題（事實上直到現在RPC協議都是混亂的，數一數現在流行的RPC協議有多少個）。這個規范的發展很曲折，我們重點關注一個歷史性的時刻：W3C在1998年發布SOAP 1.0來實現Web Service。SOAP當時風頭一時無兩，雖然現在來看他在性能上和易用性上并不完美，但是這并不是他沒落的原因，而是因為過于“理想主義”的期望解決解決分布式計算中可能遇到的所有問題，為此定義龐大Web Service 協議家族，學習、使用成本非常高，脫離人民群眾的做法導致SOAP必然逐漸淹沒在歷史的長河中。SOAP作為SOA登上架構舞臺的重要條件，他的沒落也意味著SOA架構的沒落。

回顧“原始分布式時代”這一講中：Unix DCE提出的分布式服務的主旨是“讓開發人員不必關心服務是遠程還是本地，都能夠透明地調用服務或者訪問資源”。但是現在SOA已經背離了這一初心，于是微服務時代到來。

4.微服務架構時代

微服務真正崛起實于2014年，這時候的微服務已經和9年前剛剛被提出時有了明顯的區別。最開始微服務是SOA的輕量版，既然SOA過于繁重，那么微服務就盡可能的拋棄SOA 里可以拋棄的所有約束和規范，回歸透明簡單的初心；當然現在微服務已經脫離SOA成為一整獨立的架構風格，Martin Fowler在《Microservices: A Definition of This New Architectural Term》一文中對微服務解釋已經足夠詳細，這里不再贅述。

那么微服務和SOA到底有什么不同？討論這個問題實在意義不大，因為他們之間的關系實在太微妙了，有人說ESB是SOA的特點，這其實是過于武斷了，微服務拋棄了SOA中所有可以拋棄的標準并不代表微服務一定不用，別忘了微服務是自由的。我們只需要知道：微服務提倡以“實踐標準”代替“規范標準”，針對SOA解決的那些分布式服務的問題在微服務中不再會有統一的解決方案，開發者可以結合實際情況自由選擇。

微服務是普通開發者的狂歡，可以隨心所欲；微服務是架構者的噩夢，對架構師的能力要求提升到史無前例。微服務并不是什么銀彈，沒有必要過分的神話他，分布式架構中出現的問題如注冊發現、跟蹤治理、負載均衡、傳輸通信等微服務一個都沒有避免，該需要解決還是需要解決。但是在云時代下，微服務迎來新的契機：云技術讓微服務從軟件層面獨力應對分布式問題發展到軟、硬協同應對，也稱為“后微服務時代”。

當問題不局限于采用軟件方式那很多問題都簡單了。例如軟件可以通過命令伸縮擴容服務，硬件難道就不可以通過敲鍵盤就變出相應的應用服務器、負載均衡器等基礎設施嗎？氪金買云服務一樣可以解決問題，虛擬化技術讓軟件、硬件的邊界開始模糊，一旦虛擬化硬件變得足夠靈活，那么和業務無關的技術性問題都可以解決于基礎設施內，讓研發專注于業務開發。后面也催生出了云原生等許多新的概念，但是從本質上講他們所追求的目標和微服務沒有什么區別。微服務時代所取得的成就離不開以虛擬化技術的巨大貢獻。

微服務+云讓普通程序員也同樣能寫出可用于生產的軟件產品，但是對于架構師提出更高的技術要求，這會導致開發者的分層，形成大部分普通程序員加上小部分軟件設計專家的金字塔結構。

5.無服務時代

回想分布式架構之所以存在，最開始就是因為單臺機器的性能無法滿足復雜系統的需要。那么如果單臺機器如果性能無限所有問題都解決了。以前不敢做這樣的假設，但是現在云計算技術的發展實際已經讓這個暢想接近現實，而所謂無服務實際主要涉及兩點：后端基礎設施和函數。后端基礎設施提供了日志、存儲等等這一類用于支撐業務邏輯運行，而函數負責實現業務邏輯。我們不用考慮容量和算力問題，函數就是服務?，F在云計算提供的能力已經讓無服務初見端倪。

到這里架構演變的歷史我們已經理清，相信你也理解了每種架構出現的意義與淘汰的原因，接下來我們一起討論該如何選擇架構來解決今天我們所面臨的現實問題。

二、單體還是微服務

我們花了大量的篇幅去講架構演進是為了在歷史的浪潮中，理解每種架構出現的意義和淘汰原因，解決今天我們所面對的現實問題。直到現在關于架構好壞之爭依然存在，最激烈的討論就是的單體還是微服務。先說結論，假如一個業務發展良好，當系統復雜度增加到一定程度必然是從單體遷移到微服務的，但在這之前，我推薦單體。下面我們來看下是什么驅動復雜系統從單體向微服務遷移。

1.為什么要使用微服務

天下熙熙，皆為利來；天下攘攘，皆為利往。有收益才有付出，上文已經介紹既然單體是如此簡單、自然為什么還要遷移到微服務呢？為了更好的性能？微服務可以擴縮容自如，很好的應對業務發展所帶來的性能壓力，問題是隨著云計算的發展，單體服務同樣可以集群化部署、同樣可以很方便的擴縮容，而且硬件的價格越來越便宜，甚至單體服務還減少了RPC所帶來的性能損耗，這個理由看似正確，實際上是站不住腳的。僅僅為了性能而選擇分布式的話，那應該是 40 年前“原始分布式時代”所追求的目標。需求是不這樣不行，而不是這樣也行，同理復雜系統遷移微服務必然也有著非遷不可的理由。

(1) 當團隊內個人能力因素成為系統發展的明顯制約

這個問題很好解釋，前面我已經舉了一個極端例子：有10萬人寫一個單體服務，假如每個人寫出系統的可用性都能達到99.999%，那么這個單體服務的可用性只能達到36.8%。更何況沒有人能保證招到的人全部都專業、靠譜，即使可以人也具有不穩定性，受到情緒、健康狀況、人際關系影響也可能干出各種不靠譜的事，難以做出整體可靠的大型系統。由于在單體架構下系統中“整體”與“部分”的關系沒有物理的劃分，一旦發生錯誤缺乏有效的阻斷手段，而少量的專家也沒有辦法控制某個人研發在某行不起眼的代碼生成一個BUG并造成全局影響。

這種情況下，團隊人員水平參差不齊，或者團隊已經發展的非常大，微服務都是一個更好的選擇。在單體架構下，系統質量只能靠研發與項目管理措施來盡可能地保障，而微服務已經假定系統一定會出錯，架構本身就追求獨立、自治，讓高水平專家來開發和維護關鍵的基礎設置和業務服務，至于其他非核心功能發生錯誤可以依靠基礎設置的自愈能力恢復，退一萬步來講即使不能恢復影響也控制在一個小的范圍，而系統整體依然是高可用的。

(2) 當語言或者技術框架成為系統發展的明顯制約

語言沒有好壞，但有適不適合，舉一個非常簡單的例子：近幾年人工智能開展的如火如荼，所有的軟件都在考慮怎么結合人工智能提供能優秀的服務，讓業務進入第二增長曲線。但是稍微一調研就會發現Python對于AI訓練的支持是其他所有語言所無法比擬的，如果原來的系統使用C++實現，這時候對不同技術棧、不同框架實現的功能進行分布式部署并不是你想或者不想的問題，而是沒有選擇、無可避免的。當然非要在C++里執行Python也可以，可是使用這些奇技淫巧所帶來的維護成本是無法估量的。

(3) 當組織的人員架構成為系統發展的明顯制約

康威定律大家應該都了解，這里不做額外的贅述。變化是永恒的，隨著業務規模的不斷擴大，開發該系統的團隊也必然不斷擴大，組織架構隨之調整是自然而然的事。我們對抗不了康威定律，隨著組織架構的調整系統架構必然隨之調整。舉個簡單的例子：我要對某個模塊進行發布，該找誰審批，必然是自己的領導？但是如果是單體服務很可能涉及到多個團隊，讓每個團隊的領導都來審批會導致發布效率低下，這是很難容忍的。

那如何識別組織架構已經成為制約了呢：當所有的決策都要依賴某個人或者某個會議，對某個服務或者功能沒有人愿意承擔責任，或者愿意承擔責任的人成為決策單點時，這時候就該意識到該拆分服務了。

(4) 小結

我們要認識到微服務是有成本的，這里如果用一張表格來從各個緯度對比來說微服務需要解決哪些哪些問題可能并不會讓你有直接的感受，下面是網上一張著名的圖：Netflix公司在2014年公開的微服務調用關系圖。我相信Netflix中沒有一個人可以理清楚該系統的服務間調用關系，這是一個黑洞，如果某個微服務需要修改協議，很難理清楚到底需要周知哪些依賴方進行兼容修改。

Netflix公司在2014年公開的微服務調用關系圖

微服務核心價值是拆分之后的系統能夠讓局部的單個服務敏捷開發，最主要的目的是對系統進行有效的拆分以進行物理隔離，通過一系列的自制手段用不可靠的微服務構造可靠的系統，然而微服務在解決單體問題的同時又會帶來額外的很多問題，這里如果權衡不好反而會導致生產力下降，而系統進行任何改造的根本動力都是“這樣做收益大于成本”，因此“對于中小型系統單體架構就是最好的架構”，只有在業務已經發展到一定的程度，單體架構與微服務架構的生產力曲線已經到達交叉點，此時開始進行微服務化才是有收益的。至于這個是否出現了這個交叉點如何判斷，可以審查一下是否出現了以上三點。

圖源《鳳凰架構》

2.使用微服務的必備條件

即使我們有了充分的理由要遷移微服務也不能立刻遷移，還要看當前團隊是否具備遷移微服務的條件，貿然遷移很可能會適得其反。

(1) 組織中具備對微服務有充分理解的專家

講微服務時代時候就提到，微服務給予編碼人員充分的自由，但對于架構師卻提出了史無前例的高要求。在實際研發團隊中并不是每個人都是架構師，也不是每個人都會去探究擴展、認證、隔離等和具體業務無關的問題，大多人普通程序員還是更聚焦于業務代碼的編寫?？墒鞘褂梦⒎諈s不關注這些問題那帶來的災難將是巨大的。

舉幾個例子：微服務之間如何路由？微服務之間如何進行權限認證？微服務超時間如何配置才能規避重試帶來的雪崩？流量變化以怎樣的策略進行擴縮容？而這些問題不解決很可能影響整個系統的可用性。使用微服務架構的團隊經常會遇到這中情況：微服務劃分不合理導致高扇入、高扇出，加一個字段要修改N個模塊、測試N個接口，極其低效。因此要想享受微服務帶來的好處，首先就需要有專家認識到其中的風險，設計靠譜的架構。如果整個團隊中缺乏能夠在微服務架構中撐起系統主干的專家，強行遷移微服務帶來的收益不足以抵消復雜性增加而導致的成本。

(2) 系統應具有以自治為目標的自動化與監控度量能力

我們期望團隊具備這樣一個資產管理系統，可以清晰的看到所有的資產、服務運行情況以及系統還有多少風險項沒有消除。微服務是由大量松耦合服務互相協作構成的系統，一旦切換為微服務意味著資產成倍增長。我們再來回顧下：微服務是正視問題，認為“錯誤一定會發生”，因此要有一系列的手段來用不可靠的微服務構造可靠的系統。這個前提系統能夠監控自身的健康狀態以實現自動恢復，也就是我們需要奔著自動化運維目標前進。

在團隊缺少基礎設施的情況下使用微服務是冒著極大風險的，想象一下系統故障，原來使用單體服務只需要查看少數模塊就可以定位問題發生點，假如拆分為數百個模塊，如果沒有有效的監控系統，該需要多少時間才能定位到異常原因。

3.如何實踐微服務

如何實踐微服務這個話題太大了，遠遠不是一篇文章所能夠承載的，光介紹微服務的書就有《微服務設計》、《微服務架構設計模式》、《微服務分布式構架開發實戰》 等等很多，這里我只是簡單提幾個點與大家一起討論：

如果團隊規模較小，在開始一個新的系統的時我認為應該堅定不移的選擇單體服務。這時候希望團隊對于做出使用的單體的架構師有充分的信任?，F實中往往在立項之初就會給業務定下長遠的目標，但是從技術角度還是應該立足當下，然后隨著業務不斷發展對架構進行及時調整。切不可當業務發展到一定規模時需要拆分微服務時再來指責架構師：“當初我就說應該使用微服務，而不應該使用單體這種落后的架構”。客觀的想一下，與一開始就用微服務比，前期使用單體所節約的工作量，比起遷移所帶來工作是劃算的。我們也應該有這樣的意識：我們沒有辦法設計出一個永遠不變的完美的架構，架構一定是隨著業務發展而不斷變化的。

如果團隊規模較大，我相信沒有哪個系統一開始就由一個“大團隊”開發，而是隨著業務發展系統規模越來越大，團隊所需的人員也不斷增長最終變成“大團隊”。這種情況下應該通過領域建模后基于內部視角將系統劃分為多個子系統，結合康威定律將這些子系統分配給不同的小團隊負責。通常情況下此階段系統已經變的較為復雜，達到了2.1.4小節圖中效率和成本的平衡點，各個小團隊經過評估后可以將所負責的子系統部署為相對獨立的服務，這些服務之間的交互使用統一的規范。而且推薦數據去中心化，每個服務管理自己的數據庫，即使這些數據在不同的子系統都可能出現，但是每個子系統所需要的屬性多少有差異，還是推薦自己維護以便于團隊獨立迭代。實際上就是每個小團隊維護了一個小的子系統，那么參考第一點“如果團隊規模較小”時的結論，各個小的團隊構建服務也從單體服務架構開始，沒有必要從一開始就再拆分多個更小的服務。我所在團隊也一直在探索和實踐單體服務，某業務的核心功能到現在依然是單體，該業務已經發展三年，到現在為止尚沒有因為使用單體而在某一點上明顯拖慢效率。

三、尾巴

回到導語中的問題，單體和微服務誰是毒瘤，都不是，他們只是在某個歷史階段下適應潮流而生的一種普通的架構，并沒有高低貴賤、先進落后之分；而現在，也只是我們結合業務和團隊實際情況進行利益取舍后，供我們選擇的方案之一罷了。