作者|劉尚奇

(資料圖)

最近一則IT行業(yè)的新聞引起了廣泛傳播，標(biāo)題非常引人注目：“從微服務(wù)轉(zhuǎn)為單體架構(gòu)，成本降低 90%”。

新聞報(bào)道了亞馬遜Prime Video團(tuán)隊(duì)的案例，他們通過(guò)將一個(gè)監(jiān)控系統(tǒng)從基于AWS Lambda的無(wú)服務(wù)器架構(gòu)遷移到傳統(tǒng)的單體架構(gòu)，大幅度降低了基礎(chǔ)設(shè)施成本。

圖片來(lái)源網(wǎng)絡(luò)

這則新聞引起轟動(dòng)的原因可能有幾個(gè)方面。首先，"90%成本降低"在當(dāng)前注重成本效益的時(shí)代引起了許多行業(yè)的共鳴。在宏觀經(jīng)濟(jì)不確定性的背景下，許多IT組織已將工作重心從技術(shù)創(chuàng)新轉(zhuǎn)向了降低運(yùn)營(yíng)成本。

其次，該案例講述了從AWS Lambda架構(gòu)遷移出去的過(guò)程。要知道，AWS最初推出Lambda和無(wú)服務(wù)器架構(gòu)時(shí)，強(qiáng)調(diào)的賣點(diǎn)就是降低計(jì)算成本，然而在這個(gè)案例中，Lambda的成本竟然不如更簡(jiǎn)單的單體架構(gòu)。最具諷刺意味的是，這個(gè)案例是由亞馬遜自己的Prime Video團(tuán)隊(duì)發(fā)布的，宛如大水沖了龍王廟。

云計(jì)算領(lǐng)域的先驅(qū)，37signals的CTO DHH也發(fā)表文章嘲笑，連亞馬遜自己都不知道如何正確地使用無(wú)服務(wù)器架構(gòu)和微服務(wù)。

圖片來(lái)源網(wǎng)絡(luò)

關(guān)于AWS Lambda和無(wú)服務(wù)器架構(gòu)，Thoughtworks技術(shù)雷達(dá)早在2015年就開(kāi)始追蹤和評(píng)估其發(fā)展，到2016年將其評(píng)級(jí)從評(píng)估提升為試驗(yàn)，然而直到2017年后，該評(píng)級(jí)一直未能提升到采納環(huán)。也就是說(shuō)，我們認(rèn)為AWS Lambda和無(wú)服務(wù)器架構(gòu)已具備生產(chǎn)級(jí)別的經(jīng)驗(yàn)，但尚未成熟到默認(rèn)使用的程度。

AWS Lambda的潛力和困境

AWS Lambda最初的誕生具備了巨大的潛力和顛覆性。在此之前，云服務(wù)提供的計(jì)算抽象仍然是粗粒度的IaaS和PaaS服務(wù)。AWS Lambda允許開(kāi)發(fā)者將函數(shù)級(jí)別的計(jì)算單元部署和托管在云平臺(tái)上。這極大地降低了計(jì)算資源的粒度，增加了計(jì)算的彈性。

AWS Lambda提供的降本增效價(jià)值主張也非常合理：傳統(tǒng)的云計(jì)算服務(wù)需要按照整個(gè)應(yīng)用級(jí)別進(jìn)行部署和托管，占用更多的資源，而最低計(jì)費(fèi)單位通常是按天計(jì)費(fèi)。而AWS Lambda的計(jì)費(fèi)則根據(jù)函數(shù)調(diào)用的次數(shù)和執(zhí)行時(shí)間進(jìn)行計(jì)費(fèi)，沒(méi)有最低計(jì)費(fèi)時(shí)間的限制。也就是說(shuō)，如果你的代碼只執(zhí)行了100毫秒，那么只按照100毫秒進(jìn)行計(jì)費(fèi)，實(shí)現(xiàn)真正的按需收費(fèi)。

