作者 |?楊皓然（不瞋）

對企業而言，Serverless 架構有著巨大的應用潛力。隨著云產品的完善，產品的集成和被集成能力的加強，軟件交付流程自動化能力的提高，我們相信在 Serverless 架構下，企業的敏捷性有 10 倍提升的潛力。本次分享我主要分為以下四個方面：

一、DevOps 的挑戰以及如何降低 DevOps 實施代價？
二、為什么 Serverless 是云發展的必然結果？
三、Serverless + DevOps =？
四、實戰案例分享

DevOps 的挑戰

1. DevOps 的挑戰

對于應用交付的整個流程而言，通常會涉及三個環節，即開發、測試和運維，而在傳統的組織架構中，他們對應的也往往是三個不同的團隊。這三個環節各自有自己的側重點，但是在實際上，想要讓整個應用交付過程變得順滑高效，并且讓應用在上線后保持高可用的狀態，往往需要三個團隊將相互之間存在的墻打破掉。

這里的墻不只是組織架構隔閡所帶來的障礙，還包括三個領域關注點的不同。比如開發需要關注可測試性和可運維性，這些東西將會深刻地影響應用的架構設計和開發實現，如果開發同學沒有充分考慮到代碼的可測試性，那么交給測試同學就會造成很大的問題，比如如何實現故障注入和精細流控，這都需要在開發時就考慮清楚。

對于運維而言也是一樣的，開發的時候也需要考慮到可運維性，比如在開發的時候就需要考慮如何在服務實際上下線的時候做到平滑且不丟失數據，同時這樣的設計也需要和運維系統進行深刻的對接，這樣才能非常可靠、非常安全地連接起來，提升運維的效率。

阿里內部之前很多故障也都是因為開發和運維之間在設計上面存在信息不一致導致的，比如在開發設計時會做三副本的高可靠保證，但是在運維側則可能會認為副本所在的機器沒有提供服務因此被錯誤下線掉。

所以，DevOps 實際上包含了兩層含義，首先是將開發、測試、運維變成一個團隊；其次，還需要讓整個團隊的心智統一，這也是 DevOps 真正的挑戰。

2. DevOps 的挑戰 - 開發

快速回顧一下 DevOps 每個環節所需要考慮的東西。在開發階段，首先需要梳理業務的需求和場景，并且將需求轉換為系統設計，同時需要考慮數據模型如何設計，才能夠讓數據庫不成為單點和瓶頸。因為在阿里巴巴這樣的互聯網企業中，應用承載了大量的用戶訪問，因此需要考慮復雜均衡、容錯設計、流量控制等。

如果采用了微服務架構，應用將由多個服務組成，那么還需要考慮服務管理。以上全部考慮到之后，將其轉化為系統設計，最后進行開發調試以及單元測試，完成了這些之后才可以將應用交給測試環節。

3. DevOps 的挑戰 - 測試

在測試時需要考慮很多方面和維度，保證軟件各方面的質量。測試包括了集成測試、端到端的 E2E 測試、性能測試、壓力測試、容錯測試、兼容測試、破壞測試等。

4. DevOps 的挑戰 - 運維

當應用通過測試之后，就產出了一個交付物，這個交付物被認為具備了可以發布的能力，后續就需要進行運維工作了，比如應用灰度發布、升級回滾、服務器上下線、監控報警、安全補丁升級、網路配置、操作審計、生產環境引流等。

5. DevOps 的挑戰 - 如何降低 DevOps 實施代價？

當我們深入地看 DevOps 中所包含的這些工作項之后，其實能夠感受到如果想要做一個具有彈性的、高可靠的應用，需要考慮的點是非常多的，而這些在實施了 DevOps 之后就變成了同一個團隊在整個應用生命周期中需要考慮的事情了。這對于團隊心智和能力的要求是非常高的。

DevOps 應用交付流水線里面包含了很多環節，如何將這些環節非常流暢地串聯起來，實現自動化也是非常重要的方面。

回顧了 DevOps 的挑戰之后，通過阿里內部和整個業界的實踐可以看到，需要通過平臺和工具降低 DevOps 的復雜度。

Serverless 簡介

1. 云的趨勢

在介紹 Serverless 之前，首先回顧一下云的發展趨勢，再來探討為什么 Serverless 是云發展的必然結果。

在過去的十年間，云計算獲得了很大的發展，其使得用戶能夠通過 API 的方式非常輕松地獲得近乎無限的算力，而這些算力是通過虛擬機來呈現的，這樣的模式存在很多的優點，它和應用原來的開發和運行環境是兼容的，這種模式能夠使得傳統遺留應用非常平滑地遷移到云上。

