無狀態(tài)和事件驅(qū)動

　　無服務(wù)器計算有兩個顯著特征，既有強大的吸引力，又面臨著更廣泛采用的障礙。

　　首先，無服務(wù)器功能是無狀態(tài)的，這意味著沒有用于交互的上下文。它們不存儲歷史記錄，因此僅使用隨附的信息處理每個請求?！懊看味枷褚粔K白板，但非常高效，因為你不需要應(yīng)對重重的復雜應(yīng)用邏輯，” Wikibon分析師James Kobielus說。

　　另一個顯著特征是無服務(wù)器是事件驅(qū)動的，意味著會對用戶或程序生成的動作做出響應(yīng)，事件可能包括查詢明尼阿波利斯當前溫度的請求、搜索引擎查詢或數(shù)據(jù)庫記錄更新。

　　事件驅(qū)動的應(yīng)用是非常高效的，因為在不使用的時候不會消耗資源。這種應(yīng)用編程簡單，易于擴展。“你可以設(shè)置應(yīng)用，這樣如果有事件進來，那么功能運行起來。如果有一百萬個時間進來，你就可以應(yīng)對一百萬個，”Lowery說。但是，并非每個應(yīng)用都可以被提煉為一系列無狀態(tài)事件。

　　綜合起來，這些讓無服務(wù)器計算成為某些請求的理想平臺，例如查看美國明尼阿波利斯的熱或冷。然而，對于其他例如管理購物車或制作賬單來說，并不是那么好用。

　　Kobelius說：“有人點擊‘購買’，整套數(shù)據(jù)庫和運行時功能做定價，最終確定訂單，并發(fā)送確認。所有必須以嚴格的方式發(fā)生，帶有狀態(tài)和事務(wù)流”，這使得它無法與無服務(wù)器執(zhí)行相匹配。

　　目前尚不清楚是否會有新的工具和擴展程序讓無服務(wù)器技術(shù)在更為傳統(tǒng)的應(yīng)用中變得可行。無狀態(tài)應(yīng)用可以擴展或改進以展示有狀態(tài)的行為，就像容器一樣，輕量級虛擬機可以抽象消除底層基礎(chǔ)架構(gòu)的差異。容器也是無狀態(tài)的，但商業(yè)和開源擴展讓容器可以用于上下文敏感的應(yīng)用中。

　　微軟的目標是消除功能即服務(wù)和平臺即服務(wù)之間的界限，讓開發(fā)人員能夠混合搭配各種不同的平臺。特別是，微軟強調(diào)所謂的“虛擬Kubelets”，這個在12月推出的技術(shù)能夠使容器運行各種功能或完整的應(yīng)用，但有了微計費和自動基礎(chǔ)設(shè)施配置，無服務(wù)器提供了很多企業(yè)客戶想要的靈活性。AWS在11月底推出了Fargate，可以在不管理服務(wù)器或服務(wù)器集群的情況下運行容器。

　　微軟Azure容器項目管理負責人Gabe Monroy在去年12月的KubeCon + CloudNativeCon北美會議上表示：“這實際是最好的無服務(wù)器，如果基礎(chǔ)設(shè)施消失，我們將在基礎(chǔ)設(shè)施領(lǐng)域開展工作?！?/p>

　　Wikibon的Kobielus甚至認為，區(qū)塊鏈這種去中心化的數(shù)字記賬技術(shù)對數(shù)據(jù)庫密集型場景中的無狀態(tài)來說是一種補充。他說：“你可以隨時回滾一個完整敘述，關(guān)于誰在什么樣的聯(lián)合框架中調(diào)用了什么?！?/p>

　　因此，無服務(wù)器的擁護者認為，這項技術(shù)有廣闊的前景，特別是對于那些有著“提升和轉(zhuǎn)變”心態(tài)的企業(yè)，他們試圖將舊應(yīng)用轉(zhuǎn)移到一種新模式上，并積極擁抱構(gòu)建和運行這些應(yīng)用的新方法。

　　例如就在幾年前，房利美(Fannie Mae)公司運行蒙特卡洛(Monte Carlo)模擬分析其抵押貸款組合的風險?，F(xiàn)在，他們正在運行所謂的第一個在金融行業(yè)中使用無服務(wù)器的高性能計算平臺。在大約2000萬抵押貸款的模擬中，該系統(tǒng)的工作速度比以前快了4倍多。

　　“我們認為沒有任何固有的技術(shù)限制可以阻止任何主要工作負載在Lambda上的使用，”AWS的Gilbert表示，他有趣地稱Fannie Mae將無服務(wù)器當做“云中的超級計算機”。他說：“無服務(wù)器將是最簡單、最簡單的，對許多客戶來說是主流計算的首選方式?！?/p>

　　開發(fā)者的愛

　　無服務(wù)器模型有一個優(yōu)點，不容易被提煉為投資回報指標：開發(fā)人員喜歡這項技術(shù)。無服務(wù)器架構(gòu)使他們擺脫了基礎(chǔ)架構(gòu)部署的負擔，他們只需要編寫代碼就行了。