這項(xiàng)技術(shù)看起來(lái)確實(shí)是一項(xiàng)具有跨時(shí)代意義的云計(jì)算技術(shù)。首先，相較于傳統(tǒng)的IaaS和PaaS，它更為簡(jiǎn)單，程序員無(wú)需進(jìn)行云服務(wù)器的配置和管理，只需編寫(xiě)和部署代碼即可。

其次，由于計(jì)算的顆粒度在函數(shù)級(jí)別，使得Lambda的云服務(wù)更具彈性，當(dāng)流量增加時(shí)，無(wú)需擴(kuò)容整個(gè)應(yīng)用，只需對(duì)高頻調(diào)用的函數(shù)進(jìn)行自動(dòng)擴(kuò)容。最后，按需使用理論上更為成本有效。盡管技術(shù)人員清楚，與普通應(yīng)用進(jìn)程內(nèi)的函數(shù)調(diào)用相比，AWS Lambda的函數(shù)調(diào)用開(kāi)銷更大，但這是局部?jī)?yōu)化與全局優(yōu)化的對(duì)比，如果能實(shí)現(xiàn)全局層面的函數(shù)調(diào)用按需計(jì)費(fèi)，理論上可以實(shí)現(xiàn)整體成本的降低。

然而，如果這項(xiàng)技術(shù)真的如此理想，就不會(huì)出現(xiàn)前文提到的新聞了。我們必須承認(rèn)，AWS Lambda和無(wú)服務(wù)器架構(gòu)在實(shí)踐中面臨許多問(wèn)題。

對(duì)于只包含幾個(gè)Lambda函數(shù)和幾十行代碼的無(wú)服務(wù)器應(yīng)用來(lái)說(shuō)，當(dāng)然非常簡(jiǎn)單。然而，遺憾的是這種簡(jiǎn)單的應(yīng)用通常只存在于演示中。大多數(shù)現(xiàn)代應(yīng)用更加復(fù)雜，這帶來(lái)了許多挑戰(zhàn)。首先是代碼管理。在傳統(tǒng)的大型軟件架構(gòu)中，我們有成熟的實(shí)踐來(lái)管理代碼的依賴和復(fù)用，例如通過(guò)架構(gòu)分層、提取共享庫(kù)等。在應(yīng)用進(jìn)程內(nèi)部調(diào)試代碼相對(duì)簡(jiǎn)單，但一旦涉及跨進(jìn)程的Lambda調(diào)用，追蹤和調(diào)試就變得更加困難。

其次是可擴(kuò)展性。AWS Lambda提供了理論上的函數(shù)級(jí)計(jì)算資源彈性。然而，當(dāng)應(yīng)用變得復(fù)雜時(shí)，挑戰(zhàn)就超出了人類架構(gòu)設(shè)計(jì)的能力。特別是在工作流程編排變得過(guò)于復(fù)雜時(shí)，很容易觸發(fā)著名的Lambda彈球反模式（Lambda Pinball）。Lambda Pinball是Thoughtworks技術(shù)雷達(dá)在2019年提出的一個(gè)反模式，指的是那些編排混亂的Lambda函數(shù)，請(qǐng)求在函數(shù)之間像彈球一樣來(lái)回跳動(dòng)。這種反模式很容易引發(fā)意想不到的副作用、服務(wù)之間的競(jìng)爭(zhēng)條件，并給系統(tǒng)增加更多負(fù)載。

更重要的是，當(dāng)你的復(fù)雜性帶來(lái)更多的性能負(fù)載，很多Lambda看起來(lái)在執(zhí)行，實(shí)際卻沒(méi)有運(yùn)行，這個(gè)時(shí)候成本會(huì)指數(shù)級(jí)爆炸。Lambda函數(shù)曾經(jīng)的最長(zhǎng)執(zhí)行時(shí)間是5分鐘，執(zhí)行超時(shí)就會(huì)被銷毀，如今這個(gè)時(shí)間已經(jīng)被提升到了15分鐘。這給程序員帶來(lái)更多便利的同時(shí)，也降低了對(duì)資源浪費(fèi)的警惕性。最后你會(huì)發(fā)現(xiàn)，看起來(lái)美好的無(wú)服務(wù)器架構(gòu)，最后總體成本反而比傳統(tǒng)應(yīng)用大很多。