云的第一個階段就是基礎設施云化，這里就是云托管模式。基于云上的存儲、網絡等基礎設施來構建應用，這種模式的核心價值在于資源的彈性和成本。下一個階段中，云的體系已經遠遠超越了基礎設施，能夠看到在各個領域都出現了很多的云服務。因此，在今天需要考慮如何利用云服務的能力，以搭積木的方式來更快速地構建應用，而不是重復造輪子，這就是云原生的模式。

2. 云的產品體系正在迅速 Serverless 化

目前，主流的云計算產商的產品體系也正在迅速地 Serverless 化，這并非是對于未來的預測，而是實際正在發生的事實。下圖中的數據是基于對于 AWS、微軟和阿里云的產品所發布的新功能或者新服務形式的統計，可以看到絕大多數的新服務都在呈現 Serverless 化。

3. 云編程模型

云計算產生了大量的服務，在效能的角度來看，這些云服務是在更高層次抽象的 Serverless 形態，這就變得非常有意義了。如果從云編程模型的角度重新來審視云產品體系，能夠看到最底層是基礎設施層，這一層包含兩部分，分別是 IaaS 和容器。在基礎設施之上就是云原生應用操作系統，K8s 是這一層的事實標準，它能夠把底層 IaaS 基礎設施很好地管理起來。在操作系統之上出現了非常豐富的 API，也就是全托管的云服務體系。如果看阿里云的產品體系，就會發現了阿里云提供了豐富的產品體系，包括數據庫、大數據、中間件，這些都是以 Serverless 全托管模式提供服務的。

在這樣具有大量云 API 的情況下，今天的問題是如何設計一個通用的計算框架能夠與這些 Serverless 的云服務、云 API 產生非常緊密的連接來幫助客戶快速構建彈性、高可用應用。因此在框架層就出現了 Serverless 計算，其產生的原因最主要是需要和云 API 發生緊密的化學反應，幫助用戶提升應用構建和運維效率，幫助客戶構建分布式、數據化、智能化的新一代的云原生應用。

4. 云托管和 Serverless 應用差異

這里對比一下采用云托管的應用和采用 Serverless 的應用最本質的差異在哪里。對于應用而言，可以將其構建模式拆分為三層，分別是底層基礎設施管理、中間的外部服務集成和上層的應用邏輯。如果采用云托管模式，實際上是在基礎設施層去構建應用，應用構建的抽象層次是比較低的，因此會帶來大量工作，用戶自己需要整合不同的組件和服務，需要進行大量的決策和實現，交付的速度會比較慢，需要考慮很多的事情，而且在運維方面有大量的重復工作。

如果用戶采用 Serverless 的模式構建應用，也就是相當于在上層 API 的方式構建應用，粘合的邏輯和基礎設施管理的工作都由云服務商來承擔，用戶所需要整合和決策的代價比較低，所需要考慮的主要就是如何將業務邏輯和需求與云服務進行適配來構建應用。基于非常高效的云 API 來構建應用的好處在于構建的成本很低，并且能夠實現按天、按小時進行交付，并且大大降低未來運維的負擔。

5. 什么是 Serverless 計算？

Serverless 計算具有四個特點：首先，不需要維護云計算基礎設施，應用構建的抽象層次上升，變得更加高效；其次，能夠實現實時的彈性伸縮，這樣能夠通過未來的數據驅動的負載感知算法能夠實現既滿足很低的延時，也能夠實現很高的資源利用率；再次，計量模式提供了非常細粒度的按需的模式，可以實現按秒級計量，能夠實現完全按需的付費模式，對于用戶而言，資源利用率是 100%；最后，能夠實現高可用，將這種能力內置在平臺層。

6. 阿里云 Serverless 產品體系

這里做一個說明，Serverless 計算只是阿里云 Serverless 產品中的一部分，除此之外還包括存儲、API、分析、中間件等。因此，從這個角度來看，Serverless 也不是一個非常新的概念，最早的 OSS 對象存儲就是一個 Serverless 產品，可以看出云產品體系正在 Serverless 化，只不過最近幾年出現了函數計算這樣通用的 Serverless 計算平臺，進而能夠將 Serverless 體系產品連接起來，構建一個 Serverless 應用。

Serverless DevOps

當有了這些 Serverless 的能力，那么如何將這些能力與 DevOps 結合起來呢？

1. 簡化基礎設施的管理和運維

下圖更多地是從如何構建高可用應用的角度來展現。這里將應用的模塊分為四個方面：包括基礎設施、運行時、數據和應用。基礎設施層就是需要處理與機器相關的操作，比如故障處理。運行時則需要做應用資源隔離、流控等。數據層主要需要和數據庫、緩存相關，比如如何設計數據庫表結構，如何設計緩存策略，如何實現負載均衡，如何保證不會出現橫向擴展瓶頸。

