過去十年最大的架構錯誤，微服務又被潑冷水了！

　　自微服務這個概念誕生以來，就伴隨著諸多熱議。人們要么愛它，要么恨它，似乎沒有什么中間地帶。

　　在微服務如日中天的幾年中，很多公司都嘗試進行了微服務轉型。彼時，微服務架構提供了一種新穎的重構現有系統的方法，并以提供模塊化、可擴展性、可用性的能力成為軟件開發行業的新寵。

　　但任何一種架構都不會是適配所有問題的萬能鑰匙，微服務也不例外。近年來，一些公司放棄微服務實踐、選擇退回單體架構的消息也不時出現在大眾視野。不久前，GitHub前CTO Jason Warner更是直接在推特上表示，“我確信過去十年中，最大的架構錯誤之一就是全面使用微服務。”一時掀起漣漪無數。

　　我們知道，微服務不會適用于所有公司，但無論是選擇它還是放棄它，其背后的根由依舊值得深思。

　　1、為什么我們選擇微服務

　　2003年左右，諸如DDD和EIP之類的軟件設計開始流行，一些團隊嘗試將應用程序開發為模塊化服務，但傳統的基礎結構對模塊化部署并不友好。而隨著云計算的發展，云托管的普及，像Heroku這樣的平臺又為模塊化部署提供了便利。這也為微服務打造細粒度和可重用的功能提供了可能性。

　　傳統的單體架構優缺點都很鮮明，優勢在于早期開發簡單，易于對程序做重大更改，但隨著業務發展也會逐漸暴露出開發效率低下，伸縮性差，缺乏故障隔離等問題，淪為“單體地獄”。

　　微服務的出現則提供了一種架構思維上的新解：將其中服務按照業務域分為多個塊，相應地，代碼可以被分解成更小的部分，可以獨立地開發、測試、部署和更新。它提供了復雜應用程序的持續交付，使應用程序更易于理解，開發，測試，并且對架構侵蝕更具彈性。尤其在開發大型應用程序時，這種優勢會愈發突出。

　　在微服務相關的推薦文章中，對微服務的褒獎大體可歸因為以下幾種：

　　保證服務的可伸縮性：由于每個服務都是獨立的組件，因此可以使用更多容器部署擴展，從而實現更有效的容量規劃。

　　降低耦合簡化了團隊協作：單一用途設計意味著它們可以由較小的團隊構建和維護。每個團隊可以是跨職能的，同時也可以專注于解決方案中的一個微服務子集。

　　改善了故障隔離：在微服務架構中，如果單個模塊受到影響，則可以輕松拆卸或解決，而不會影響應用程序的其他部分。

　　易于修改技術堆棧：通過微服務，軟件開發公司可以在特定組件上嘗試新的堆�；蜃钚录夹g。由于沒有依賴性問題，軟件開發人員可以避免使用特定的技術堆棧。大數據世界中的各種技術，包括開源社區，在微服務架構中都能很好地工作。

　　提升開發效率提高生產力：不同的團隊同時處理不同的組件，而無需等待一個團隊完成任務。從而提升工作效率，加快產品發布速度。

　　可以肯定的是，以微服務架構搭建的系統提供了大量的好處，比如獨立部署、強大的子系統邊界、保障了技術多樣性等等，這也是微服務架構一度為眾多公司所青睞的原因。不過，凡事一體兩面，微服務架構同樣有其弊端。

　　2、我們需要的不是微服務，而是模塊

　　微服務在解決了很多單體架構的痼疾后也帶來了其他挑戰。我們可以列舉其中幾個：

　　首先，判斷是不是適合微服務化，也要看具體的業務場景。如果只是為了拆分而拆分，那無疑沒有意義。而且微服務在設計上也更為復雜，比如，拆成幾個微服務?新需求來了，是新建一個微服務還是在老系統上改造?都需要綜合考量�？梢哉f，一個設計糟糕的微服務架構比一個設計糟糕的單體架構要麻煩得多。

　　其次，提高了開發的技術門檻。鑒于微服務是一個分布式系統，它也帶來了開發分布式應用程序相關的復雜性的代價，比如獨立的數據模型、微服務之間的彈性通信、最終一致性和操作復雜性等。開發和運行大規模的分布式服務并非易事。隨著企業發展而擁有的分布式系統，引入數十個微服務進行推理已經很難了，更不用說數百個各有風險的微服務。

　　再者，增加了運維的復雜性。某種程度上，微服務所提供的敏捷性和開發效率是以增加操作復雜性為代價的。服務被拆成了多個微服務，每個微服務又會部署很多套，人肉運維顯然就不合適了。另外，所有服務可能都需要群集以實現故障轉移和彈性。你的系統可能具有數十個單獨的組件，并且在添加新功能時，它將變得越來越復雜。

　　在稍稍權衡了微服務的褒貶兩面時，我們需要重新審視的是，當談起微服務時，我們看重的到底是什么;當我們選擇微服務時，我們關注的核心到底是什么。

