從你自己的Web應(yīng)用程序里面創(chuàng)建API不合邏輯或不切實(shí)際時(shí)，有三種主要的方法可以創(chuàng)建API。你可以使用虛擬機(jī)(比如AWS EC2實(shí)例)構(gòu)建服務(wù)，使用你的服務(wù)構(gòu)建容器，或者在無服務(wù)器環(huán)境中構(gòu)建。

下面解釋了為什么在構(gòu)建API時(shí)采用無服務(wù)器最有意義。

別使用容器來構(gòu)建API

容器是近年來最令人迷惑的時(shí)尚。在某些情況下，“我們可以構(gòu)建是你之前構(gòu)建的機(jī)器的完美復(fù)制品的新機(jī)器”有莫大的吸引力，還充分發(fā)掘一些關(guān)鍵流程，但公共API很少一開始就需要啟動(dòng)幾十個(gè)復(fù)制品，這個(gè)優(yōu)勢(shì)無法壓倒諸多困難。

與虛擬機(jī)相比，容器啟動(dòng)速度更快，只需較少的資源即可多路運(yùn)行，但這兩個(gè)優(yōu)點(diǎn)沒一個(gè)適用于API服務(wù)。通常，容器啟動(dòng)速度不夠快，等到收到API請(qǐng)求才開始。與傳統(tǒng)虛擬機(jī)相比，我們的開銷較低，這里就引出了一個(gè)基本的開發(fā)事實(shí)：沒有哪個(gè)高管抱怨買不到更多的內(nèi)存，但他們?nèi)鄙?a target="_blank">工程師。如果非常稀缺的是內(nèi)存或CPU周期，沒人會(huì)寫一行Javascript。大多數(shù)廣泛采用的技術(shù)主要是為了節(jié)省開發(fā)人員的時(shí)間。

容器以犧牲開發(fā)時(shí)間來節(jié)省內(nèi)存，這方面的一個(gè)例子是缺乏可靠的管理工具。這是一則軼聞，但我從未在Amazon EC2或Azure VM的虛擬機(jī)管理程序界面方面遇到過問題。另一方面，我從未成為(或甚至遇到過)管理Docker容器方面自學(xué)成才的專家。

面對(duì)大多數(shù)Web開發(fā)人員面臨容器時(shí)遇到的一些基本困難時(shí)，答案常常是“稍加培訓(xùn)，就能輕松地管理這個(gè)或那個(gè)”，這引出了容器方面的一個(gè)根本問題：接觸了多年的Web開發(fā)人員仍然無法獨(dú)自解決問題。一般來說，領(lǐng)導(dǎo)者談?wù)撃男┵Y源供不應(yīng)求時(shí)，往往是“人時(shí)不足”，而不是技術(shù)性問題。需要更多工程師時(shí)間的解決方案似乎注定帶來更多的麻煩。

別使用虛擬機(jī)來構(gòu)建API

雖然我反對(duì)容器的理由有一大堆，但反對(duì)虛擬機(jī)的理由歸結(jié)為一個(gè)詞：安全。確實(shí)，虛擬機(jī)方面的噩夢(mèng)場景就是類似公共API的服務(wù)。設(shè)想一下這個(gè)場景：

你的團(tuán)隊(duì)被要求構(gòu)建公共API，幫助與并行服務(wù)建立起潛在的合作關(guān)系。

經(jīng)過數(shù)月或數(shù)年的開發(fā)后，社區(qū)對(duì)端點(diǎn)的興趣不溫不火，公司的所有開發(fā)人員將注意力轉(zhuǎn)到別處。

在此期間，我們所用虛擬機(jī)的操作系統(tǒng)出現(xiàn)了新的漏洞，但由于構(gòu)建公共API不是任何人的“全職工作”，操作系統(tǒng)沒有相應(yīng)的更新，或者如果虛擬機(jī)管理程序服務(wù)迫使更新，但要是沒有人搞清楚為什么更新搞砸了服務(wù)，就得讓更新回滾或恢復(fù)。

過了一兩年后，你收到了一黑客發(fā)來的郵件，解釋了他們?nèi)绾瓮ㄟ^早就有補(bǔ)丁的安全漏洞、卻從未給你API的虛擬機(jī)打上補(bǔ)丁，完全克隆你的生產(chǎn)服務(wù)器。

問題很明顯，但解決方案并不是很清晰：嚴(yán)加管理的虛擬機(jī)讓我們獲得了酷似無服務(wù)器的東西，試圖將服務(wù)遷移到更現(xiàn)代的機(jī)器映像可能要占用開發(fā)人員的大量時(shí)間。更糟糕的是，很難知道這種情況何時(shí)發(fā)生，于是你的環(huán)境中有幾個(gè)確實(shí)很古老的虛擬機(jī)。

為什么無服務(wù)器是贏家?

無服務(wù)器的風(fēng)頭“蓋過”容器趨勢(shì)。許多新開發(fā)人員接受了在像Heroku這樣高度抽象的環(huán)境中管理虛擬機(jī)這方面最基本的課程之后，正在學(xué)習(xí)無服務(wù)器。

無服務(wù)器提供了這樣一個(gè)環(huán)境：更新和安全漏洞“不是你的問題”，你可以針對(duì)已可靠地工作了一段時(shí)間的服務(wù)，采取“如果它沒有壞，別去修它”的態(tài)度。

最后，使用單個(gè)函數(shù)(在AWS中它們是Lambdas)來處理單個(gè)路由意味著通過API泄漏數(shù)據(jù)的危險(xiǎn)將大大降低。無服務(wù)器可能無法提供出色的資源使用、定價(jià)或易復(fù)制性，但這些都不是關(guān)鍵的阻礙因素，尤其是在構(gòu)建公共API時(shí)。在Stackery，我們專門旨在解決許多這些問題，使開發(fā)人員更容易讓無服務(wù)器應(yīng)用程序快速啟動(dòng)和運(yùn)行起來。

針對(duì)內(nèi)部服務(wù)、任務(wù)關(guān)鍵型項(xiàng)目和分布式系統(tǒng)，可以為幾乎任何現(xiàn)存的技術(shù)找出理由。以構(gòu)建API為例，很難為除了無服務(wù)器外的任何解決方案找到充分的理由。