?譯者 | 胥磊

審校 | 孫淑娟

在本系列的第一篇文章中，我們探討了??為什么堅信Serverless是云計算的未來??，期間我們研究了云計算的演變，也列舉了當(dāng)前已經(jīng)轉(zhuǎn)向Serverless模式的一些用例。在本文中，我們將進(jìn)一步闡述如何實現(xiàn)Serverless以及實現(xiàn)過程中將會遇到的挑戰(zhàn)。最后將通過論點總結(jié)和愿景展望來結(jié)束這個系列。

挑戰(zhàn)

 轉(zhuǎn)向一個更純粹的Serverless的世界將能解決現(xiàn)代工作負(fù)載運行時遇到的許多問題，但同時也存在很多挑戰(zhàn)。本文中，我們將這些挑戰(zhàn)分為四大類：云優(yōu)化、服務(wù)設(shè)計、功能和工作流以及安全問題，分別展開來進(jìn)行探討。在每個大類中我們都列出了重要的，有待徹底解決的具體問題。雖然不是很全面，但我們堅信這些將成為Serverless社區(qū)規(guī)劃線路的基石。

挑戰(zhàn)摘要

云計算優(yōu)化

Serverless適合為服務(wù)需求分配計算資源，它在服務(wù)需求增長時分配新的計算資源，而在需求減少時釋放相關(guān)計算資源。這里的分配和釋放計算資源的開銷問題可能是Serverless應(yīng)用部署后出現(xiàn)的最重要的問題之一。

Serverless服務(wù)（無論函數(shù)，容器或者是工作流運行的容器組）都會產(chǎn)生計算資源的縮減和回升的成本，而且這種成本的量可能相當(dāng)可觀，因為其貫徹了Serverless服務(wù)的生命周期的各個環(huán)節(jié)。包括Kubernetes在內(nèi)的大多數(shù)云技術(shù)在設(shè)計時都考慮了服務(wù)資源的預(yù)配置。在Serverless模式下，就必須要考慮通過降低運行中實例的變化而產(chǎn)生的開銷來優(yōu)化更多的動態(tài)用例。例如，Kubernetes添加一個Pod副本就必須進(jìn)行優(yōu)化，通過最大限度的減少開銷，以便于每次服務(wù)需求變化時成本和能源消耗降到最低。

另一方面需要注意的是，應(yīng)對需求增長，在增加計算資源過程中所帶來的服務(wù)延遲。當(dāng)你等待額外的資源被分配時，期間就會導(dǎo)致服務(wù)延遲的增加。極端情況下，當(dāng)一個請求到達(dá)一個還沒有分配資源的服務(wù)時，冷啟動的時間會導(dǎo)致該請求受到非常顯著的影響。正如在??Knative減少冷啟動時間??所討論的那樣，最壞的情況下服務(wù)啟動時間是以秒為單位，而請求的響應(yīng)時間通常則只有幾十毫秒。當(dāng)你創(chuàng)建由多個獨立擴(kuò)展組成的Serverless解決方案時，冷啟動帶來的影響是非常顯著的，必須考慮到這一點。進(jìn)一步改善這個問題就需要對云技術(shù)進(jìn)行更多優(yōu)化。

最后需要對KUbernetes和Knative進(jìn)行優(yōu)化，以充分發(fā)掘其解決能源和資金節(jié)約的潛力。Pod分配和集群控制應(yīng)發(fā)展到支持動態(tài)調(diào)整（碎片整理）到其他工作節(jié)點的子集，這樣空閑的節(jié)點就可以暫停，當(dāng)然當(dāng)集群資源總體需求增加時還可以恢復(fù)。

服務(wù)設(shè)計

當(dāng)你創(chuàng)建Serverless應(yīng)用或解決方案時，主要挑戰(zhàn)之一就是要以事件驅(qū)動的思維模式來設(shè)計應(yīng)用和服務(wù)，也就是要去了解應(yīng)用和整體方案各部分運行的事件。這些事件來自你對應(yīng)用領(lǐng)域的業(yè)務(wù)理解，必須被明確的提取出來。例如在一個業(yè)務(wù)流程的應(yīng)用中，如：假期預(yù)定系統(tǒng)，就有明確的事件來驅(qū)動整個應(yīng)用的使用。當(dāng)客戶計劃一個假期時，他們必須依次選擇和預(yù)定一系列的選項，如地點、航班、酒店、租車、餐飲以及其他活動。整個的過程可以被分解為服務(wù)以及它們之間流轉(zhuǎn)的事件，企業(yè)將其應(yīng)用設(shè)計成微服務(wù)，這種分解和設(shè)計也是眾所周知的。

