騰訊雲Serverless無伺服器架構最佳實踐經驗談

對於中小型互聯網創業公司來說，在技術人員緊缺的前提下，如果設計系統時需要考慮諸多例如 Web 應用伺服器如何配置、資料庫如何配置、消息服務中間件如何搭建等技術問題，那對於他們來說人員成本、系統維護成本會很高。

Serverless 架構應時而生，可能會大幅度改善上面提到的問題。2014 年 Serverless 架構進入大眾視線，業界普遍認為，Serverless 可大幅降低 IT 成本，將雲的費用減少 10%-90%，同時還能提高服務部署效率。

2017 年 6 月騰訊雲 + 未來深圳峰會上，騰訊雲技術專家 黃文俊在開發者論壇分享了騰訊 Serverless 無伺服器架構最佳實踐的技術內容，而且騰訊雲無伺服器雲函數（Serverless Cloud Function）也在 4 月份全國首發，正式推出了 Serverless 產品。InfoQ 有幸採訪到黃文俊，請他從 Serverless 架構、FaaS 和微服務等角度來解答一些讀者比較感興趣的話題，內容整理如下。

在整個業界，大家公認為 2014 年年底 AWS 推出 Lambda 產品即標誌著 Serverless 發展的開端。2016 年 Google Cloud Function 和微軟 Azure Function 這兩款產品的商業化，標誌著 Serverless 這個產品或者服務達到了成熟期。另外在開源領域，其實還有 OpenWhisk、OpenLambda、Serverless framework、Iron.io 等項目，這些開源項目發展的也都很迅速。騰訊雲在今年 4 月底正式推出了 FaaS 產品，即無服務雲函數。這個產品可以簡化用戶運維成本，只需要上傳代碼就可以開發運行，利用騰訊雲的全球基礎設施幫助客戶實現伸縮，降低用戶的計算成本。

Serverless 的誕生需要兩大因素：一是雲產品和整個生態環境的成熟；二是客戶提出了實際落地的需求。騰訊雲本身擁有豐富的雲產品，包括監控、日誌、存儲、資料庫、緩存、消息隊列、安全等足夠成熟的雲產品和服務，它們作為後端服務為雲函數提供了有力支撐。同時，騰訊雲越來越多的客戶提出了需要用雲函數產品來解決按需使用、節省費用、簡化管理、快速開發的問題。

傳統企業在這個過程中需求最強烈，因為他們的產品形態和應用場景更需要通過無服務技術來解決問題：一是定時任務的數據採集、收集、匯聚、計算，實時數據的收集、匯聚、計算和展示，再就是多媒體和圖片的轉換、優化、美化、分析、抽取，還有部分客戶使用雲函數進行後端服務或者後端業務的封裝和開發，這都是比較典型的無服務計算的應用場景。

正是在這種需求的強烈推動下，騰訊雲推出了 Serverless 服務。

其實很多初創團隊和傳統企業為了減少運維成本和人力成本，都會採用第三方的 CI/CD 服務，而 Serverless 服務在一定程度上也是可以解決初創團隊在這方面的需求的。

2014 年 Serverless 發展到現在，這三年裡騰訊雲做了哪些研發準備，經歷了哪些測試階段？效果如何呢？黃文俊說到，研發準備階段可以分為兩方面：一是底層，二是生態。

從底層來說，需要對資源調度能力不斷提升，原有的資源調度粒度較粗，需要提升到更細粒度的資源控制能力；再就是需要做到對用戶或者租戶更好的隔離，確保函數或數據安全；另外對於屏蔽硬體差異、計算能力動態校正和運行調度平台優化上都做了很多基礎能力的提升。從生態上來說，這幾年，騰訊雲推出了各種雲化服務和產品，像對象存儲、雲資料庫、分散式資料庫、雲緩存和消息隊列等，在一定程度上也是對 Serverless 產品的推出打下了基礎。

