什么是無服務(wù)器架構(gòu).doc

無服務(wù)器架構(gòu)是最近一個(gè)比較熱的話題。我們也看到有很多的書籍、開源框架和大量的產(chǎn)品在不斷涌現(xiàn)，在一些技術(shù)大會上也有專門的主題。6月17日，MikeRobers在MartinFowler的博客網(wǎng)站上發(fā)布了一篇題為“無服務(wù)器架構(gòu)”的文章，引起了業(yè)界的諸多關(guān)注。在該文章中，他認(rèn)為無服務(wù)器是后端即服務(wù)(BaaS)和函數(shù)即服務(wù)(FaaS)的結(jié)合，并以AWSLambda產(chǎn)品為例探討了FaaS的特點(diǎn)、什么不是無服務(wù)器及需要考慮的其他相關(guān)問題。他指出：就像很多軟件發(fā)展趨勢一樣，業(yè)界并沒有對“無服務(wù)器”有一個(gè)明確的說法，即使它真的表示以下兩個(gè)不同而又重疊的領(lǐng)域也不會對此有所幫助：無服務(wù)器先用來描述那些顯著或完全依賴于第三方應(yīng)用或服務(wù)（“在云端”）的應(yīng)用程序。這些應(yīng)用程序依賴于第三方來管理服務(wù)器端邏輯和狀態(tài)，它們都是典型“富客戶端”的應(yīng)用程序（你可以想象為單一頁面的Web應(yīng)用程序或移動(dòng)應(yīng)用），并采用云平臺提供的生態(tài)系統(tǒng)，包括可訪問的數(shù)據(jù)庫（如Parse、Firebase）、認(rèn)證服務(wù)（Auth0、AWSCognito）等。這些類型的服務(wù)以前被描述為“（移動(dòng)）后端即服務(wù)”。我在文中會用“BaaS”縮寫來代替這樣的服務(wù)。無服務(wù)器還表示那些有服務(wù)器端邏輯的應(yīng)用仍然需要由開發(fā)者來編寫。不同于傳統(tǒng)的架構(gòu)，它運(yùn)行在無狀態(tài)計(jì)算的容器中，這些容器由事件觸發(fā)的、是短暫的（也許僅僅只是一次調(diào)用）、并且完全由第三方管理。（感謝ThoughtWorks在他們最近的技術(shù)雷達(dá)的定義。）理解這個(gè)觀點(diǎn)的另一種方式是“函數(shù)即服務(wù)（FaaS）”，其中AWSLambda是目前最流行的FaaS實(shí)現(xiàn)之一。Mike主要分析了第二個(gè)領(lǐng)域，并用FaaS作為文中“無服務(wù)器”的代言詞。他認(rèn)為第二個(gè)領(lǐng)域相對較新，并且它和我們平常如何考慮技術(shù)架構(gòu)的方式有顯著的區(qū)別，也推動(dòng)了無服務(wù)概念周邊很多的炒作。他也提到了其實(shí)這些概念是相互關(guān)聯(lián)的，并在不斷合并。文中他給出了UI驅(qū)動(dòng)的應(yīng)用和消息驅(qū)動(dòng)的應(yīng)用兩個(gè)例子解釋了無服務(wù)架構(gòu)的設(shè)計(jì)以及不同。通過解讀AWSLamda產(chǎn)品描述，Mike在文中分享了他對于FaaS的幾個(gè)理解：從根本上說，F(xiàn)aaS是關(guān)于無需管理自己的服務(wù)器系統(tǒng)或者服務(wù)器應(yīng)用，就能夠運(yùn)行后端代碼的。FaaS不需要基于一個(gè)特定的框架或類庫進(jìn)行編碼。無服務(wù)器應(yīng)用程序的運(yùn)行部署與傳統(tǒng)系統(tǒng)非常不同-我們將代碼上傳到FaaS服務(wù)提供商，它會幫我們做所有其他事情。水平擴(kuò)展是完全自動(dòng)的、彈性的，并且由服務(wù)提供商進(jìn)行管理。FaaS中的函數(shù)是由服務(wù)提供商定義的事件類型觸發(fā)的。大多數(shù)服務(wù)提供商還允許函數(shù)被HTTP請求響應(yīng)觸發(fā)，通常在某種API網(wǎng)關(guān)里。他同時(shí)也探討了FaaS在狀態(tài)、執(zhí)行時(shí)長、啟動(dòng)延時(shí)、API網(wǎng)關(guān)、工具和開源等方面的表現(xiàn)。他提到了FaaS在本地狀態(tài)的顯著約束，并可以這樣簡單來理解：對于任何的函數(shù)調(diào)用，你所創(chuàng)建的進(jìn)程或者主機(jī)狀態(tài)不會有一個(gè)對隨后的調(diào)用可用，這包含了你寫到內(nèi)存和硬盤上的狀態(tài)。換句話說，從部署單元角度來看，F(xiàn)aaS的函數(shù)是無狀態(tài)的。這對應(yīng)用架構(gòu)產(chǎn)生了巨大的影響。這通常意味著FaaS要么是純粹無狀態(tài)的，即提供輸入的純函數(shù)轉(zhuǎn)換；要么是利用數(shù)據(jù)庫、跨應(yīng)用緩存（如Redis）或者網(wǎng)絡(luò)文件存儲（如S3）的方式來存儲跨請求的狀態(tài)或處理請求需要的進(jìn)一步輸入。而對于執(zhí)行時(shí)間而言，F(xiàn)aaS函數(shù)的每次調(diào)用是有時(shí)間限制的。當(dāng)前AWSLamda函數(shù)不允許超過5分鐘，超過就會被中斷。這意味著長任務(wù)并不適合FaaS，除非重新設(shè)計(jì)架構(gòu)。另外，F(xiàn)aaS函數(shù)的響應(yīng)時(shí)長取決于很多的因素，也許會從10毫秒到2分鐘。Mike認(rèn)為如果你編寫一個(gè)低延遲交易應(yīng)用，那么不管你使用什么語言實(shí)現(xiàn)，可能都無法使用FaaS系統(tǒng)。那么Paas是無服務(wù)器嗎？在文中Mike引用了AdrianCockcroft的回答如果您的PaaS能夠高效地在20分鐘內(nèi)啟動(dòng)運(yùn)行半秒的實(shí)例，那么你可以稱它為無服務(wù)器。Mike認(rèn)為：絕大多數(shù)PaaS應(yīng)用并不是著眼于將整個(gè)應(yīng)用的每個(gè)請求都來回切換，而FaaS平臺做的正是這一點(diǎn)。FaaS和PaaS之間的主要操作差異在于擴(kuò)展。對于大多數(shù)的PaaS來說，你仍然需要考慮規(guī)模，例如在Heroku你想運(yùn)行多少Dynos。而如果是FaaS的應(yīng)用，這完全是透明的。即使你將你的PaaS應(yīng)用程序設(shè)置為自動(dòng)擴(kuò)展，你也不會對單個(gè)請求進(jìn)行同樣的配置（除非你有一個(gè)非常特殊的流量描述文件），所以當(dāng)涉及到成本的時(shí)候，F(xiàn)aaS應(yīng)用會更高效。同時(shí)他也指出這并不意味著沒有運(yùn)維。這里要考慮兩個(gè)重要的事情：首先，“運(yùn)維”不僅僅意味著服務(wù)器管理。它也意味著監(jiān)控、部署、安全、網(wǎng)絡(luò)，也意味著一定的產(chǎn)品問題診斷和系統(tǒng)規(guī)模擴(kuò)展。這些問題在無服務(wù)器應(yīng)用中仍然存在，你依舊需要應(yīng)對的策略。其次，即使仍然發(fā)生系統(tǒng)管理的工作，你也僅僅是將它們外包給無服務(wù)器平臺而已。最后Mike對存儲過程即服務(wù)的另一話題也進(jìn)行了探討，他認(rèn)為:這可能來自于一個(gè)事實(shí)，即FaaS函數(shù)的許多例子（包括一些我在本文中使用的）都是少量訪問數(shù)據(jù)庫的代碼。如果這就是我們可以使用FaaS的所有場景，那么我認(rèn)為這個(gè)名字是有幫助的。然而它實(shí)際上只是FaaS能力的一個(gè)子集。如果僅僅因?yàn)檫@個(gè)原因就形成這樣觀點(diǎn)的話，那這限制是不合理的。同