綜述
近兩年來，Serverless 概念在開發者中交流的愈來愈多，實踐、服務、產品層出不窮。
html
Serverless 的主題分享呈現爆發趨勢，如在雲原生領域頗具影響力的 KubeCon&CloudNativeCon 會議中，關於 Serverless 的主題，2018 年有 20 個，到 2019 年增加至 35 個。安全
產品層面，從最先的 AWS Lambda，到 Azure Functions、Goolge Functions、Google CloudRun，再到國內阿里雲 Serverless Kubernetes、Serverless 應用引擎、函數計算等，面向計算的 Serverless 雲上基礎設施愈來愈豐富。服務器
新概念、新產品的產生不是憑空出現，它們誕生之初要解決的是當前問題。隨着實踐者對問題域的理解愈來愈清晰和深入，會逐步迭代問題的處理方法，提供更接近問題本質的解決方案。微信
若不從問題域出發來理解解決方案，容易陷入兩個極端，即「它能解決一切問題」「它太超前了，理解不了」。架構
本篇文章嘗試以平常開發流程爲起點，分析每一個階段面對的問題，而後組合解決方案，提煉面向 Serverless 的開發模型，並與業界提出的 Serverless 產品形態作對應，爲開發者採用 Serverless 架構和服務提供參考。
app
從項目總體視角來看：
框架
這個模型的目標是知足客戶需求。經過 被動迭代 知足客戶提出的需求，同時逐步深入理解客戶需求的本質，經過 主動迭代 和客戶一塊兒採用更好的方案或從根源解決面對的問題。less
每次的需求反饋會加深對客戶需求的理解，提供更知足需求的服務。每次的 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
本文分享自微信公衆號 - 雲服務圈（heidcloud）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。