綜述
近兩年來，Serverless 概念在開發者中交流的越來越多，實踐、服務、産品層出不窮。
Serverless 的主題分享呈現爆發趨勢，如在雲原生領域頗具影響力的 KubeCon&CloudNativeCon 會議中，關于 Serverless 的主題，2018 年有 20 個，到 2019 年增長至 35 個。
産品層面，從最早的 AWS Lambda，到 Azure Functions、Goolge Functions、Google CloudRun，再到國内阿裡雲 Serverless Kubernetes、Serverless 應用引擎、函數計算等，面向計算的 Serverless 雲上基礎設施越來越豐富。
新概念、新産品的産生不是憑空出現，它們誕生之初要解決的是目前問題。随着實踐者對問題域的了解越來越清晰和深刻，會逐漸疊代問題的處理方法，提供更接近問題本質的解決方案。
若不從問題域出發來了解解決方案，容易陷入兩個極端，即「它能解決一切問題」「它太超前了，了解不了」。
本篇文章嘗試以日常開發流程為起點，分析每個階段面對的問題，然後組合解決方案，提煉面向 Serverless 的開發模型，并與業界提出的 Serverless 産品形态做對應，為開發者采用 Serverless 架構和服務提供參考。
疊代模型
從項目整體視角來看：
這個模型的目标是滿足客戶需求。通過 被動疊代 滿足客戶提出的需求，同時逐漸深刻了解客戶需求的本質，通過 主動疊代 和客戶一起采用更好的方案或從根源解決面對的問題。
每次的需求回報會加深對客戶需求的了解，提供更滿足需求的服務。每次的 bug 回報會加深對處理方案的了解，提供更穩定的服務。
在模型啟動後，日常的核心問題就集中在了 如何加速疊代。
為了解決疊代加速的問題，需要了解有哪些制約因素，有的放矢。下述是從開發視角看到的開發模型：
雖然會有不同的開發語言和架構，但在每個階段均有通用的問題，如：
除了要解決上述通用問題，還需要提供标準化的方案，降低開發者的學習和使用成本，縮短從想法到上線的時間。
若将上述過程中不同階段花費的時間做個分析，在項目整個生命周期中會發現：
- 部署&運維 占用的時間和精力，會遠大于 開發&測試
- 通用邏輯 占用的時間和精力，會接近甚至超過 業務邏輯
為了加速疊代，需要依次解決占用時間和精力多的部分，如圖 1：
從左至右，通過下放不同層次的運維工作，降低「部署&運維」成本。在降低了運維工作成本後，在「通用邏輯」層面降低成本。二者結合起來，在疊代過程中更深入聚焦業務。
該過程也是從 Cloud Hosting 到 Cloud Native 的過程，充分享受雲原生帶來的技術紅利。
由于軟體設計架構和部署架構與當時環境耦合度高，面對新的理念和服務、産品，存量應用疊代過程中采用的技術需要有相應調整，即開發和部署方式需要有一定的改造。新應用的開發和部署應用新的理念時，有一定的學習和實踐成本。
故上述過程不能一蹴而就，需要根據業務目前的痛點優先級來選擇比對的服務和産品，并根據未來的規劃提前進行技術預研，在不同的階段選擇适合的服務和産品。
Serverless 簡介
維基百科對于 Serverless 有較為完備的定義 [1]:
Serverless computing is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. It can be a form of utility computing.
在這種計算模型下，給使用者會帶來如下收益：
Serverless computing can simplify the process of deploying code into production. Scaling, capacity planning and maintenance operations may be hidden from the developer or operator. Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.
概念本質上是對問題域的抽象，是對問題域特征的總結。通過特征來了解概念，可以避免注意力集中在文字描述而非概念的價值本身。
站在使用者角度，我們可以抽象出 Serverless 的如下特征：
- 免運維 (伺服器運維、容量管理、彈性伸縮等)
- 按資源的使用量付費
在一定規模的公司中，若嚴格區分開發和運維的角色，這種計算形态其實是已經存在的，并非全新的事物。但目前的技術趨勢，是期望借助雲的規模和技術紅利優勢，通過上雲來降低業務在技術側的成本，并通過技術紅利反哺業務。故業界對于 Serverless 的讨論，注意力是集中在雲上的服務和産品所展現的 Serverless 能力。
Serverless 開發模型
Martin Fowler 的這篇文章 [2] 站在架構的角度，對 Serverless 開發模型做了充分的闡述，這裡做個簡單的總結，核心圍繞三點：
- Event-driven 開發模型
- 自動彈性伸縮
- OpenAPI
Serverless 開發采用 Event-driven 模型 [3]，圍繞 HTTP/HTTPS 請求、時間、消息等 Event 的生産和響應進行架構設計。在這樣的模型中，Event 的生産、處理流程是核心，通過 Event 驅動整個服務流程，注意力集中在整個處理流程。對業務了解越深刻，Event 類型和業務會越比對，技術和業務的互相促進作用會越有效。
Event-driven 模型，使得 服務常駐 這種理念從必選項轉變為可選項，可以更好應對業務請求量的變化，如自動彈性伸縮。同時服務非常駐，可以降低所需的資源成本和維護成本，加速項目疊代。
通過文章 [2] 的兩幅圖可以更直覺了解：
圖 2
圖 3
圖 2 是目前常見的開發模型，Click Processor 服務是個常駐服務，響應來自使用者的所有點選請求。生産環境中，通常會多執行個體部署，常駐 是個關鍵特征，日常的運維重點在確定常駐服務的穩定性方面。
圖 3 是 Event-driven 開發模型，關注重心前移，集中在 Event 的産生和響應方面，響應服務是否常駐是個可選項。
Serverless 在概念上與 PaaS (Platform as a Service)、CaaS (Container as a Service) 的差別，重點是在是否将 自動彈性伸縮 作為概念誕生之初的核心特征。
結合 Event-driven 的開發模型，Serverless 場景中自動彈性伸縮需要對開發者透明度加深，開發者開發過程對處理能力的關注重心從靜态轉為動态，更好應對上線後業務請求量的不确定性。
在開發方面，傳遞時可以采用鏡像，也可以采用語言層面的打包 (如 Java 中的 war/jar) ，由平台負責運作時相關的工作。還可以更進一步，采用 FaaS 的理念，依托于平台或标準化 FaaS 解決方案，隻提供業務邏輯函數，由平台負責請求入口、請求調用和自動彈性伸縮等運作時事宜。
不論哪種傳遞方式，在雲上均可以使用 BaaS [4] 的理念，将部分邏輯通過雲平台或第三方的 OpenAPI 實作，如權限管理、中間件管理等，開發過程中注意力更加聚焦在業務層面。
Serverless 服務模型
Serverless 服務模型關注雲廠商對于 Serverless 計算形态的支援，不同的服務和産品形态主要差異點主要集中在對 Serverless 特征的了解和滿足程度方面：
在免運維次元，最基本的是免去伺服器運維成本，開發者可以按量申請資源。在容量管理、彈性伸縮、流量管理、日志/監控/告警等正常的運維層面，不同的服務和産品會根據自身定位、目标客戶特征等，有側重采用适合的方式來滿足。
在計費形态方面，雲廠商一方面會根據自身定位确定收費次元，如資源、請求量等，一方面也會根據目前的技術能力确定收費的粒度。
通過上述分析可知，雲廠商不同 Serverless 服務模型不是靜态的，會伴随産品定位、目标客戶特征、技術能力等持續疊代，和客戶共同成長。
Serverless 服務模型需要滿足實際需求，再回到圖 1，雲廠商的 Serverless 服務模型可以分為如下幾類：
- 資源執行個體平台
- 排程平台
- 應用管理平台
- 業務邏輯管理平台
綜合起來，即：
阿裡雲 Serverless 産品
國内的雲服務廠商，阿裡雲提供的 Serverless 服務和産品形态相對完備。這裡以阿裡雲為例進行探讨，探讨的經驗可以平滑遷移到其他雲服務廠商。
從阿裡雲公開的資料 [5] 可以了解到幾類常見的 Serverless 産品形态：
上述雲産品分類可以清晰和圖 1 的模型對應起來，使用者在進行選擇時，先整理目前業務技術所處的階段和痛點，确定對雲上方案的需求，然後再根據雲廠商的産品形态做對應，選擇适合目前階段的服務和雲産品。
該對應關系重點是了解雲産品定位是否可以長期滿足業務需求，如：
- 業務技術目前所處的階段是否有對應的 Serverless 産品形态
- 業務快速疊代是否會受限于雲産品自身的發展
- 雲産品的穩定如何
- 雲産品是否可以持續為業務帶來技術紅利
同時還需要了解雲産品是否可以伴随業務發展，重點是業務對技術的需求中，哪些是雲産品層面由于定位帶來的限制，哪些是目前雲産品的技術實作帶來的限制。
若是雲産品定位帶來的限制，那麼就需要考慮使用和業務需求定位更比對的雲産品。若是目前技術實作的限制，那麼有機會和雲産品共同成長，及時給雲産品回報，使得雲産品可以更好滿足自身的業務需求。
除此之外，業務層面還需關注雲廠商自身服務類型的豐富性，雲廠商自身服務越豐富，規模越大，越會産生規模效應，進而給業務帶來更豐富的技術紅利和成本優勢。
幸運的是，雲産品通常都會有豐富的文檔，也有相應的使用者群，可以直面産品 PD 和研發。雲産品的 PD 和研發也很期望直面使用者，聆聽使用者的回報和需求，和使用者一起共建。
下面簡單介紹下阿裡雲 Serverless 産品和使用者釘釘群。
阿裡雲 ECI 産品 [6] 是 Serverless 和容器化的彈性計算服務，使用者無需管理底層伺服器，隻需要提供打包好的鏡像，即可運作容器，并僅為容器實際運作消耗的資源付費。
阿裡雲 Serverless Kubernetes (簡稱 ASK) 是阿裡雲容器服務産品 [7] 家族中的一種形态，托管 Kubernetes Master 元件，依托阿裡雲 ECI 産品提供 Pod 執行個體，使用者無需運維 Kubernetes Master 和 Agent 節點即可使用 Kubernetes 排程能力，詳情可參見産品文檔 [8]。
阿裡雲 Serverless 應用引擎 (簡稱 SAE) [9] 是面向應用的 Serverless PaaS 平台，幫助 PaaS 層使用者免運維 IaaS，按需使用，按量計費，實作低門檻微服務應用上雲，有效解決成本及效率問題。支援 Spring Cloud、Dubbo 和 HSF 等流行的開發架構，真正實作了 Serverless 架構和微服務架構的完美融合。除了微服務應用外，使用者還能通過 Docker 鏡像部署任何語言的應用。
阿裡雲函數計算有兩款産品，函數計算 [10] 是一個事件驅動的全托管 Serverless 計算服務，使用者無需管理伺服器等基礎設施，隻需編寫代碼并上傳，函數計算會為使用者準備好計算資源，并以彈性、可靠的方式運作使用者代碼。Serverless 工作流 [11] 是一個用來協調多個分布式任務執行的全托管 Serverless 雲服務，緻力于簡化開發和運作業務流程所需要的任務協調、狀态管理以及錯誤處理等繁瑣工作，讓使用者聚焦業務邏輯開發。使用者可以用順序、分支、并行等方式來編排分布式任務，服務會按照設定好的順序可靠地協調任務執行，跟蹤每個任務的狀态轉換，并在必要時執行使用者定義的重試邏輯，以確定工作流順利完成。
使用者釘釘群：
小結
Serverless 本質上是一個問題域，将研發流程中非業務核心卻影響業務疊代的問題抽象化，并提出相應的解決方案。該概念不是突然産生的，大家或多或少已經将其理念應用到日常的工作中 ，隻是伴随着雲計算浪潮，雲上的 Serverless 服務和産品更系統、更具有競争力，可以基于規模優勢和豐富的産品線，面對問題域持續提供更滿足業務需求的服務。
Serverless 理念不僅在中心化的雲端蓬勃發展，目前也逐漸在邊緣端發展，使得服務的運作更加廣泛化，更好滿足業務自身的客戶，提供更低延時、穩定的服務。
本篇文章嘗試從項目、開發的日常流程出發，協助讀者從日常實踐角度來了解 Serverless 概念，根據所處的階段選擇适合的 Serverless 服務和産品。并嘗試從雲産品内部的視角，傳遞雲産品和使用者共建的觀念，通過不同的分工更好傳遞和創造價值。
References
- [1] wikipedia: Serverless computing
- [2] Martin Fowler: Serverless Architectures
- [3] wikipedia: Event-driven architecture
- [4] wikipedia: Mobile backend as a service
- [5] 從 DevOps 到 NoOps，Serverless 技術的落地方式探讨
- [6] 阿裡雲 ECI 産品首頁
- [7] 阿裡雲容器服務
- [8] 阿裡雲 Serverless Kubernetes 産品文檔
- [9] 阿裡雲 Serverless 應用引擎
- [10] 阿裡雲函數計算
- [11] 阿裡雲 Serverless 工作流
- Cloud Programming Simplified: A Berkeley View on Serverless Computing