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

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

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

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

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

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

　　2003年左右，諸如DDD和EIP之類(lèi)的軟件設(shè)計(jì)開(kāi)始流行，一些團(tuán)隊(duì)嘗試將應(yīng)用程序開(kāi)發(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ì)在于早期開(kāi)發(fā)簡(jiǎn)單，易于對(duì)程序做重大更改，但隨著業(yè)務(wù)發(fā)展也會(huì)逐漸暴露出開(kāi)發(fā)效率低下，伸縮性差，缺乏故障隔離等問(wèn)題，淪為“單體地獄”。

　　微服務(wù)的出現(xiàn)則提供了一種架構(gòu)思維上的新解：將其中服務(wù)按照業(yè)務(wù)域分為多個(gè)塊，相應(yīng)地，代碼可以被分解成更小的部分，可以獨(dú)立地開(kāi)發(fā)、測(cè)試、部署和更新。它提供了復(fù)雜應(yīng)用程序的持續(xù)交付，使應(yīng)用程序更易于理解，開(kāi)發(fā)，測(cè)試，并且對(duì)架構(gòu)侵蝕更具彈性。尤其在開(kāi)發(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í)也可以專(zhuān)注于解決方案中的一個(gè)微服務(wù)子集。

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

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

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

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

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

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

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

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

　　再者，增加了運(yùn)維的復(fù)雜性。某種程度上，微服務(wù)所提供的敏捷性和開(kāi)發(fā)效率是以增加操作復(fù)雜性為代價(jià)的。服務(wù)被拆成了多個(gè)微服務(wù)，每個(gè)微服務(wù)又會(huì)部署很多套，人肉運(yùn)維顯然就不合適了。另外，所有服務(wù)可能都需要群集以實(shí)現(xiàn)故障轉(zhuǎn)移和彈性。你的系統(tǒng)可能具有數(shù)十個(gè)單獨(dú)的組件，并且在添加新功能時(shí)，它將變得越來(lái)越復(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ù)“塊”的想法，它們彼此分開(kāi)，使用公共的輸入和輸出來(lái)實(shí)現(xiàn)更大的系統(tǒng)集成。所有都指向了微服務(wù)的本質(zhì)關(guān)鍵詞——模塊。

　　太陽(yáng)底下無(wú)新事。

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

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

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

　　如果你做過(guò)微服務(wù)相關(guān)工作的話(huà)，那么可能聽(tīng)說(shuō)過(guò)“康威定律”。這是Melvin Conway在1967年提出的一個(gè)觀(guān)點(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ì)通信開(kāi)銷(xiāo))進(jìn)行“優(yōu)化”的，而不一定是為了解決特定的技術(shù)或性能問(wèn)題。最好通過(guò)業(yè)務(wù)來(lái)劃分團(tuán)隊(duì)，如此一來(lái)，能讓團(tuán)隊(duì)自然的自治自洽，明確業(yè)務(wù)邊界會(huì)減少跨界的溝通成本，每個(gè)小團(tuán)隊(duì)都對(duì)自己的模塊的整個(gè)生命周期負(fù)責(zé)，權(quán)責(zé)明確，沒(méi)有無(wú)效的扯皮推諉踢皮球。

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

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

　　所以說(shuō)在嘗試微服務(wù)之前，首先要考慮清楚的是，是否真的需要減少開(kāi)發(fā)團(tuán)隊(duì)所面臨的依賴(lài)關(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)的過(guò)程，其技術(shù)人員Ben Nadel曾如此描述這種抉擇的原因：

　　“多年來(lái)，InVision必須要從組織和基礎(chǔ)設(shè)施方面進(jìn)行發(fā)展。這意味著，在其背后，有一個(gè)較老的‘遺留’平臺(tái)和一個(gè)不斷發(fā)展的‘現(xiàn)代’平臺(tái)。隨著越來(lá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é)越來(lái)越多的服務(wù)。這意味著：人數(shù)變少了，但是代碼倉(cāng)庫(kù)變多了，編程語(yǔ)言變多了，數(shù)據(jù)庫(kù)變多了，監(jiān)控儀表盤(pán)變多了，錯(cuò)誤日志變多了。”

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

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

　　4、結(jié)語(yǔ)

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

　　如果你的系統(tǒng)不夠大，團(tuán)隊(duì)成員不同多，現(xiàn)有的技術(shù)架構(gòu)完全可以滿(mǎn)足業(yè)務(wù)需求，那就根本沒(méi)必要選擇微服務(wù)。微服務(wù)的重點(diǎn)從來(lái)不是“微”，而是成為“大小合適”的服務(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)之間的取舍。