過去十年最大的架構(gòu)錯(cuò)誤，微服務(wù)又被潑冷水了！

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

　　在微服務(wù)如日中天的幾年中，很多公司都嘗試進(jìn)行了微服務(wù)轉(zhuǎn)型。彼時(shí)，微服務(wù)架構(gòu)提供了一種新穎的重構(gòu)現(xiàn)有系統(tǒng)的方法，并以提供模塊化、可擴(kuò)展性、可用性的能力成為軟件開發(fā)行業(yè)的新寵。

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

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

　　1、為什么我們選擇微服務(wù)

　　2003年左右，諸如DDD和EIP之類的軟件設(shè)計(jì)開始流行，一些團(tuán)隊(duì)嘗試將應(yīng)用程序開發(fā)為模塊化服務(wù)，但傳統(tǒng)的基礎(chǔ)結(jié)構(gòu)對(duì)模塊化部署并不友好。而隨著云計(jì)算的發(fā)展，云托管的普及，像Heroku這樣的平臺(tái)又為模塊化部署提供了便利。這也為微服務(wù)打造細(xì)粒度和可重用的功能提供了可能性。

　　傳統(tǒng)的單體架構(gòu)優(yōu)缺點(diǎn)都很鮮明，優(yōu)勢(shì)在于早期開發(fā)簡(jiǎn)單，易于對(duì)程序做重大更改，但隨著業(yè)務(wù)發(fā)展也會(huì)逐漸暴露出開發(fā)效率低下，伸縮性差，缺乏故障隔離等問題，淪為“單體地獄”。

　　微服務(wù)的出現(xiàn)則提供了一種架構(gòu)思維上的新解：將其中服務(wù)按照業(yè)務(wù)域分為多個(gè)塊，相應(yīng)地，代碼可以被分解成更小的部分，可以獨(dú)立地開發(fā)、測(cè)試、部署和更新。它提供了復(fù)雜應(yīng)用程序的持續(xù)交付，使應(yīng)用程序更易于理解，開發(fā)，測(cè)試，并且對(duì)架構(gòu)侵蝕更具彈性。尤其在開發(fā)大型應(yīng)用程序時(shí)，這種優(yōu)勢(shì)會(huì)愈發(fā)突出。

　　在微服務(wù)相關(guān)的推薦文章中，對(duì)微服務(wù)的褒獎(jiǎng)大體可歸因?yàn)橐韵聨追N：

　　保證服務(wù)的可伸縮性：由于每個(gè)服務(wù)都是獨(dú)立的組件，因此可以使用更多容器部署擴(kuò)展，從而實(shí)現(xiàn)更有效的容量規(guī)劃。

　　降低耦合簡(jiǎn)化了團(tuán)隊(duì)協(xié)作：?jiǎn)我挥猛驹O(shè)計(jì)意味著它們可以由較小的團(tuán)隊(duì)構(gòu)建和維護(hù)。每個(gè)團(tuán)隊(duì)可以是跨職能的，同時(shí)也可以專注于解決方案中的一個(gè)微服務(wù)子集。

　　改善了故障隔離：在微服務(wù)架構(gòu)中，如果單個(gè)模塊受到影響，則可以輕松拆卸或解決，而不會(huì)影響應(yīng)用程序的其他部分。

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

　　提升開發(fā)效率提高生產(chǎn)力：不同的團(tuán)隊(duì)同時(shí)處理不同的組件，而無需等待一個(gè)團(tuán)隊(duì)完成任務(wù)。從而提升工作效率，加快產(chǎn)品發(fā)布速度。

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

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

　　微服務(wù)在解決了很多單體架構(gòu)的痼疾后也帶來了其他挑戰(zhàn)。我們可以列舉其中幾個(gè)：

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

　　其次，提高了開發(fā)的技術(shù)門檻。鑒于微服務(wù)是一個(gè)分布式系統(tǒng)，它也帶來了開發(fā)分布式應(yīng)用程序相關(guān)的復(fù)雜性的代價(jià)，比如獨(dú)立的數(shù)據(jù)模型、微服務(wù)之間的彈性通信、最終一致性和操作復(fù)雜性等。開發(fā)和運(yùn)行大規(guī)模的分布式服務(wù)并非易事。隨著企業(yè)發(fā)展而擁有的分布式系統(tǒng)，引入數(shù)十個(gè)微服務(wù)進(jìn)行推理已經(jīng)很難了，更不用說數(shù)百個(gè)各有風(fēng)險(xiǎn)的微服務(wù)。

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

　　在稍稍權(quán)衡了微服務(wù)的褒貶兩面時(shí)，我們需要重新審視的是，當(dāng)談起微服務(wù)時(shí)，我們看重的到底是什么;當(dāng)我們選擇微服務(wù)時(shí)，我們關(guān)注的核心到底是什么。

　　其實(shí)，在上文中列舉的關(guān)于微服務(wù)的優(yōu)點(diǎn)中，稍加留心就可以發(fā)現(xiàn)，其中大半論點(diǎn)都折射出了一個(gè)共同的主題：創(chuàng)建和維護(hù)小的、獨(dú)立的代碼和數(shù)據(jù)“塊”的想法，它們彼此分開，使用公共的輸入和輸出來實(shí)現(xiàn)更大的系統(tǒng)集成。所有都指向了微服務(wù)的本質(zhì)關(guān)鍵詞——模塊。

