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

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

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

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

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

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

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

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

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

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

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

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

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

并非雨后彩虹

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

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

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

相關(guān)文章：

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

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

文章來自微信公眾號：Docker

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