Serverless的事件驅(qū)動架構(gòu)只是簡單的對不同的服務(wù)增加了事件（內(nèi)部或外部）觸發(fā)，如果它們沒有處理任何請求時，可以縮減到零。為了充分發(fā)揮這種架構(gòu)的優(yōu)勢，必須將驅(qū)動服務(wù)的事件外部化，這樣就可以用這些事件來觸發(fā)Serverless組件網(wǎng)中的工作流。由于服務(wù)都是可以動態(tài)擴(kuò)展的，就出現(xiàn)了之前提到的一個問題就是需要考慮冷啟動的潛在影響，同時還需要有一個顯示良好且響應(yīng)快速的用戶界面。

事件驅(qū)動架構(gòu)也有自己必須要解決的一系列挑戰(zhàn)，大部分可以通過選擇正確的事件代理、觸發(fā)器和事件模型來解決。而你應(yīng)用程序的部分也需要注意一些陷阱，特別是事件風(fēng)暴或一段時間后可能發(fā)生事件減少或不起作用的問題。以上所有這些就是我們所說的Serverless設(shè)計。

功能和工作流

AWS在2014年推出其Lambda服務(wù)時，介紹的第一個模型就是一個純粹的函數(shù)式編程模型。服務(wù)是以定義在不同語言和庫中的函數(shù)的形式執(zhí)行。后來Knative提出了一個更通用的模型：以容器為中心，像Lambda函數(shù)一樣，執(zhí)行是基于事件的觸發(fā)，并隨著服務(wù)的需求（請求）的變化增減資源規(guī)模。隨后，Knative適時推出了自己的函數(shù)式編程模型：Knative函數(shù)。

雖然不同的Serverless技術(shù)的共存對創(chuàng)新有很大幫助，但畢竟它們是不兼容的，因為不存在一個標(biāo)準(zhǔn)，而兼容性的挑戰(zhàn)在網(wǎng)絡(luò)邊界得到了解決。首先，容器鏡像的格式和執(zhí)行正在由Kubernetes社區(qū)定義。最重要的是很多Serverless平臺的事件模型是基于云事件標(biāo)準(zhǔn)，這是個非常重要的標(biāo)準(zhǔn)。它允許工作負(fù)載跨云合作，協(xié)作和執(zhí)行。Kubernetes提供了通用的執(zhí)行平臺，以及我們需要的該平臺上Serverless的通用定義。

最后一個挑戰(zhàn)是Serverless服務(wù)之間協(xié)調(diào)流轉(zhuǎn)的通用描述。創(chuàng)建一個簡單的Serverless解決方案不僅需要觸發(fā)器、事件源和不同服務(wù)的事件匯聚，還需要不同服務(wù)之間的協(xié)調(diào)。在各種流程語言中存在部分解決方案，那就是管道語言，但它不是為任意的帶有同步點的復(fù)雜圖設(shè)計的，更需要一種完整的工作流語言。這種語言可能是Tekton演變出來的，或者至少是其一個超集。

安全問題

伴隨每一項新技術(shù)的出現(xiàn)，新的網(wǎng)絡(luò)安全挑戰(zhàn)往往也隨之而來。而Serverless技術(shù)的出現(xiàn)改變了這種格局，因為更多的控制權(quán)從用戶端轉(zhuǎn)移到云端自動化，特別是對在何處使用多少計算資源來滿足需求的控制。由此伴隨網(wǎng)絡(luò)邊界逐漸消失，許多相關(guān)的安全控制也隨之消失。此外，伴隨Serverless帶來的低成本和簡化操作，許多的工作負(fù)載將被劃分為更細(xì)的自助服務(wù)，而工作負(fù)載的片段越來越多，攻擊者也會看到更大的攻擊面。

Knative社區(qū)應(yīng)對新的網(wǎng)絡(luò)安全挑戰(zhàn)的措施

• 對已部署的服務(wù)提升更新的效率和速度

Knative提供了協(xié)助服務(wù)修正的基本功能，支持在服務(wù)修正過程中進(jìn)行流量切分，從而使服務(wù)在修正版本的迭代期間能平滑、無風(fēng)險的過度。支持更高頻率的更新，以降低不斷變化的威脅和新發(fā)現(xiàn)的漏洞所帶來的風(fēng)險。