　　Braze的Poliandro說“無服務(wù)器技術(shù)讓我們的應(yīng)用和運營工程師能夠以對他們更有意義的方式思考他們的責任。他們可以更快地部署，不必擔心周圍的基礎(chǔ)設(shè)施?！?/p>

　　但是，在無服務(wù)器平臺上構(gòu)建應(yīng)用，需要對開發(fā)人員如何考慮執(zhí)行任何的方式進行重大改變?！斑x擇Lambda意味著要為代碼進行重寫，”Ryland坦言。

　　無服務(wù)器架構(gòu)的粉絲說，這種局限性不在于技術(shù)，而在于開發(fā)集成應(yīng)用已有60年的歷史。 Gartner的Lowery說：“無服務(wù)器技術(shù)挑戰(zhàn)了軟件應(yīng)該如何開發(fā)的一些假設(shè)和已有的模式?？蛻艨吹狡渲杏泻芏鄡r值，但他們不得不學習一種全新的編程方式。”

　　針對無狀態(tài)、以事件驅(qū)動的環(huán)境進行開發(fā)，并不一定比開發(fā)單一程序更容易。無服務(wù)器架構(gòu)“將復雜性從應(yīng)用轉(zhuǎn)移到連接中，”Atchison說?！斑@不是萬能的解決方案，也有自身的問題，也要解決這些問題?！?/p>

　　微軟建議，開發(fā)人員要熟悉基于事件的異步模式的編程，并學習使用功能協(xié)調(diào)器(如Durable Functions編程模型和Logic Apps連接器)，創(chuàng)建長時間運行的操作和狀態(tài)管理。

　　但是倡導者們說，這些好處值得陡峭的學習曲線，所需要的不僅僅是更多工具，還有更具創(chuàng)造性的軟件開發(fā)方法。

　　“大多數(shù)應(yīng)用所做的，絕大多數(shù)都可以呈現(xiàn)為無服務(wù)器功能，”Kobielus說。容器有助于將功能封裝并作為服務(wù)提供給用戶，它們可以獨立擴展。”

　　傳統(tǒng)應(yīng)用仍然可以通過修改以利用某些無服務(wù)器功能。本質(zhì)上由事件驅(qū)動的各種功能是可以與主應(yīng)用分開封裝的。

　　例如，“隨時在數(shù)據(jù)庫或文件系統(tǒng)中創(chuàng)建數(shù)據(jù)，這是一個事件，”Lowery說?！斑@意味著你可以將其設(shè)置為獨立于主程序執(zhí)行其他操作。這樣做讓應(yīng)用生命周期更長，”因為應(yīng)用可以通過使用應(yīng)用程序編程接口進行擴展，或者掛接到其他應(yīng)用中。

　　企業(yè)組織可以調(diào)整各個組成部分以便受益于無服務(wù)器執(zhí)行，并分階段遷移，而不是從頭開始重寫現(xiàn)有應(yīng)用?！皩⑿碌膽?yīng)用功能作為微服務(wù)，將用戶界面組件從業(yè)務(wù)邏輯和數(shù)據(jù)訪問層拆分，并將現(xiàn)有的微服務(wù)轉(zhuǎn)換并拆分為無服務(wù)器功能，”Simform技術(shù)顧問Rohit Akiwatkar這樣說道，Simform是一家移動和物聯(lián)網(wǎng)服務(wù)公司，已經(jīng)圍繞服務(wù)器做了廣泛發(fā)布?！半S著時間的推移，功能的數(shù)量將會增加，開發(fā)團隊的敏捷性和速度將會提高?！?/p>

　　最佳時機

　　現(xiàn)在是CIO加入無服務(wù)器陣營的時候了嗎? Lowery認為是的?！拔腋嬖VCIO們，這項技術(shù)不會消失，這不是一種流行時尚。企業(yè)應(yīng)該開始讓員工熟悉這項技術(shù)?！?/p>

　　Simform的Akiwatkar建議采取三個步驟：了解使用無服務(wù)器架構(gòu)的最佳實踐;確定高ROI的應(yīng)用;在低風險環(huán)境中嘗試無服務(wù)器功能。

　　所有這些讓現(xiàn)在成為開發(fā)者采用無服務(wù)器技術(shù)的最佳時機。從容器、微服務(wù)到現(xiàn)在的無服務(wù)器計算，過去五年在應(yīng)用的構(gòu)建和部署方面引入的創(chuàng)新數(shù)量比過去20年的總和還多。

　　在一個極度缺乏人才的經(jīng)濟體中，對下一個重要事件保持謙遜可能是吸引最優(yōu)秀人才的唯一途徑。 “你必須有一個長期采用這項技術(shù)的計劃，否則你將無法獲得所需的人才。開發(fā)人員會對這項技術(shù)充滿期待，”Lowery說。

　　對于那些仍在努力應(yīng)對如DevOps等無窮無盡創(chuàng)新(例如云、容器和微服務(wù))的組織來說，無服務(wù)器計算似乎又是一個令人頭痛的問題。 但在這個所有公司都想成為軟件公司的商業(yè)世界中，沒有跟上這個最新趨勢可能會讓你犯下存在感減少的錯誤。