作者 | Scott Rogowski
策劃 | 萬(wàn)佳
轉(zhuǎn)發(fā)鏈接：https://mp.weixin.qq.com/s/QtYw0xdC3KN2gNAqHubIOg
前言
在現(xiàn)代技術(shù)公司（無(wú)論大小）的架構(gòu)中，微服務(wù)已經(jīng)無(wú)處不在。但是，它們真的比以前的開(kāi)發(fā)模型更優(yōu)秀嗎？在這篇文章中，我將揭穿工程師們關(guān)于微服務(wù)所講述的七大謊言，以及為什么它可能是一種反模式。
免責(zé)聲明 1：我不是架構(gòu)師，也沒(méi)假裝自己是架構(gòu)師。本文內(nèi)容只是我多年來(lái)作為軟件開(kāi)發(fā)人員 / 經(jīng)理所做的觀察總結(jié)。我曾見(jiàn)證兩家公司在微服務(wù)架構(gòu)的壓力下陷入泥潭。由于很少有人深度質(zhì)疑這種新生范式，因此我想表達(dá)自己的聲音。不過(guò)，我經(jīng)驗(yàn)有限，所以也歡迎反饋意見(jiàn)。
免責(zé)聲明 2：互聯(lián)網(wǎng)上也有其他標(biāo)題相似的演講 / 文章，這里就不糾結(jié)這種相似度了。
單體架構(gòu)和微服務(wù)之間有何區(qū)別？
開(kāi)始研究謊言前，我們先來(lái)定義一下術(shù)語(yǔ)。后端軟件架構(gòu)可以分為單體和微服務(wù)兩種。單體架構(gòu)指的是由一臺(tái)或多臺(tái)服務(wù)器運(yùn)行單個(gè)應(yīng)用程序，其通常從單個(gè)存儲(chǔ)庫(kù)中部署。使用多臺(tái)服務(wù)器時(shí)，這些服務(wù)器將運(yùn)行相同的代碼。從 90 年代到 2000 年代，多數(shù)情況下這都是默認(rèn)的架構(gòu)。
隨著互聯(lián)網(wǎng)的發(fā)展，大型公司開(kāi)始面臨單體架構(gòu)的局限。為解決這一問(wèn)題，公司開(kāi)始將其代碼分割成在不同服務(wù)器上運(yùn)行的多個(gè)組件。例如，一家公司可能會(huì)有運(yùn)行日志記錄的服務(wù)、調(diào)用外部 API 的服務(wù)以及管理數(shù)據(jù)庫(kù)的服務(wù)。亞馬遜 AWS 在這一風(fēng)潮中扮演了重要角色，因?yàn)樗尣渴鸱?wù)器和管理基礎(chǔ)設(shè)施的工作變得非常容易。
隨著時(shí)間流逝，中小型公司也開(kāi)始接受這種新的發(fā)展范式。很快，一個(gè)圍繞微服務(wù)的產(chǎn)業(yè)發(fā)展壯大起來(lái)，它逐漸成為尋求擴(kuò)展的企業(yè)默認(rèn)架構(gòu)。不幸的是，現(xiàn)在有許多公司由于這種選擇而掉進(jìn)了各種之前想不到的坑里。
1謊言一：跨服務(wù)的關(guān)注點(diǎn)分離降低了復(fù)雜度
“[關(guān)注點(diǎn)分離]”指的是在不相關(guān)的代碼間應(yīng)存在隔離墻。當(dāng)不相關(guān)的代碼需要協(xié)同工作時(shí)，應(yīng)該使用抽象良好的接口并盡量減少狀態(tài)共享。很多入門(mén)編程課程都將其視為標(biāo)準(zhǔn)的軟件開(kāi)發(fā)公理。你的代碼對(duì)其他代碼的了解，越少越好。同樣，一個(gè)函數(shù)執(zhí)行的功能越多，你就越需要考慮運(yùn)動(dòng)部件之間的復(fù)雜關(guān)系（即復(fù)雜度）。而且，我們作為合格的工程師就應(yīng)該努力降低復(fù)雜度。
我堅(jiān)信這一公理。從邏輯上講，分離關(guān)注點(diǎn)的最佳方法是否就是讓你的無(wú)關(guān)代碼運(yùn)行在不同的服務(wù)（服務(wù)之間以 API 溝通）中呢？
不，并非如此。
經(jīng)典的單進(jìn)程關(guān)注點(diǎn)分離之所以有效，是因?yàn)樗梢宰钚』⒑?jiǎn)化不相關(guān)代碼之間的接口。在設(shè)計(jì)良好的程序中，此接口可以只有帶 return 語(yǔ)句的單個(gè)函數(shù)調(diào)用。不相關(guān)代碼之間的邊界本質(zhì)上是復(fù)雜的，而簡(jiǎn)單的接口有助于管理這種復(fù)雜性。
相比之下，在微服務(wù)中，函數(shù)調(diào)用被替換為網(wǎng)絡(luò)請(qǐng)求。這種新的服務(wù)間障礙嚴(yán)格來(lái)說(shuō)更加復(fù)雜且更不可靠。首先，每個(gè)網(wǎng)絡(luò)調(diào)用都需要一定數(shù)量的樣板。其次，工程師現(xiàn)在需要默認(rèn)任何服務(wù)隨時(shí)會(huì)失效。相反，在單體中，當(dāng)代碼失敗時(shí)整個(gè)服務(wù)都會(huì)失敗。盡管這聽(tīng)起來(lái)很糟糕，但由于現(xiàn)在只有一種故障情況，因此它更易于管理。
在實(shí)踐中更糟
左下方的圖表是幾年前 Uber 的微服務(wù)架構(gòu)。它很簡(jiǎn)單，很容易理解。右邊是 Uber 的實(shí)際服務(wù)地圖。
我敢說(shuō) Uber 的任何人都不知道這個(gè)架構(gòu)是如何工作的。曾在使用微服務(wù)架構(gòu)的大型公司工作過(guò)的人都知道，Uber 的經(jīng)驗(yàn)并不是特例。
模型與現(xiàn)實(shí)之間存在這種差異的原因有兩個(gè)。首先，這些圖表通常過(guò)于簡(jiǎn)化。架構(gòu)師設(shè)計(jì)這些圖表是為了交流，而非完美反映現(xiàn)實(shí)。但因?yàn)樗鼈冸[藏了復(fù)雜性，也就容易誤導(dǎo)決策。如果 Uber 的技術(shù)領(lǐng)導(dǎo)者知道自己的架構(gòu)會(huì)變成什么樣，他們還會(huì)走這條路嗎？
其次，一旦你投身于微服務(wù)，隨后的所有技術(shù)決策都將受其影響。因此，開(kāi)發(fā)新功能時(shí)總要啟動(dòng)新的服務(wù)。架構(gòu)圖很快就會(huì)變得非常復(fù)雜，膨脹成上圖那種密密麻麻的網(wǎng)狀結(jié)構(gòu)。
2謊言二：微服務(wù)提高開(kāi)發(fā)速度
當(dāng)你采用“關(guān)注點(diǎn)分離”公理并將其應(yīng)用在開(kāi)發(fā)人員頭上時(shí)會(huì)發(fā)生什么？你會(huì)得到一些孤立的團(tuán)隊(duì)，他們之間各自獨(dú)立。從表面上看這似乎是有益的。如果團(tuán)隊(duì)只需要操心自己的服務(wù)，那將減輕他們的認(rèn)知負(fù)擔(dān)，并提高他們的生產(chǎn)力。現(xiàn)在，工程師無(wú)需擔(dān)心基礎(chǔ)架構(gòu)中其他部分的復(fù)雜性了。
問(wèn)題在于，大多數(shù)新功能都需要一些跨多個(gè)服務(wù)的補(bǔ)丁。
許多功能需要在兩個(gè)或多個(gè)服務(wù)上開(kāi)發(fā)
開(kāi)發(fā)多服務(wù)功能需要在具有不同優(yōu)先級(jí)和能力的團(tuán)隊(duì)之間安排大量會(huì)議。考慮到他們從事的多個(gè)不同項(xiàng)目，這些團(tuán)隊(duì)可能需要異步協(xié)作。你現(xiàn)在還需要交付經(jīng)理來(lái)分配工作和管理迭代。
從技術(shù)角度來(lái)看，實(shí)現(xiàn)多服務(wù)功能可能需要編輯多個(gè)存儲(chǔ)庫(kù)。至少，它需要一種方法來(lái)測(cè)試在多個(gè)服務(wù)上運(yùn)行的代碼。
對(duì)許多公司而言，這種多服務(wù)測(cè)試的需求是事后才會(huì)意識(shí)到的。架構(gòu)師在設(shè)計(jì)技術(shù)棧時(shí)會(huì)假設(shè)大多數(shù)開(kāi)發(fā)工作都將在單個(gè)服務(wù)上進(jìn)行。多服務(wù)功能將很少見(jiàn)。你如何手動(dòng)測(cè)試多服務(wù)功能？你需要在機(jī)器上啟動(dòng)多個(gè)容器，并仔細(xì)設(shè)置每個(gè)容器的狀態(tài)。那單元測(cè)試呢？你將在哪里對(duì)多服務(wù)功能進(jìn)行單元測(cè)試？是倉(cāng)庫(kù) A 還是倉(cāng)庫(kù) B？文檔寫(xiě)好了嗎？部署往往會(huì)破壞未調(diào)整好的服務(wù)。很容易想象，數(shù)據(jù)流中的一個(gè)小錯(cuò)誤會(huì)破壞多個(gè)下游服務(wù)。我們應(yīng)該期望工程師理解所有可能依賴其代碼的下游服務(wù)嗎？
如果你的組織沒(méi)有投入大量的工程資源來(lái)構(gòu)建多服務(wù)測(cè)試流程，那么除了最常見(jiàn)的功能之外，開(kāi)發(fā)新功能的速度會(huì)像蝸牛般緩慢。如果沒(méi)有質(zhì)量測(cè)試框架，看似簡(jiǎn)單的任務(wù)（例如“添加分頁(yè)”）也可能會(huì)變成歷時(shí)數(shù)月、跨多個(gè)團(tuán)隊(duì)的工作。
3謊言三：部署眾多小型服務(wù)比部署整個(gè)應(yīng)用更安全
“回滾”是現(xiàn)代軟件工程需要面對(duì)的現(xiàn)實(shí)。作為工程師，當(dāng)你部署的代碼會(huì)破壞某些功能時(shí)，必須回滾部署并還原提交。沒(méi)有人想要回滾——尤其是部署代碼的工程師。但是，好的公司知道錯(cuò)誤的部署總有可能出現(xiàn)，因此必須對(duì)其進(jìn)行管理。
微服務(wù)架構(gòu)的一個(gè)觀點(diǎn)是，部署多個(gè)獨(dú)立服務(wù)比部署整個(gè)應(yīng)用更安全。當(dāng)一項(xiàng)服務(wù)中斷時(shí)，其他服務(wù)還有回退可用。整個(gè)應(yīng)用程序?qū)⒗^續(xù)運(yùn)行，客戶不會(huì)有什么感覺(jué)。
這種方法存在多個(gè)問(wèn)題。
首先，這要假設(shè)你的服務(wù)可以容忍其他任何服務(wù)的隨機(jī)消失。這是 Netflix 的“Chaos Monkey”方法。但是，將其構(gòu)建到服務(wù)中并非易事，測(cè)試它需要資源，并且除非這是工程的最優(yōu)先事項(xiàng)，否則實(shí)踐中人們多大程度上會(huì)遵守這一要求就不一定了。
https://netflix.github.io/chaosmonkey/
其次，部署多服務(wù)功能時(shí)，服務(wù)的上線時(shí)間會(huì)有所不同。在一段時(shí)間里，你的那些服務(wù)將有不同的版本。對(duì)此有多種處理方法。你是否在半夜部署？你是否并行維護(hù)不同的 API 版本？你是否使用托管流？所有解決方案都需要額外的工程資源。如果部署意外破壞了（甚至不是部署的一部分）服務(wù)中的狀態(tài)，會(huì)發(fā)生什么情況？你是否有針對(duì)任何意外情況的預(yù)案？
雖然單體部署也會(huì)出錯(cuò)，但是有多種方法可以緩解這種情況（藍(lán)色 / 綠色、金絲雀等等）。雖然這些方法也可用于微服務(wù)，但是設(shè)置和管理安全部署并非易事，應(yīng)對(duì)一項(xiàng)服務(wù)總比應(yīng)對(duì)多個(gè)服務(wù)要容易些。
4謊言四：分開(kāi)擴(kuò)展服務(wù)通常是有利的
在每個(gè)應(yīng)用程序中，都有經(jīng)常運(yùn)行的部分和很少運(yùn)行的部分。很少運(yùn)行的部件比頻繁運(yùn)行的部件需要的資源要少一些。那么分開(kāi)擴(kuò)展這些部件是否有意義？
從根本上講，擴(kuò)展軟件的原因是因?yàn)槟愕能浖枰嗟暮诵馁Y源。這些資源可能是 CPU 周期、內(nèi)存、磁盤(pán)空間或網(wǎng)絡(luò)。例如，當(dāng) CPU 以 100％運(yùn)行時(shí)，可以啟動(dòng)另一個(gè)服務(wù)來(lái)減輕壓力。
對(duì)于大多數(shù)應(yīng)用，水平擴(kuò)展（克隆單體）就足夠了。水平擴(kuò)展的復(fù)雜度較低，許多云服務(wù)都可以用很少的配置來(lái)做到這一點(diǎn)。
相比之下，選擇分開(kāi)擴(kuò)展許多微服務(wù)有兩個(gè)常見(jiàn)原因。首先，如果你的代碼具有實(shí)質(zhì)上并行的部分，則在某些情況下將計(jì)算塊分配給不同的“worker”可能會(huì)有些意義。重要的是，相對(duì)于每個(gè)任務(wù)的總計(jì)算量，數(shù)據(jù)傳輸和加速的開(kāi)銷(xiāo)必須夠低。因此，將十個(gè)計(jì)算塊（每個(gè)計(jì)算耗時(shí) 10ms）發(fā)送到服務(wù)器，開(kāi)銷(xiāo)卻為 100ms 就沒(méi)有并行的價(jià)值了。因?yàn)轫樞驁?zhí)行耗時(shí)是 10x10ms=100ms，而并行卻是 10ms+100ms=110ms。但是，如果每次計(jì)算都花費(fèi) 100 毫秒，則將它們并行化就能節(jié)省時(shí)間。
其次，如果資源需求在整個(gè)請(qǐng)求中出現(xiàn)變化，則單獨(dú)擴(kuò)展各個(gè)微服務(wù)可能是有意義的。例如，如果一個(gè)請(qǐng)求在開(kāi)始時(shí)是受內(nèi)存限制的，而在結(jié)束時(shí)是 CPU 限制的，那么就可以將請(qǐng)求的開(kāi)始部分放在高內(nèi)存服務(wù)中，將結(jié)束部分放在高 CPU 服務(wù)中。即便如此，除非你是獨(dú)角獸級(jí)別的企業(yè)，否則分開(kāi)擴(kuò)展服務(wù)帶來(lái)的財(cái)務(wù)優(yōu)勢(shì)可能也無(wú)法抵消額外的復(fù)雜性。
另外，你試圖省錢(qián)的做法可能會(huì)適得其反：
快樂(lè)的云客戶
5謊言五：微服務(wù)架構(gòu)性能更高
我在學(xué)校學(xué)到了一些經(jīng)驗(yàn)法則：
- 讀取內(nèi)存所需的時(shí)間是讀取二級(jí)緩存的 10 倍；
- 讀取硬盤(pán)驅(qū)動(dòng)器所需時(shí)間是讀取內(nèi)存的 10 倍；
- 從網(wǎng)絡(luò)讀取所需的時(shí)間是從硬盤(pán)讀取的 10 倍。
這些數(shù)字是粗略的近似值。我們來(lái)看一下數(shù)據(jù)中心中的網(wǎng)絡(luò)通信與從內(nèi)存讀取之間的實(shí)際差異：2009 年，從內(nèi)存中順序讀取 1MB 的耗時(shí)估計(jì)為 250000ns；2019 年，在 AWS 數(shù)據(jù)中心中，兩個(gè) EC2 實(shí)例之間的通信速度可以達(dá)到 5Gbps。
http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf
https://aws.amazon.com/blogs/aws/the-floodgates-are-open-increased-network-bandwidth-for-ec2-instances/
簡(jiǎn)單算一算：
- 2009 年的內(nèi)存：0.25 毫秒內(nèi) 1 兆字節(jié)；
- 2019 年的數(shù)據(jù)中心：1 秒內(nèi) 5Gbit=1 秒內(nèi) 0.625GBytes=0.64 秒內(nèi) 1 兆字節(jié)
覺(jué)得差距不算大？可我們要意識(shí)到：
- 上面的網(wǎng)絡(luò)速度是最好的情況；
- 我們正在對(duì)比 2009 年與 2019 年的指標(biāo)；
- 要通過(guò)超高速的 AWS 網(wǎng)絡(luò)發(fā)送這一兆數(shù)據(jù)，我們?nèi)匀恍枰獜膬?nèi)存中讀取它。
假設(shè)你只有一個(gè)依賴項(xiàng)，那么這也意味著幾千倍的速度差距。實(shí)際情況中這一差距還會(huì)大得多。
難怪我們現(xiàn)在使用字節(jié)流來(lái)讓每個(gè)請(qǐng)求快那么幾毫秒。當(dāng)然，對(duì)于字節(jié)流來(lái)說(shuō)，調(diào)試服務(wù)間通信也是需要工具的。
6謊言六：管理多個(gè)服務(wù)并不難
軟件工程師喜歡自欺欺人。也許你以前聽(tīng)過(guò)，什么“不需要很長(zhǎng)時(shí)間”“請(qǐng)給我?guī)讉€(gè)小時(shí)”或“我可以在周末完成任務(wù)”，諸如此類(lèi)。優(yōu)秀的項(xiàng)目經(jīng)理會(huì)理解這一點(diǎn)，并將工程師的估算值乘以四（或四十……）。
使用微服務(wù)的決策也會(huì)有同樣的樂(lè)觀情緒。這項(xiàng)工作并不是"為所有人獲取 AWS 證書(shū)并移動(dòng)一些代碼"那么簡(jiǎn)單。實(shí)踐中會(huì)有大量意外開(kāi)銷(xiāo)。下面是你需要的一些人員和工具類(lèi)別：
- 架構(gòu)師。你需要一些人來(lái)繪制美觀且過(guò)于簡(jiǎn)化的圖表并做演示。
- 發(fā)布管理。現(xiàn)在，你需要協(xié)調(diào)各個(gè)部署并管理多個(gè) pipelines。這種協(xié)調(diào)工作將需要通用工具鏈，還要有團(tuán)隊(duì)來(lái)維護(hù)這一工具鏈。
- DevOps。“常規(guī)”工程師既沒(méi)有專業(yè)知識(shí)，也沒(méi)有意愿來(lái)正確配置他們的服務(wù)。他們也很難正確處理安全性問(wèn)題。
- 數(shù)據(jù)工程師。如果你很幸運(yùn)能夠按照這些建議來(lái)成功分解數(shù)據(jù)存儲(chǔ)，那么你現(xiàn)在需要一個(gè)團(tuán)隊(duì)來(lái)將這些數(shù)據(jù)提取到一個(gè)地方進(jìn)行分析。
- 配置文件。雖然一些額外的 YAML 文件聽(tīng)起來(lái)并不那么糟糕，但這里會(huì)出現(xiàn)最危險(xiǎn)的錯(cuò)誤。它們也難以測(cè)試和調(diào)試。
https://abcnews.go.com/Technology/wireStory/latest-twitter-Appears-back-outage-64276132
你不僅需要支付所有這些額外人員的薪酬，而且還指數(shù)級(jí)增加了工程組織中的溝通渠道數(shù)量。這會(huì)拖慢所有人的步伐。
7謊言七：如果你從頭開(kāi)始精心設(shè)計(jì)微服務(wù)，它們將會(huì)起作用
這里我引用一段文字：
正常運(yùn)作的復(fù)雜系統(tǒng)一定是從一個(gè)正常運(yùn)作的簡(jiǎn)單系統(tǒng)演變而來(lái)的。從頭開(kāi)始設(shè)計(jì)的復(fù)雜系統(tǒng)永遠(yuǎn)無(wú)法正常工作，也無(wú)法靠打補(bǔ)丁來(lái)正常運(yùn)作。你必須從一個(gè)簡(jiǎn)單系統(tǒng)起步。——Gall 定律
8總結(jié)
既然有這么多如此明顯的缺點(diǎn)，為什么微服務(wù)還這么受歡迎呢？
我相信大多數(shù)工程師（包括我本人）都有一定程度的自我能力否定傾向。很多時(shí)候，我們需要面對(duì)自身能力不足以應(yīng)付的狀況，卻依舊要跨過(guò)眼前的障礙。在這種情況下，依靠他人的成果和“最佳實(shí)踐”是更安全的。但是，我們很快就認(rèn)為這些“最佳實(shí)踐”是經(jīng)過(guò)深思熟慮的，或肯定適用于我們的問(wèn)題。當(dāng)你啟用更多服務(wù)時(shí)，云供應(yīng)商會(huì)受益。微服務(wù)倡導(dǎo)者在你購(gòu)買(mǎi)他們出的書(shū)時(shí)也會(huì)賺錢(qián)。他們倆都有動(dòng)力向你兜售你本來(lái)用不到的技術(shù)。
不管怎樣，我認(rèn)為在某些情況下微服務(wù)可能是正確的選擇。如果你是谷歌或 Facebook 那樣的企業(yè)，并且要應(yīng)對(duì)數(shù)十種產(chǎn)品上數(shù)以十億計(jì)的活躍用戶，那么單體架構(gòu)肯定是不夠的。如果你有大量可并行化的任務(wù)，那么只用單體也是不行的。
我的目的是要告訴大家，后端服務(wù)設(shè)計(jì)是非常重要的，沒(méi)有哪種選擇是銀彈。無(wú)論我們是在談?wù)撐⒎?wù)還是單體，SQL 還是 NoSQL，Python 還是 Node，本質(zhì)都一樣。任何技術(shù)都不可能完美適應(yīng)所有用例。
因此，你應(yīng)該認(rèn)真思考各種想法，質(zhì)疑所有假設(shè)并清醒地做出架構(gòu)決策。你的選擇可能會(huì)成就或拖垮你的公司。
作者 | Scott Rogowski
策劃 | 萬(wàn)佳
轉(zhuǎn)發(fā)鏈接：https://mp.weixin.qq.com/s/QtYw0xdC3KN2gNAqHubIOg