• 避免服務(wù)配置的任意性

Knative自動化部署確保服務(wù)所需的所有Kubernetes資源都出自單一的服務(wù)資源。違規(guī)者或內(nèi)部人員對任何資源的手動修改，無論有意還是無意都會被Knative自動化覆蓋，避免配置任意修改。

• 避免基礎(chǔ)設(shè)施配置的任意性

Knative使用Kubernetes來協(xié)助管理Knative的底層組件，但并不支持對Serverless的基礎(chǔ)設(shè)置進(jìn)行手動更改。

• 安全行為的監(jiān)控和控制

Knative社區(qū)正在引入新的技術(shù)來監(jiān)控已部署服務(wù)的行為以及發(fā)送到這些服務(wù)的事件的行為。安全衛(wèi)士是一種為每個服務(wù)量身定制的、運行時的安全保障，用于防護(hù)脆弱的服務(wù)免受0-day或已知漏洞的威脅。該技術(shù)還為你提供機(jī)制以應(yīng)對服務(wù)被利用的情況。

總結(jié)

隨著云計算的不斷發(fā)展，它已成為全球能耗的一個重要角色，據(jù)國際能源署的估計其已經(jīng)占了2021年全球能源消耗的1-1.5%和二氧化碳排放量的1%！Kubernetes規(guī)范了工作負(fù)載的部署和管理方式。而Knative憑借Serverless和高效性向前更進(jìn)一步，它有助于實現(xiàn)更環(huán)保的云計算，并為云服務(wù)商和云用戶節(jié)省大量成本，這種Serverless模式適用于所有的工作負(fù)載。更高的效率不僅僅是對單個工作負(fù)載來說的，還包括底層云資源和每個工作負(fù)載的執(zhí)行所消耗的能源。

除了效率之外，Serverless還為云用戶帶來別的額外好處，包括簡單化、自動化、版本修正管理和網(wǎng)絡(luò)安全的改善。然而這些也同樣存在挑戰(zhàn)，Kubernetes需要更進(jìn)一步優(yōu)化基于實際負(fù)載自動擴(kuò)展服務(wù)的動態(tài)特性。為了使Serverless更加通用，并涵蓋更多的用例場景，還有許多工作需要做。同樣為了使用Serverless模式，用戶也必須改進(jìn)他們的工作負(fù)載和部署的策略，當(dāng)然這些都需要時間。

隨著我們逐漸轉(zhuǎn)向Serverless模式，適用的新的工作負(fù)載和用例場景也是我們需要考慮的。人工智能，數(shù)據(jù)和機(jī)器學(xué)習(xí)社區(qū)在認(rèn)知這種按需分配計算資源模式的價值方面取得先機(jī)，Kubeflow和Tekon都是以Serverless模式設(shè)計和執(zhí)行數(shù)據(jù)密集型AI管道以及工作負(fù)載的很好的例子。其他未來可用的工作負(fù)載和用例場景還包括量子Serverless，通過它可以在量子計算機(jī)上按需使用或執(zhí)行量子算法。

Serverless模式代表了成本節(jié)約和分配資源的經(jīng)濟(jì)性，應(yīng)用是為這而設(shè)計的，而平臺對于運行Serverless解決方案也是高效和經(jīng)濟(jì)的，所以對各方都是有意義的。另外作為額外的獎勵，對環(huán)境也是有好處的。

鳴謝

感謝Paul Schweigert和Lionel Villard的反饋和意見。此外還要感謝整個Knative社區(qū)，感謝他們?yōu)閯?chuàng)建Kubernetes的Serverless平臺所做的貢獻(xiàn)和努力，在不到兩年的時間里，社區(qū)已經(jīng)發(fā)布了十幾個版本，改進(jìn)了各個方面并保持與Kubernetes的兼容，且允許擴(kuò)展和實驗各種創(chuàng)新。

譯者介紹

胥磊，51CTO社區(qū)編輯，某頭部電商技術(shù)副總監(jiān)，關(guān)注Java后端開發(fā)，技術(shù)管理，架構(gòu)優(yōu)化，分布式開發(fā)等領(lǐng)域。

原文標(biāo)題：??How do we make the future serverless?，作者：Michael Maximilien??, David Hadas, Angelo Danducci II, Simon Moser