Serverless 和原有的雲伺服器相比，它的最明顯特點就是調度粒度已經細到了函數級別。而且，Serverless 天生具有事件觸發的屬性，對於 web 服務來說，原有的雲伺服器，在沒有客戶訪問的時候也需要維持最低的資源消耗；在遇到高併發量、高請求量的時候，則需要彈性伸縮；而 Serverless 的彈性完全是取決於用戶的請求數，沒有用戶請求的時候沒有函數運行，在有高峰來臨的時候，相應的彈性也完全適配用戶的訪問。這個彈性併發數在理論上是沒有最高峰值的，而從實際出發，騰訊云為了防止用戶超費用、超流量的情況，而做了一些安全策略，有相應的應用防護、流量監控、併發流控的策略。

Serverless 可以說是一種流程、一種工具或是一種架構，而 FaaS 屬於 Serverless 的子集。Serverless 包含了 FaaS、BaaS 這兩個概念，FaaS 即 Function as a Service 函數即服務，BaaS 即 Backend as a Service 後端即服務。FaaS 是雲化的函數，把函數放到雲端，通過雲進行函數級別的調度、彈性；BaaS 指的是各種雲化的產品和服務，雲存儲、雲資料庫、雲監控、雲告警，都可以囊括在 BaaS 裡面。而 PaaS，更多考慮的是提供一個通用平台，把平台提供給用戶使用，用戶自己去完成計算資源的分配、調度、擴縮容等工作。

黃文俊在這裡進一步介紹了 FaaS，實際上這個函數是用戶自身的一段業務代碼，這段業務代碼由事件觸發，而支持的事件有很多種，最簡單的，例如和對象存儲對接之後，某個數據文件的上傳即可觸發函數執行，對文件進行分析，分析之後的結果，可以再次寫到對象存儲中或者雲資料庫里。發事件來源有很多種，包括對象存儲裡面的各種事件、前端 HTTP 請求、消息隊列里的消息，甚至是監控中某個事件告警，均可以用來觸發函數的執行。總的來說，FaaS 在雲里就像粘合劑，把各個雲產品或者服務連接在一起，形成一個鏈條，或類似 IFTTT 的服務。

FaaS 的誕生場景也是為了滿足客戶不同的需求，從整個雲的發展歷史來看，最開始的物理機，完全沒有彈性能力，或者彈性周期很長，要經歷採購、到貨、部署上線；再到後來的雲伺服器，實現了粗粒度的彈性，可以立即申請，立即使用，不再使用時可以立即釋放；到容器時，彈性能力就更細了，每個運行的容器都可以彈性伸縮，跨雲調度；而到了 Serverless，彈性的能力到了函數級別，細到執行的某段代碼都可以進行彈性；所以整個雲的發展，就是計算能力的粒度細化，同時彈性能力的增強，因此可以說 FaaS 是雲發展的必經之路。

有人說 Serverless 並不等於沒有運維，Serverless 接下來在發展過程中肯定會給運維帶來衝擊，對於這一點，黃文俊則解釋道，Serverless 也需要運維，只不過不像維護傳統的伺服器或者自己安裝的資料庫那樣去運維。

黃文俊覺得 Serverless 的運維需要在以下四點有所提升，一是雲化運維，要充分運用雲上的各種運維產品，包括雲日誌、監控、告警、簡訊平台的對接，甚至微信的消息，還可以運用雲函數本身來進行運維工作，利用這些工具來搭建和使用運維平台。二是業務運維，不僅要做普通的運維工作，還要從業務角度來去進行更深入的查看，分析業務瓶頸。三是充分利用原有能力的組合，尤其是在新業務開發過程中，如何通過原有的函數組合和模塊組合實現功能。四是業務函數或者模塊如何進行複雜調用的跟蹤和分析。對於這種雲化的環境，DevOps 優勢體現需要更明顯，開發和運維都要 DevOps，開發和運維兩者需要結合得更緊密，兩者作為一個團隊來負責一個產品或服務的生命周期，兩者需要通力合作，對整個產品或服務完整的生命周期持續跟蹤、改進。

講了這麼多內容，也許有人會問，這是減輕了運維人員工作量還是增加運維人員的工作量了呢？其實這並不是減輕或增加工作量的問題，黃文俊說，要從全新的角度看待運維，而不是做好傳統的伺服器或資料庫運維工作就行，而是需要提升自己，從業務層面甚至是決策層面來看待平台和整個業務。

