?譯者 | 胥磊

審校 | 孫淑娟

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

挑戰

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

挑戰摘要

云計算優化

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

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

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

最后需要對KUbernetes和Knative進行優化，以充分發掘其解決能源和資金節約的潛力。Pod分配和集群控制應發展到支持動態調整（碎片整理）到其他工作節點的子集，這樣空閑的節點就可以暫停，當然當集群資源總體需求增加時還可以恢復。

服務設計

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

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

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

功能和工作流

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

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

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

安全問題

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

Knative社區應對新的網絡安全挑戰的措施

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

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

• 避免服務配置的任意性

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

• 避免基礎設施配置的任意性

Knative使用Kubernetes來協助管理Knative的底層組件，但并不支持對Serverless的基礎設置進行手動更改。

• 安全行為的監控和控制

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

總結

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

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

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

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

鳴謝

感謝Paul Schweigert和Lionel Villard的反饋和意見。此外還要感謝整個Knative社區，感謝他們為創建Kubernetes的Serverless平臺所做的貢獻和努力，在不到兩年的時間里，社區已經發布了十幾個版本，改進了各個方面并保持與Kubernetes的兼容，且允許擴展和實驗各種創新。

譯者介紹

胥磊，51CTO社區編輯，某頭部電商技術副總監，關注Java后端開發，技術管理，架構優化，分布式開發等領域。

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