Serverless對研發效能的變革和創新

對企業而言，Serverless 架構有着巨大的應用潛力。隨着雲產品的完善，產品的集成和被集成能力的增強，軟件交付流程自動化能力的提升，咱們相信在 Serverless 架構下，企業的敏捷性有 10 倍提高的潛力。本次分享我主要分爲如下四個方面：
1、DevOps的挑戰以及如何下降 DevOps 實施代價？
2、爲何 Serverless 是雲發展的必然結果？
3、Serverless+DevOps =？
4、實戰案例分享

1、DevOps的挑戰

DevOps的挑戰

對於應用交付的整個流程而言，一般會涉及三個環節，即開發、測試和運維，而在傳統的組織架構中，他們對應的也每每是三個不一樣的團隊。這三個環節各自有本身的側重點，可是在實際上，想要讓整個應用交付過程變得順滑高效，而且讓應用在上線後保持高可用的狀態，每每須要三個團隊將相互之間存在的牆打破掉。

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

對於運維而言也是同樣的，開發的時候也須要考慮到可運維性，好比在開發的時候就須要考慮如何在服務實際上下線的時候作到平滑且不丟失數據，同時這樣的設計也須要和運維繫統進行深入的對接，這樣才能很是可靠、很是安全地鏈接起來，提高運維的效率。

阿里內部以前不少故障也都是由於開發和運維之間在設計上面存在信息不一致致使的，好比在開發設計時會作三副本的高可靠保證，可是在運維側則可能會認爲副本所在的機器沒有提供服務所以被錯誤下線掉。

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

DevOps的挑戰-開發

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

若是採用了微服務架構，應用將由多個服務組成，那麼還須要考慮服務管理。以上所有考慮到以後，將其轉化爲系統設計，最後進行開發調試以及單元測試，完成了這些以後才能夠將應用交給測試環節。

DevOps 的挑戰-測試

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

DevOps 的挑戰-運維

當應用經過測試以後，就產出了一個交付物，這個交付物被認爲具有了能夠發佈的能力，後續就須要進行運維工做了，好比應用灰度發佈、升級回滾、服務器上下線、監控報警、安全補丁升級、網路配置、操做審計、生產環境引流等。

DevOps 的挑戰-如何下降 DevOps 實施代價？

當咱們深刻地看 DevOps 中所包含的這些工做項以後，其實可以感覺到若是想要作一個具備彈性的、高可靠的應用，須要考慮的點是很是多的，而這些在實施了 DevOps 以後就變成了同一個團隊在整個應用生命週期中須要考慮的事情了。這對於團隊心智和能力的要求是很是高的。

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

回顧了 DevOps 的挑戰以後，經過阿里內部和整個業界的實踐能夠看到，須要經過平臺和工具下降 DevOps 的複雜度。

2、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 應用。

3、Serverless DevOps

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

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

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

在應用層，則須要處理與應用相關的操做，好比代碼包的錯誤、配置錯誤、心跳異常的處理。下圖中藍色虛框中的部分能夠徹底由平臺負責，用戶能夠無感知；藍色實框則是平臺幫助用戶作了大量工做，可是仍是須要用戶感知和做出必定決策；紅色框則表明仍是須要用戶本身管理的部分。能夠看到，在容錯方面，平臺提供了很是強的能力，包括多AZ的容災能力、快速的彈性能力、內置的流控能力以及多層次、多維度的監控報警能力。藉助於這些能力，用戶管理基礎設施的複雜度就大大下降了。

敏捷的應用角度流程

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

自動化應用交付流水線

下圖展示的是自動化應用交付流水線，能夠看到在下面的每個環節都須要實現不少的功能，而不少都是重複性工做，所以須要作到基礎設施即代碼。

基礎設施即代碼

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

能夠爲模板傳入不一樣參數，能夠動態生成應用運行環境。

服務版本和灰度發佈

在函數計算裏面，應用有版本的概念，版本是一個不可變實體，所以杜絕了版本由於非預期的修改形成線上應用受損，阿里雲經過服務版本和灰度發佈避免了這樣的問題，客戶端訪問應用經過別名來訪問。

Serverless工做流

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

自動化應用交付流水線

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

日誌收集和查詢

在 Serverless 計算平臺之上，原生提供了不少的日誌收集和 Metric 收集能力，好比簡單日誌查詢以及高級日誌查詢，可以經過日誌方式爲用戶提供高級數據分析能力。

指標收集和可視化能力

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

當 Serverless 和 DevOps 結合以後，可以大大提高研發效能，一方面大大下降了開發團隊的心智負擔；另一方面，經過工具使得整個 DevOps 流水線可以實現高度自動化。

4、案例分享

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

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

做者介紹：

楊皓然（不瞋），Serverless 計算負責人，2010 年加入阿里雲，深度參與了阿里雲飛天分佈式系統研發和產品迭代的全過程。對大規模分佈式計算，大規模數據存儲和處理有很是深刻的理解。

原文連接本文爲阿里雲原創內容，未經容許不得轉載。