《如何選擇最合適的Serverless服務(wù)？》要點(diǎn)：
本文介紹了如何選擇最合適的Serverless服務(wù)？，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

通過(guò)迅速靈活以及容量巨大的彈性伸縮,無(wú)服務(wù)器架構(gòu)能很好地解決關(guān)鍵功能的性能瓶頸,但它并不是完美的：不僅需要修改設(shè)計(jì)去適應(yīng)它,對(duì)熟悉的編程模型進(jìn)行調(diào)整,還要解決諸如規(guī)劃預(yù)算、安全等等問(wèn)題.但總的來(lái)說(shuō),它為云上的應(yīng)用提供了另一種選擇——并且具有難以抵擋的誘惑：極大地簡(jiǎn)化應(yīng)用從開發(fā)到部署和維護(hù)的整個(gè)過(guò)程.

將編寫代碼和部署應(yīng)用的整個(gè)過(guò)程簡(jiǎn)化是每個(gè)開發(fā)人員的夢(mèng)想,而無(wú)服務(wù)器架構(gòu)(Serverless)正是這樣的解決方案,在采用這種架構(gòu)的時(shí)候需要考慮它的局限,費(fèi)用問(wèn)題以及安全問(wèn)題.

信息技術(shù)在不同領(lǐng)域的發(fā)展不盡相同.誠(chéng)然,事實(shí)一直如此,因?yàn)槿藗優(yōu)楫?dāng)下的問(wèn)題所找到的可行的解決方案,通常先于這些問(wèn)題本身就已經(jīng)存在了.與虛擬化、云計(jì)算等技術(shù)的緩慢進(jìn)步相比,編程語(yǔ)言幾乎是原地踏步了十年.直到新一輪的編程語(yǔ)言和方法諸如Python,Ruby,Node,Swift的出現(xiàn)才打破這一局面.這兩個(gè)領(lǐng)域看似毫無(wú)關(guān)聯(lián),然而我們即將看到二者共同演變并結(jié)合在一起開花結(jié)果.

這個(gè)新的結(jié)合領(lǐng)域就是無(wú)服務(wù)器計(jì)算(Serverless).易于部署的容器實(shí)例集合、無(wú)處不在的基于REST API的外部服務(wù)、易于實(shí)現(xiàn)REST API的新編程語(yǔ)言使得以 REST API提供接口成為一種簡(jiǎn)單而可行的選擇.這些技術(shù)相互結(jié)合,創(chuàng)造了一種全新的計(jì)算形式. 我們已經(jīng)很熟悉這種新的編程形式的諸多方面(例如如何設(shè)計(jì)和實(shí)現(xiàn)REST API,如何設(shè)計(jì)實(shí)現(xiàn)微服務(wù)),但是仍有一些方面并不為人熟知.

從Node.js中學(xué)到的

但這個(gè)應(yīng)用提供的并不是REST API,它只是簡(jiǎn)單地根據(jù)不同的請(qǐng)求內(nèi)容響應(yīng)包含不同內(nèi)容的HTML頁(yè)面.結(jié)合REST之后,Node應(yīng)用便成為一個(gè)計(jì)算結(jié)點(diǎn).不變的是,當(dāng)收到請(qǐng)求時(shí),它便執(zhí)行邏輯,然后退出.同時(shí),作為基礎(chǔ)設(shè)施的部分,它會(huì)保持對(duì)特定端口的監(jiān)聽.

基礎(chǔ)設(shè)施

然而,為了實(shí)現(xiàn)一個(gè)簡(jiǎn)單但完整、可運(yùn)行的Node應(yīng)用(或者 Python / Djang / Java / Spring / RoR 等),還需要進(jìn)行網(wǎng)絡(luò)配置,防火墻配置,操作系統(tǒng)配置和調(diào)整,存儲(chǔ)配置,并且如果你使用了網(wǎng)絡(luò)應(yīng)用防火墻(WAF: Web Application Firewall),還需要配置WAF.盡管,DevOps能使所有這一切更容易一些,但請(qǐng)?jiān)囅胍幌?如果你根本不需要做這些額外的配置,那將會(huì)怎樣?

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

這對(duì)開發(fā)者無(wú)疑有著巨大的吸引力.編寫代碼后,無(wú)需進(jìn)行那些看似必須的配置(無(wú)論是物理環(huán)境,虛擬環(huán)境的還是云端環(huán)境)就能部署,是眾多開發(fā)者的夢(mèng)想.這也不禁讓人想起一些現(xiàn)實(shí)世界中的例子.首當(dāng)其沖的就是應(yīng)對(duì)高峰期的性能瓶頸.假設(shè)你有一個(gè)完美運(yùn)行的在線訂單系統(tǒng),在銷售高峰期(比如黑色星期五),由于驗(yàn)證收貨地址的時(shí)間過(guò)長(zhǎng),系統(tǒng)經(jīng)常陷入崩潰.

