對企業而言，Serverless 架構有著巨大的應用潛力。隨著雲產品的完善，產品的集成和被集成能力的加強，軟件交付流程自動化能力的提高，我們相信在 Serverless 架構下，企業的敏捷性有 10 倍提升的潛力。本次分享我主要分為以下四個方面：
一、DevOps的挑戰以及如何降低 DevOps 實施代價？
二、為什麼 Serverless 是雲發展的必然結果？
三、Serverless+DevOps =？
四、實戰案例分享
一、DevOps的挑戰
DevOps的挑戰
對於應用交付的整個流程而言，通常會涉及三個環節，即開發、測試和運維，而在傳統的組織架構中，他們對應的也往往是三個不同的團隊。這三個環節各自有自己的側重點，但是在實際上，想要讓整個應用交付過程變得順滑高效，並且讓應用在上線後保持高可用的狀態，往往需要三個團隊將相互之間存在的牆打破掉。
這裡的牆不只是組織架構隔閡所帶來的障礙，還包括三個領域關注點的不同。比如開發需要關注可測試性和可運維性，這些東西將會深刻地影響應用的架構設計和開發實現，如果開發同學沒有充分考慮到代碼的可測試性，那麼交給測試同學就會造成很大的問題，比如如何實現故障注入和精細流控，這都需要在開發時就考慮清楚。
對於運維而言也是一樣的，開發的時候也需要考慮到可運維性，比如在開發的時候就需要考慮如何在服務實際上下線的時候做到平滑且不丟失數據，同時這樣的設計也需要和運維繫統進行深刻的對接，這樣才能非常可靠、非常安全地連接起來，提升運維的效率。
阿里內部之前很多故障也都是因為開發和運維之間在設計上面存在信息不一致導致的，比如在開發設計時會做三副本的高可靠保證，但是在運維側則可能會認為副本所在的機器沒有提供服務因此被錯誤下線掉。
所以，DevOps 實際上包含了兩層含義，首先是將開發、測試、運維變成一個團隊；其次，還需要讓整個團隊的心智統一，這也是DevOps 真正的挑戰。
DevOps的挑戰-開發
快速回顧一下DevOps每個環節所需要考慮的東西。在開發階段，首先需要梳理業務的需求和場景，並且將需求轉換為系統設計，同時需要考慮數據模型如何設計，才能夠讓數據庫不成為單點和瓶頸。因為在阿里巴巴這樣的互聯網企業中，應用承載了大量的用戶訪問，因此需要考慮複雜均衡、容錯設計、流量控制等。
如果採用了微服務架構，應用將由多個服務組成，那麼還需要考慮服務管理。以上全部考慮到之後，將其轉化為系統設計，最後進行開發調試以及單元測試，完成了這些之後才可以將應用交給測試環節。
DevOps 的挑戰-測試
在測試時需要考慮很多方面和維度，保證軟件各方面的質量。測試包括了集成測試、端到端的 E2E 測試、性能測試、壓力測試、容錯測試、兼容測試、破壞測試等。
DevOps 的挑戰-運維
當應用通過測試之後，就產出了一個交付物，這個交付物被認為具備了可以發佈的能力，後續就需要進行運維工作了，比如應用灰度發佈、升級回滾、服務器上下線、監控報警、安全補丁升級、網路配置、操作審計、生產環境引流等。
DevOps 的挑戰-如何降低 DevOps 實施代價？
當我們深入地看 DevOps 中所包含的這些工作項之後，其實能夠感受到如果想要做一個具有彈性的、高可靠的應用，需要考慮的點是非常多的，而這些在實施了 DevOps 之後就變成了同一個團隊在整個應用生命週期中需要考慮的事情了。這對於團隊心智和能力的要求是非常高的。
DevOps 應用交付流水線裡面包含了很多環節，如何將這些環節非常流暢地串聯起來，實現自動化也是非常重要的方面。
回顧了 DevOps 的挑戰之後，通過阿里內部和整個業界的實踐可以看到，需要通過平臺和工具降低 DevOps 的複雜度。
二、Serverless簡介
雲的趨勢
在介紹 Serverless 之前，首先回顧一下雲的發展趨勢，再來探討為什麼 Serverless 是雲發展的必然結果。
在過去的十年間，雲計算獲得了很大的發展，其使得用戶能夠通過API的方式非常輕鬆地獲得近乎無限的算力，而這些算力是通過虛擬機來呈現的，這樣的模式存在很多的優點，它和應用原來的開發和運行環境是兼容的，這種模式能夠使得傳統遺留應用非常平滑地遷移到雲上。
雲的第一個階段就是基礎設施雲化，這裡就是雲託管模式。基於雲上的存儲、網絡等基礎設施來構建應用，這種模式的核心價值在於資源的彈性和成本。下一個階段中，雲的體系已經遠遠超越了基礎設施，能夠看到在各個領域都出現了很多的雲服務。因此，在今天需要考慮如何利用雲服務的能力，以搭積木的方式來更快速地構建應用，而不是重複造輪子，這就是雲原生的模式。
雲的產品體系正在迅速 Serverless 化
目前，主流的雲計算產商的產品體系也正在迅速地 Serverless 化，這並非是對於未來的預測，而是實際正在發生的事實。下圖中的數據是基於對於AWS、微軟和阿里雲的產品所發佈的新功能或者新服務形式的統計，可以看到絕大多數的新服務都在呈現Serverless 化。
雲編程模型
雲計算產生了大量的服務，在效能的角度來看，這些雲服務是在更高層次抽象的 Serverless 形態，這就變得非常有意義了。如果從雲編程模型的角度重新來審視雲產品體系，能夠看到最底層是基礎設施層，這一層包含兩部分，分別是 IaaS 和容器。在基礎設施之上就是雲原生應用操作系統，K8s 是這一層的事實標準，它能夠把底層 IaaS 基礎設施很好地管理起來。在操作系統之上出現了非常豐富的API，也就是全託管的雲服務體系。如果看阿里雲的產品體系，就會發現了阿里雲提供了豐富的產品體系，包括數據庫、大數據、中間件，這些都是以 Serverless 全託管模式提供服務的。
在這樣具有大量雲 API 的情況下，今天的問題是如何設計一個通用的計算框架能夠與這些 Serverless 的雲服務、雲 API 產生非常緊密的連接來幫助客戶快速構建彈性、高可用應用。因此在框架層就出現了Serverless計算，其產生的原因最主要是需要和雲API發生緊密的化學反應，幫助用戶提升應用構建和運維效率，幫助客戶構建分佈式、數據化、智能化的新一代的雲原生應用。
雲託管和Serverless應用差異
這裡對比一下采用雲託管的應用和採用 Serverless 的應用最本質的差異在哪裡。對於應用而言，可以將其構建模式拆分為三層，分別是底層基礎設施管理、中間的外部服務集成和上層的應用邏輯。如果採用雲託管模式，實際上是在基礎設施層去構建應用，應用構建的抽象層次是比較低的，因此會帶來大量工作，用戶自己需要整合不同的組件和服務，需要進行大量的決策和實現，交付的速度會比較慢，需要考慮很多的事情，而且在運維方面有大量的重複工作。
如果用戶採用 Serverless 的模式構建應用，也就是相當於在上層API的方式構建應用，粘合的邏輯和基礎設施管理的工作都由雲服務商來承擔，用戶所需要整合和決策的代價比較低，所需要考慮的主要就是如何將業務邏輯和需求與雲服務進行適配來構建應用。基於非常高效的雲API來構建應用的好處在於構建的成本很低，並且能夠實現按天、按小時進行交付，並且大大降低未來運維的負擔。
什麼是Serverless計算？
Serverless計算具有四個特點：首先，不需要維護雲計算基礎設施，應用構建的抽象層次上升，變得更加高效；其次，能夠實現實時的彈性伸縮，這樣能夠通過未來的數據驅動的負載感知算法能夠實現既滿足很低的延時，也能夠實現很高的資源利用率；再次，計量模式提供了非常細粒度的按需的模式，可以實現按秒級計量，能夠實現完全按需的付費模式，對於用戶而言，資源利用率是100%；最後，能夠實現高可用，將這種能力內置在平臺層。
阿里雲Serverless產品體系
這裡做一個說明，Serverless 計算只是阿里雲 Serverless 產品中的一部分，除此之外還包括存儲、API、分析、中間件等。因此，從這個角度來看，Serverless 也不是一個非常新的概念，最早的 OSS 對象存儲就是一個 Serverless 產品，可以看出雲產品體系正在 Serverless 化，只不過最近幾年出現了函數計算這樣通用的 Serverless 計算平臺，進而能夠將 Serverless 體系產品連接起來，構建一個 Serverless 應用。
三、Serverless DevOps
當有了這些 Serverless 的能力，那麼如何將這些能力與 DevOps 結合起來呢？
簡化基礎設施的管理和運維
下圖更多地是從如何構建高可用應用的角度來展現。這裡將應用的模塊分為四個方面：包括基礎設施、運行時、數據和應用。基礎設施層就是需要處理與機器相關的操作，比如故障處理。運行時則需要做應用資源隔離、流控等。數據層主要需要和數據庫、緩存相關，比如如何設計數據庫表結構，如何設計緩存策略，如何實現負載均衡，如何保證不會出現橫向擴展瓶頸。
在應用層，則需要處理與應用相關的操作，比如代碼包的錯誤、配置錯誤、心跳異常的處理。下圖中藍色虛框中的部分可以完全由平臺負責，用戶可以無感知；藍色實框則是平臺幫助用戶做了大量工作，但是還是需要用戶感知和作出一定決策；紅色框則代表還是需要用戶自己管理的部分。可以看到，在容錯方面，平臺提供了非常強的能力，包括多AZ的容災能力、快速的彈性能力、內置的流控能力以及多層次、多維度的監控報警能力。藉助於這些能力，用戶管理基礎設施的複雜度就大大降低了。
敏捷的應用角度流程
下圖展示了應用交付的流程，代碼通過統一管理的代碼庫存儲和管理起來，再通過持續集成將其變成一個交付物，再將其存儲到交付物倉庫裡面。交付物可以是容器鏡像，也可以是代碼包的模式。產出了交付物之後，可以自動地將其部署到測試、生產環境中去做版本部署，最後實現到生產環境的自動部署。因此這樣應用交付流程的關鍵點在於實現高度自動化，而自動化的關鍵環節有兩點：分別是基礎設施即代碼和環節間的自動化串聯。
自動化應用交付流水線
下圖展現的是自動化應用交付流水線，可以看到在下面的每一個環節都需要實現很多的功能，而很多都是重複性工作，因此需要做到基礎設施即代碼。
基礎設施即代碼
下圖是基礎設施即代碼的展示。Serverless 應用模型通過聲明來定義應用資源，能夠實現標準化、自動化和可視化。
可以為模板傳入不同參數，可以動態生成應用運行環境。
服務版本和灰度發佈
在函數計算裡面，應用有版本的概念，版本是一個不可變實體，因此杜絕了版本因為非預期的修改造成線上應用受損，阿里雲通過服務版本和灰度發佈避免了這樣的問題，客戶端訪問應用通過別名來訪問。
Serverless工作流
阿里雲提供了 Serverless 工作流方便用戶將 DevOps 串聯起來，用戶可以通過配套的服務能力、工具能力快速地創建工作流，並且以可視化的方式展現出來，能夠清楚地看到工作流的效果。
自動化應用交付流水線
回顧一下當有了這些能力之後，如何實現自動化應用交付流水線。在源碼階段，可以實現代碼質量靜態檢查，保證 CheckIn 的代碼質量。當 CheckIn 到代碼庫之後，會自動運行單元測試，並且產出交付物。在測試的環節，通過與阿里雲 ROS 的無縫集成能夠實現自動化部署到測試環境，並且運行測試用例。這些完成之後，通過 ReleaseManager 可以確認部署，通過工作流將這些任務串聯起來，發佈到預發佈環境中，並且進一步部署到生產環境中，每一個步驟都實現了自動化，研發效能得到了極大提升。
日誌收集和查詢
在 Serverless 計算平臺之上，原生提供了很多的日誌收集和 Metric 收集能力，比如簡單日誌查詢以及高級日誌查詢，能夠通過日誌方式為用戶提供高級數據分析能力。
指標收集和可視化能力
Serverless 計算平臺除了提供了基本的指標視圖之外，還支持自定義指標視圖，用戶可以通過自定義的關鍵詞指標搜索實現與業務相關的數據分析。
當 Serverless 和 DevOps 結合之後，能夠大大提升研發效能，一方面大大降低了開發團隊的心智負擔；另外一方面，通過工具使得整個 DevOps 流水線能夠實現高度自動化。
四、案例分享
最後分享一些比較成功的案例。阿里Serverless計算支撐了阿里經濟體小程序平臺，節省了40%研發資源。阿里雲 Serverless 支撐語雀使用函數計算實現文檔等計算密集型業務，大幅度地降低了運維成本，還為石墨文檔降低了58%的運維成本，幫助微博提升了研發效能，使得功能上線時間從原本的2周變為幾小時。
可以看到，2020年業界對於Serverless的接受度有了極大提升，同時，Serverless的能力也變得更加普適。
作者介紹：
楊皓然（不瞋），Serverless 計算負責人，2010 年加入阿里雲，深度參與了阿里雲飛天分佈式系統研發和產品迭代的全過程。對大規模分佈式計算，大規模數據存儲和處理有非常深入的理解。