微服務(wù)架構(gòu)和無(wú)服務(wù)器架構(gòu)

我說(shuō)這個(gè)新聞是標(biāo)題黨，因?yàn)锳WS Lambda Serverless架構(gòu)和微服務(wù)架構(gòu)在顆粒度上還是有比較大的區(qū)別的。2015年我還在行業(yè)里做微服務(wù)架構(gòu)咨詢的時(shí)候就經(jīng)常有爭(zhēng)論，微服務(wù)應(yīng)該有多微? 我發(fā)現(xiàn)很多人會(huì)把微服務(wù)顆粒度想象的過(guò)于小，百十行代碼就當(dāng)成一個(gè)微服務(wù)，而當(dāng)初的基礎(chǔ)設(shè)施成熟度是無(wú)法承擔(dān)這個(gè)開(kāi)銷的。所以我不得不在客戶那里一遍遍普及，微服務(wù)首先是足夠大的，但這個(gè)大的邊界不應(yīng)該超出兩個(gè)披薩大的團(tuán)隊(duì)(即團(tuán)隊(duì)成員規(guī)模在兩個(gè)披薩的飯量，后來(lái)我們發(fā)現(xiàn)這叫認(rèn)知負(fù)載)，也不應(yīng)該影響特性層面的獨(dú)立發(fā)布和資源彈性。

后來(lái)Gartner針對(duì)microservice又提了一個(gè)概念叫nanoservice，針對(duì)的就是這種百十行代碼級(jí)別的服務(wù)。這種nanoservice顆粒度按當(dāng)時(shí)的基礎(chǔ)設(shè)施成熟度來(lái)說(shuō)是徹底的反模式，后來(lái)隨著AWS Lambda的普及成為了可能。

當(dāng)然，無(wú)論是微服務(wù)架構(gòu)還是無(wú)服務(wù)器架構(gòu)，在技術(shù)雷達(dá)上從來(lái)都沒(méi)進(jìn)過(guò)采納環(huán)。我們的CTO Rebecca 2018年的時(shí)候還發(fā)表過(guò)文章并接受采訪，為什么最早提出微服務(wù)架構(gòu)概念的Thoughtworks反而沒(méi)有把微服務(wù)列入技術(shù)雷達(dá)采納環(huán)，并且可能一直不會(huì)。

其實(shí)對(duì)于軟件架構(gòu)風(fēng)格我們可以按照物理的分布式和邏輯的模塊化兩個(gè)維度來(lái)去看待。一直以來(lái)被架構(gòu)師們批斗的對(duì)象，被微服務(wù)架構(gòu)和無(wú)服務(wù)武器架構(gòu)們革命的對(duì)象，正是大泥球架構(gòu)，物理和邏輯的耦合都非常重。

而我們剛才提到的Lambda pinball反模式，其實(shí)落入了分布式單體?？雌饋?lái)物理進(jìn)程已經(jīng)拆分成分布式了，但邏輯上還是高度耦合的。某種程度上分布式單體甚至比大泥球架構(gòu)更加糟糕，因?yàn)槟愠惺苤植际綉?yīng)用的額外開(kāi)銷，卻因?yàn)檫壿嫑](méi)解耦沒(méi)有享受到分布式應(yīng)用的好處。

前面新聞里的亞馬遜Prime Video團(tuán)隊(duì)，以及吵著要下公有云的37 signlas，則走向了模塊化單體。當(dāng)應(yīng)用的復(fù)雜度和規(guī)模沒(méi)有到很大的時(shí)候，其實(shí)通過(guò)模塊化單體就能大幅提高靈活度和可擴(kuò)展性，并不一定需要走分布式的路線。甚至對(duì)一些性能敏感類場(chǎng)景，也只適合在單體應(yīng)用進(jìn)程內(nèi)調(diào)用。