如果你有一個(gè)無(wú)服務(wù)器函數(shù)(serverless function),它僅返回輸入的地址是否有效,你就可以將地址驗(yàn)證交給它來(lái)處理,那該多好? 甚至,該功能還允許快速擴(kuò)展到幾乎無(wú)限容量(當(dāng)然,網(wǎng)絡(luò)帶寬還是要考慮的)! 現(xiàn)在,這個(gè)瓶頸不再是問(wèn)題,你只需要為這個(gè)函數(shù)實(shí)際使用的計(jì)算資源(CPU時(shí)間)付費(fèi). 這意味著調(diào)用得越多,支付的費(fèi)用就越高,但是在大部分的時(shí)間里,費(fèi)用都很少. 你只需要為真實(shí)使用的計(jì)算資源付費(fèi).

如果所有這一切以可接受的價(jià)格讓你在你的站點(diǎn)上或者云端完成,那該有多好!已經(jīng)誕生了這樣的產(chǎn)品(Microsoft Functions,AWS Lambda和nanoscale.io等)都提供了上述所有功能.

并非雨后彩虹

1. 工具支持.它必須支持你的開發(fā)工具,特別是對(duì)CI / CD / ARA的支持至關(guān)重要.如果無(wú)法將無(wú)服務(wù)器計(jì)算集成到你現(xiàn)有的開發(fā)環(huán)境和以及整個(gè)流程中,那么說(shuō)明它還不夠好.
2. 計(jì)費(fèi)和收費(fèi)方式.永遠(yuǎn)不要忘記這些服務(wù)提供商與你的商業(yè)一樣,目標(biāo)也是賺錢.請(qǐng)確保你明白他們賺到的錢是從你的預(yù)算中支出的.所有按需使用的資源都有一些附加因素,因?yàn)樗蕾囉诓豢深A(yù)測(cè)的客戶群和他們變幻莫測(cè)的使用情況.但要了解你將被收取哪些費(fèi)用,以及供應(yīng)商保留了哪些更換計(jì)費(fèi)方式的權(quán)利.
3. 安全功能.將大量代碼從你的核心應(yīng)用中分離出來(lái),并將其放在云端,這可能需要在安全上大量投資并需要撰寫一些額外的代碼.確保你的供應(yīng)商能夠提供上述協(xié)助,抑或是允許你將你的代碼保留在防火墻和WAF之后.
4. 你的整體架構(gòu).雖然我們上面的例子很好地演示了“低垂的果實(shí)”(唾手可得的部分),但稍微復(fù)雜一些的案例就可能會(huì)遇到諸如數(shù)據(jù)訪問(wèn),數(shù)據(jù)安全,成本問(wèn)題乃至高可用性等問(wèn)題.確保你的團(tuán)隊(duì)已經(jīng)深入研究了怎樣實(shí)現(xiàn)無(wú)服務(wù)器計(jì)算架構(gòu),并能很好地掌握這種編程模型.

構(gòu)建正確的應(yīng)用

將來(lái),一些應(yīng)用程序?qū)⑼耆捎脽o(wú)服務(wù)器架構(gòu),特別是對(duì)于相比使用云端實(shí)例更具成本優(yōu)勢(shì)的應(yīng)用.即便沒(méi)有這樣的應(yīng)用,盡可能少地在基礎(chǔ)設(shè)施上配置資源也會(huì)變得更加劃算.同時(shí),將無(wú)服務(wù)器計(jì)算作為解決各種相對(duì)獨(dú)立的功能引起的性能瓶頸的解決方案,或者用于測(cè)試在不需要增加基礎(chǔ)設(shè)施預(yù)算的情況下,是否可以增加應(yīng)用的容量.總的來(lái)說(shuō),在信息技術(shù)領(lǐng)域,對(duì)于如何正確地選擇架構(gòu)來(lái)實(shí)現(xiàn)業(yè)務(wù)目標(biāo),無(wú)服務(wù)器架構(gòu)無(wú)疑是其中一種解決之道.

相關(guān)文章：

• 《這不是我想要的Serverless》
• 《無(wú)服務(wù)器技術(shù)常見(jiàn)的五大誤解》

作者介紹：胡應(yīng)明,趨勢(shì)科技資深工程師,DockOne社區(qū)譯者

文章來(lái)自微信公眾號(hào)：Docker

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/3739.html