微服務和 Serverless 是比較切合的，都會強調系統的解耦，未來將微服務遷移到 Serverless 有可能是順理成章或者很容易的事情，對於這一點，黃文俊認為，微服務也是最近兩年才開始火起來的，Serverless 和微服務天生都是服務屬性。從微服務到 Serverless 的遷移過程中，還需要對微服務模塊更細的拆解，拆解到函數級別，而每個函數就是最簡功能，有可能就是微服務里的某個功能點。在拆解過程中，除了服務拆解、功能拆解、函數拆解，對開發者來說，還需要提升其他方面的能力，包括開發管理、上線管理、CI/CD 流程，上線之後的版本管理，調用跟蹤和 bug 跟蹤等。另外，在轉移到 Serverless 上時還需要考慮服務的安全性，包括應用安全，數據安全。騰訊雲在這方面會不斷的提升產品能力，協助客戶轉移到 Serverless 之後能更容易、更安全，更方便的實現業務或功能。

目前，已經有些公司嘗試用 Serverless，甚至把 Serverless 服務用於生產環境裡面，還專門成立了 Serverless 部門，這是不是就代表著 Serverless 的未來更受歡迎？對於這一點，黃文俊也是認可的。實際上，Serverless 作為一套細粒度的標準化計算框架，代表著一種全新的計算提供能力，類似原有的雲伺服器、容器，都是以計算能力的形式提供，Serverless 未來會成為和雲伺服器、容器一樣成為計算提供方式的一種，並且會持續演進。目前來看，Serverless 還處在發展早期，各個雲廠家都有其各自的產品形態，在業界還沒有形成 Serverless 的統一標準，因此這個行業還會持續發展和演進。

至於這個標準的建立，黃文俊說，不可能是某一個公司獨立掌控，而是需要社區共同參與討論、碰撞才會逐漸形成一些標準，而且這個標準對廣大開發者是有好處的，可以幫助開發者脫離行業或者供應商的業務綁定，讓函數在一定標準下任意在雲端遷移，同時這種標準的推出也能夠促使更多開發者轉移到 Serverless 上來。

如果時機成熟的話，騰訊雲也會回報社區，開源更多的計算介面標準或者計算實現方式，在 Serverless 上做一定的開源探索和嘗試。

初創團隊使用 Serverless 需要從兩個角度來評估，業務架構角度和開發運維角度。

業務架構角度包含三點：

• 一是微服務化，首先進行業務拆分，然後服務拆分，拆分之後進行雲函數的設計。

• 二是提升組裝能力，拆分之後再進行組裝，能夠通過各個服務模塊、雲函數、後端服務例如雲資料庫、雲緩存、對象存儲等，組裝出新的業務。

• 三是利用 Serverless，業務快速上線和快速迭代，加快反饋速度，加快業務調整速度。

從開發和運維的角度來說，DevOps 是最優的發展方向：

• 一是做好 CI/CD，配置管理，實現 X as Code。

• 二是運維方面要進行雲集成和雲能力的探索，充分利用雲監控、雲日誌、告警事件來提升運維能力。

• 三是提升整個團隊的跨界思考能力，開發在最初寫代碼的時候就要考慮到維護性、安全性，資源利用和費用支出；運維人員要從業務場景、業務瓶頸、業務配置角度提升運維能力。

對於初創團隊來說一開始推行微服務架構是最合適的，因為他們沒有歷史包袱，能夠直接利用雲函數和後端服務計算，直接打造整個雲化業務，充分利用雲計算能力，來節省寶貴人力，加快業務發展，快速迭代、快速反饋。

作者介紹

黃文俊，騰訊雲技術專家。擁有多年企業級系統開發和架構工作經驗，研究方向為企業級存儲、容器平台、雲計算；關注於微服務設計思考，開發流程優化，容器技術應用等領域。

智能化運維、Serverless、DevOps......CNUTCon 全球運維技術大會將於 9 月上海舉辦，12 位大牛聯合出品，揭秘最前沿運維技術，更有阿里、百度、騰訊、京東、攜程、搜狗等公司大牛分享他們在最新運維實踐過程中遇到的坑與經驗，推薦學習！點擊「閱讀原文「了解更多精彩！

細說雲計算

「細說雲計算」是InfoQ旗下關注云計算技術的垂直社群，投稿請發郵件到[email protected]，註明「細說雲計算投稿」即可。