　　其實，在上文中列舉的關于微服務的優點中，稍加留心就可以發現，其中大半論點都折射出了一個共同的主題：創建和維護小的、獨立的代碼和數據“塊”的想法，它們彼此分開，使用公共的輸入和輸出來實現更大的系統集成。所有都指向了微服務的本質關鍵詞——模塊。

　　太陽底下無新事。

　　自20世紀70年代以來，“模塊”這個概念一直是大多數編程語言的核心。CLR (c#， f#， Visual Basic…)上的“程序集”，JVM (Java, Kotlin, Clojure, Scala, Groovy…)上的“jar”或“包”，或者操作系統的動態鏈接庫(Windows上的dll, sos或*nixes上的dll，當然macOS有隱藏在/Library目錄中的“框架”)。不管形式如何，在概念層面上，它們都是模塊。它們都有不同的內部格式，但都有相同的基本目的：可以重用的，獨立被構建、被管理、被部署的代碼單元。

　　來自David Parnas的論文《關于將系統分解為模塊的標準》寫于1971年，其中定義良好的“獨立的、不同的程序模塊”涵蓋了微服務本質上的多數優點�？梢哉f，對于系統“模塊化”的追求已經有半個世紀的悠久歷史。那么微服務又為何會引來諸多追捧呢?因為微服務與其說是解決了技術的問題，更多的是解決了人的問題，其關鍵詞不是服務，也不是分布式系統，而是組織清晰度。

　　3、是架構問題，更是“人”的問題

　　如果你做過微服務相關工作的話，那么可能聽說過“康威定律”。這是Melvin Conway在1967年提出的一個觀點，大致意思是一個組織的系統通常被設計成這個組織溝通結構的副本。

　　organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

　　— M. Conway

　　簡言之，你想要什么樣的系統設計，就架構什么樣的團隊。解決方案是是圍繞團隊結構(和團隊通信開銷)進行“優化”的，而不一定是為了解決特定的技術或性能問題。最好通過業務來劃分團隊，如此一來，能讓團隊自然的自治自洽，明確業務邊界會減少跨界的溝通成本，每個小團隊都對自己的模塊的整個生命周期負責，權責明確，沒有無效的扯皮推諉踢皮球。

　　微服務可以說會在一定程度上倒逼組織結構。通常IT公司的崗位會劃分為產品、開發、測試、運維等等，有些公司甚至會劃分成不同部門。一個需求從開發到上線，會在不同部門間不斷流轉，而微服務化往往是為了加速業務響應，減少開發團隊所面臨的依賴關系。

　　在微服務架構下，其組織架構也必然要做出相應調整，這個團隊要么必須由各種具備不同技能的人員組合而成，要么每個團隊成員具備完整的技能(所謂的 "全棧式開發")。同時這個團隊也要對一個或多個微服務的迭代和運維負責。當然，康威定律的收益在很大程度上依賴于在哪里劃分邊界以及這些邊界隨時間的推移該如何變化。

　　所以說在嘗試微服務之前，首先要考慮清楚的是，是否真的需要減少開發團隊所面臨的依賴關系，團隊對他們正在嘗試構建的東西是否有清晰的愿景，以及是否愿意承擔可能因此導致的風險。

　　軟件服務公司InVision的技術架構經歷了從微服務合并回單體架構的過程，其技術人員Ben Nadel曾如此描述這種抉擇的原因：

　　“多年來，InVision必須要從組織和基礎設施方面進行發展。這意味著，在其背后，有一個較老的‘遺留’平臺和一個不斷發展的‘現代’平臺。隨著越來越多的團隊遷移至‘現代’平臺，這些團隊之前負責的服務則要移交給剩下的‘遺留’團隊。”

　　遺憾的是，Ben Nadel的團隊就是“遺留”團隊。“這個團隊已經緩慢，但穩定地負責越來越多的服務。這意味著：人數變少了，但是代碼倉庫變多了，編程語言變多了，數據庫變多了，監控儀表盤變多了，錯誤日志變多了。”

　　簡而言之，康威定律為組織帶來的所有收益，隨著時間的推移，都變成“遺留”團隊的負債。“所以，我們一直在努力‘調整’責任域，讓平衡回歸康威定律�；蛘�，換句話說，我們在嘗試改變服務邊界以匹配團隊的邊界。這意味著，將微服務重新合并為單體架構。”

　　正因為微服務不只是涉及到技術架構的問題，當它牽涉到“人”的問題時，往往會導致“水能載舟亦能覆舟”的效果。

　　4、結語

　　很多公司嘗試過微服務轉型，有的轉型成功，有的中途放棄。原因多種多樣，畢竟采用微服務，實際是在轉移復雜性，而不是消解復雜性。

　　如果你的系統不夠大，團隊成員不同多，現有的技術架構完全可以滿足業務需求，那就根本沒必要選擇微服務。微服務的重點從來不是“微”，而是成為“大小合適”的服務，負責“合適數量”的功能。這里的合適也并非靜態標準，它往往取決于團隊的技能集、組織狀態、投資回報率等多重因素。更重要的是，這也并非是單純的技術領域的選擇，同樣是關于“人”和“組織”結構之間的取舍。