在應用層，則需要處理與應用相關的操作，比如代碼包的錯誤、配置錯誤、心跳異常的處理。下圖中藍色虛框中的部分可以完全由平臺負責，用戶可以無感知；藍色實框則是平臺幫助用戶做了大量工作，但是還是需要用戶感知和作出一定決策；紅色框則代表還是需要用戶自己管理的部分。可以看到，在容錯方面，平臺提供了非常強的能力，包括多 AZ 的容災能力、快速的彈性能力、內置的流控能力以及多層次、多維度的監控報警能力。借助于這些能力，用戶管理基礎設施的復雜度就大大降低了。

2. 敏捷的應用角度流程

下圖展示了應用交付的流程，代碼通過統一管理的代碼庫存儲和管理起來，再通過持續集成將其變成一個交付物，再將其存儲到交付物倉庫里面。交付物可以是容器鏡像，也可以是代碼包的模式。產出了交付物之后，可以自動地將其部署到測試、生產環境中去做版本部署，最后實現到生產環境的自動部署。因此這樣應用交付流程的關鍵點在于實現高度自動化，而自動化的關鍵環節有兩點：分別是基礎設施即代碼和環節間的自動化串聯。

3. 自動化應用交付流水線

下圖展現的是自動化應用交付流水線，可以看到在下面的每一個環節都需要實現很多的功能，而很多都是重復性工作，因此需要做到基礎設施即代碼。

4. 基礎設施即代碼

下圖是基礎設施即代碼的展示。Serverless 應用模型通過聲明來定義應用資源，能夠實現標準化、自動化和可視化。

可以為模板傳入不同參數，可以動態生成應用運行環境。

5. 服務版本和灰度發布

在函數計算里面，應用有版本的概念，版本是一個不可變實體，因此杜絕了版本因為非預期的修改造成線上應用受損，阿里云通過服務版本和灰度發布避免了這樣的問題，客戶端訪問應用通過別名來訪問。

6. Serverless 工作流

阿里云提供了 Serverless 工作流方便用戶將 DevOps 串聯起來，用戶可以通過配套的服務能力、工具能力快速地創建工作流，并且以可視化的方式展現出來，能夠清楚地看到工作流的效果。

7. 自動化應用交付流水線

回顧一下當有了這些能力之后，如何實現自動化應用交付流水線。在源碼階段，可以實現代碼質量靜態檢查，保證 CheckIn 的代碼質量。當 CheckIn 到代碼庫之后，會自動運行單元測試，并且產出交付物。在測試的環節，通過與阿里云 ROS 的無縫集成能夠實現自動化部署到測試環境，并且運行測試用例。這些完成之后，通過 ReleaseManager 可以確認部署，通過工作流將這些任務串聯起來，發布到預發布環境中，并且進一步部署到生產環境中，每一個步驟都實現了自動化，研發效能得到了極大提升。

8. 日志收集和查詢

在 Serverless 計算平臺之上，原生提供了很多的日志收集和 Metric 收集能力，比如簡單日志查詢以及高級日志查詢，能夠通過日志方式為用戶提供高級數據分析能力。

9. 指標收集和可視化能力

Serverless 計算平臺除了提供了基本的指標視圖之外，還支持自定義指標視圖，用戶可以通過自定義的關鍵詞指標搜索實現與業務相關的數據分析。

當 Serverless 和 DevOps 結合之后，能夠大大提升研發效能，一方面大大降低了開發團隊的心智負擔；另外一方面，通過工具使得整個 DevOps 流水線能夠實現高度自動化。

案例分享

最后分享一些比較成功的案例。阿里 Serverless 計算支撐了阿里經濟體小程序平臺，節省了 40% 研發資源。阿里云 Serverless 支撐語雀使用函數計算實現文檔等計算密集型業務，大幅度地降低了運維成本，還為石墨文檔降低了 58% 的運維成本，幫助微博提升了研發效能，使得功能上線時間從原本的 2 周變為幾小時。

可以看到，2020 年業界對于 Serverless 的接受度有了極大提升，同時，Serverless 的能力也變得更加普適。

**作者介紹：**楊皓然（不瞋），Serverless 計算負責人，2010 年加入阿里云，深度參與了阿里云飛天分布式系統研發和產品迭代的全過程。對大規模分布式計算，大規模數據存儲和處理有非常深入的理解。

課程推薦

為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕松擁抱云計算的新范式——Serverless。點擊鏈接即可免費學習課程：https://developer.aliyun.com/learning/roadmap/serverless

Serverless 公眾號，發布 Serverless 技術最新資訊，匯集 Serverless 技術最全內容，關注 Serverless 趨勢，更關注你落地實踐中的遇到的困惑和問題。

總結

以上是生活随笔為你收集整理的Serverless 对研发效能的变革和创新的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。