最后，一組抽象良好、邊界清晰、顆粒度合適的微服務(wù)，其實(shí)是非?？简?yàn)架構(gòu)師的經(jīng)驗(yàn)和功力的。雖然現(xiàn)在微服務(wù)架構(gòu)已經(jīng)幾乎成為互聯(lián)網(wǎng)架構(gòu)的默認(rèn)風(fēng)格，但門檻其實(shí)沒(méi)有很多人想得這么低。

無(wú)服務(wù)器架構(gòu)風(fēng)格的實(shí)踐建議

那么針對(duì)AWS Lambda和無(wú)服務(wù)器架構(gòu)風(fēng)格有什么實(shí)踐建議嗎? 我這里總結(jié)了幾條：

首先是盡量使用無(wú)狀態(tài)函數(shù)

從設(shè)計(jì)的角度看，無(wú)狀態(tài)函數(shù)更容易推理和理解，從計(jì)算資源的角度看，無(wú)狀態(tài)函數(shù)可以實(shí)現(xiàn)執(zhí)行完即釋放。在無(wú)服務(wù)器架構(gòu)里，我們應(yīng)該盡可能使用函數(shù)式變成風(fēng)格，將Lambda設(shè)計(jì)為可以獨(dú)立和異步執(zhí)行的簡(jiǎn)單和無(wú)狀態(tài)任務(wù)。

其次是盡量使用事件驅(qū)動(dòng)

在主動(dòng)調(diào)用編排，和響應(yīng)式的事件驅(qū)動(dòng)風(fēng)格之間，我們總是更推薦你使用事件驅(qū)動(dòng)的通信風(fēng)格。這樣也可以降低架構(gòu)的復(fù)雜性，避免出現(xiàn)Lambda pinball。

然后是分層與解耦

即使使用Lambda和無(wú)服務(wù)器架構(gòu)，你也是可以考慮適當(dāng)進(jìn)行邏輯上的架構(gòu)分層，盡可能把代碼以類庫(kù)或外部服務(wù)的方式進(jìn)行封裝復(fù)用。

AWS Lambda跟其他云服務(wù)相比，我們建議更加小心優(yōu)化配置。選擇正確的內(nèi)存大小、運(yùn)行時(shí)間和配置選項(xiàng)都可以幫助優(yōu)化函數(shù)性能和冷啟動(dòng)時(shí)間，達(dá)到最終節(jié)省成本。

再就是對(duì)分布式系統(tǒng)常見(jiàn)的幾個(gè)建議

為失敗設(shè)計(jì)，為你的AWS Lambda功能失敗和異常實(shí)施適當(dāng)?shù)腻e(cuò)誤處理和重試邏輯。

度量與監(jiān)控, 用日志記錄、跟蹤和度量工具來(lái)監(jiān)控和調(diào)試Lambda功能和性能。

以及自動(dòng)化一切，盡可能用使用支持無(wú)服務(wù)器開(kāi)發(fā)工作流程的自動(dòng)化工具和框架測(cè)試和部署功能，減少手工干預(yù)錯(cuò)誤。

最后還是回到軟件開(kāi)發(fā)行業(yè)的那句老話，沒(méi)有銀彈。無(wú)服務(wù)器函數(shù)并不是解決所有問(wèn)題的靈丹妙藥。在采用它們之前需要考慮它們的局限性和權(quán)衡取舍。

為了避免 Lambda 陷阱，Thoughtworks 建議重新考慮無(wú)服務(wù)器方法對(duì)手頭問(wèn)題的適用性。我們建議，無(wú)服務(wù)器功能最適合簡(jiǎn)單、無(wú)狀態(tài)和短期任務(wù)，這些任務(wù)可以從云的可擴(kuò)展性和成本效益中受益。對(duì)于需要狀態(tài)管理、數(shù)據(jù)一致性或事務(wù)完整性的更復(fù)雜或長(zhǎng)時(shí)間運(yùn)行的任務(wù)，我們建議使用其他架構(gòu)或技術(shù)。

最終，這是一個(gè)架構(gòu)選擇問(wèn)題，而你也需要為自己的選擇買單。

關(guān)鍵詞：