　　太陽底下無新事。

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

　　來自David Parnas的論文《關(guān)于將系統(tǒng)分解為模塊的標(biāo)準(zhǔn)》寫于1971年，其中定義良好的“獨(dú)立的、不同的程序模塊”涵蓋了微服務(wù)本質(zhì)上的多數(shù)優(yōu)點(diǎn)�？梢哉f，對(duì)于系統(tǒng)“模塊化”的追求已經(jīng)有半個(gè)世紀(jì)的悠久歷史。那么微服務(wù)又為何會(huì)引來諸多追捧呢?因?yàn)槲⒎��?wù)與其說是解決了技術(shù)的問題，更多的是解決了人的問題，其關(guān)鍵詞不是服務(wù)，也不是分布式系統(tǒng)，而是組織清晰度。

　　3、是架構(gòu)問題，更是“人”的問題

　　如果你做過微服務(wù)相關(guān)工作的話，那么可能聽說過“康威定律”。這是Melvin Conway在1967年提出的一個(gè)觀點(diǎn)，大致意思是一個(gè)組織的系統(tǒng)通常被設(shè)計(jì)成這個(gè)組織溝通結(jié)構(gòu)的副本。

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

　　— M. Conway

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

　　微服務(wù)可以說會(huì)在一定程度上倒逼組織結(jié)構(gòu)。通常IT公司的崗位會(huì)劃分為產(chǎn)品、開發(fā)、測(cè)試、運(yùn)維等等，有些公司甚至?xí)�劃分成不同部門。一個(gè)需求從開發(fā)到上線，會(huì)在不同部門間不斷流轉(zhuǎn)，而微服務(wù)化往往是為了加速業(yè)務(wù)響應(yīng)，減少開發(fā)團(tuán)隊(duì)所面臨的依賴關(guān)系。

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

　　所以說在嘗試微服務(wù)之前，首先要考慮清楚的是，是否真的需要減少開發(fā)團(tuán)隊(duì)所面臨的依賴關(guān)系，團(tuán)隊(duì)對(duì)他們正在嘗試構(gòu)建的東西是否有清晰的愿景，以及是否愿意承擔(dān)可能因此導(dǎo)致的風(fēng)險(xiǎn)。

　　軟件服務(wù)公司InVision的技術(shù)架構(gòu)經(jīng)歷了從微服務(wù)合并回單體架構(gòu)的過程，其技術(shù)人員Ben Nadel曾如此描述這種抉擇的原因：

　　“多年來，InVision必須要從組織和基礎(chǔ)設(shè)施方面進(jìn)行發(fā)展。這意味著，在其背后，有一個(gè)較老的‘遺留’平臺(tái)和一個(gè)不斷發(fā)展的‘現(xiàn)代’平臺(tái)。隨著越來越多的團(tuán)隊(duì)遷移至‘現(xiàn)代’平臺(tái)，這些團(tuán)隊(duì)之前負(fù)責(zé)的服務(wù)則要移交給剩下的‘遺留’團(tuán)隊(duì)。”

　　遺憾的是，Ben Nadel的團(tuán)隊(duì)就是“遺留”團(tuán)隊(duì)。“這個(gè)團(tuán)隊(duì)已經(jīng)緩慢，但穩(wěn)定地負(fù)責(zé)越來越多的服務(wù)。這意味著：人數(shù)變少了，但是代碼倉庫變多了，編程語言變多了，數(shù)據(jù)庫變多了，監(jiān)控儀表盤變多了，錯(cuò)誤日志變多了。”

　　簡(jiǎn)而言之，康威定律為組織帶來的所有收益，隨著時(shí)間的推移，都變成“遺留”團(tuán)隊(duì)的負(fù)債。“所以，我們一直在努力‘調(diào)整’責(zé)任域，讓平衡回歸康威定律�；蛘�，換句話說，我們?cè)趪L試改變服務(wù)邊界以匹配團(tuán)隊(duì)的邊界。這意味著，將微服務(wù)重新合并為單體架構(gòu)。”

　　正因?yàn)槲⒎��?wù)不只是涉及到技術(shù)架構(gòu)的問題，當(dāng)它牽涉到“人”的問題時(shí)，往往會(huì)導(dǎo)致“水能載舟亦能覆舟”的效果。

　　4、結(jié)語

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

　　如果你的系統(tǒng)不夠大，團(tuán)隊(duì)成員不同多，現(xiàn)有的技術(shù)架構(gòu)完全可以滿足業(yè)務(wù)需求，那就根本沒必要選擇微服務(wù)。微服務(wù)的重點(diǎn)從來不是“微”，而是成為“大小合適”的服務(wù)，負(fù)責(zé)“合適數(shù)量”的功能。這里的合適也并非靜態(tài)標(biāo)準(zhǔn)，它往往取決于團(tuán)隊(duì)的技能集、組織狀態(tài)、投資回報(bào)率等多重因素。更重要的是，這也并非是單純的技術(shù)領(lǐng)域的選擇，同樣是關(guān)于“人”和“組織”結(jié)構(gòu)之間的取舍。