熱度3年猛增20倍，Serverless＆雲開發的技術架構全解析

作為一個不斷發展的新興技術， Serverless 熱度的制高點已然到來。或許，Google Trends 所顯示的 3 年猛增 20 倍的「 Serverless 」 搜索量，可以佐證 Serverless 在整個行業中的火爆程度。

不僅如此，據 KBV 研究公司新發布的《全球 Serverless 架構市場》及 RightScale 雲服務狀況報告 2018 版顯示，全球 Serverless 架構的市場滲透率已超 75%，市場規模預計到 2024 年將達到 140 億美元，並將在預測期內以 23.4% 的年複合增長率增長。

作為一種雲原生的架構，Serverless 與 BaaS、FaaS 之間有何「愛恨情仇」？冤家路窄卻能完美解決前後端聯調等開發痛點，解決方案又是如何？相較於傳統開發模式，基於「無服務開發」理念的小程序·雲開發模式又「新」在何處，有何利好？下面我們從 Serverless 的架構演進來具體分析。

Serverless 架構詳解

在過去的十幾年裡 (2006 年誕生 IaaS)，雲計算的進程從物理機演進到 IaaS，再到 PaaS，已經將應用程序的運行環境和通用組件，越來越多地交給雲服務商。Serverless 進一步將主機管理、操作系統管理、資源分配、擴展、甚至應用邏輯的整個組件，都交付給雲服務商，在成本和運營效率方面獲得了顯著的提升。

作為一種雲原生的架構，Serverless 使得開發者在開發應用時不需部署、配置和管理傳統伺服器，轉而依賴於第三方服務，將代碼託管到雲端平台。目前，業界並沒有給出明確的定義，而是把其分成兩種類型，分別為「Backend as a Service」 和 「Functions as a Service」。換一種開發者更熟知的表達方式看，也就是後端即服務（BaaS）和功能即服務（FaaS）。

Serverless=BaaS FaaS？聽著很高深，其實很好理解。

BaaS 是將應用開發中所有後端的需求，通過統一的雲平台來解決，讓開發者無需再編寫和管理所有服務端組件。BaaS 使開發者無需編寫完整的邏輯組件，但需要將應用程序與雲服務商提供的特定介面和模型集成。

而 FaaS 是把函數作為一個線上服務、遠程計算服務，可以通過 API、郵件、IoT 等執行。FaaS 是一種構建和部署服務端軟體的新方式，面向部署單個的函數或者操作，是一種新的運行代碼的託管環境。FaaS 本質上是事件驅動的，優化了函數運行時的資源使用，它的目標是在運行的時候才消費資源。

從表面上看，BaaS 和 FaaS 是兩碼事——前者是把應用中的各個部分完全外包出去，後者是一種新的運行代碼的託管環境。那麼，為什麼要把它們都劃歸為 Serverless 呢？關鍵在於，它們都不需要開發者管理自己的伺服器主機或者伺服器進程。Serverless 並非是無伺服器，它仍然涉及伺服器，只是這個伺服器在雲上。實際上，這是一種使用服務的新方法，在很多情況下，它比自己去買伺服器更為划算，而且加快了項目上線的時間，降低了開發、維護、擴展的複雜性。

Serverless 技術的崛起不但讓開發者無需過多考慮伺服器問題，並且完美地解決前後端聯調等開發痛點，作為一種全新的架構，Serverless 可謂是雲計算髮展演化的必然結果。

傳統開發痛點解析及解法

「Serverless 所提供的介面，簡化了雲計算的編程，其代表了程序員生產力的又一次的變革，一如編程語言從彙編時代演變為高級語言時代。」 2019 年，伯克利在《將雲中的編程變得簡單：伯克利視角下的 Serverless 計算》中的犀利語句也論斷了 Serverless 雲時代主宰般的地位。

此前，雲計算服務並沒有從根本上改變設計應用程序的方式。

例如，當使用 Docker 這樣的工具時，開發者在應用程序周圍放置了一個更薄的「盒子」，但它仍然是一個盒子，邏輯架構不會發生顯著的變化。再比如，在雲中託管 MySQL 實例時，開發者仍需考慮工作負載所需的虛擬機資源，以及故障切換等問題。

現如今，這種情況在 Serverless 面前，迎刃而解。甚至在前後端分離與聯調所產生的一系列權責、溝通與調試等開發痛點上，Serverless 也能從以下 5 個維度完美解決：

按需計費。不同於 IaaS/PaaS 預先分配計算資源的計費方式，Serverless 按請求次數及運行時間計費，一方面可以最大程度利用資源，另一方面真正的按需計費可以降低開發者的資源成本，開發者只需要為函數實際執行所消耗的資源付費，即用即付；

高效率。在 Serverless 的架構中，用戶操作的是服務化的組件，如存儲服務、授權服務等，縮短了開發周期，降低了開發難度，且避免了由基礎設施產生的延遲；

綠色計算。在 Serverless 架構下，服務商提供細力度的計算能力，最大限度地滿足開發的實時需求，資源利用率將大幅度提升；

高擴展。Serverless 架構的橫向擴展是完全自動、有彈性的，且由服務提供者所管理；

無需運維。運維的發展經歷了人肉運維、自動化運維、DevOps 和 AIOps 等階段，而 Serverless 帶來一種新的運維模式。在這種模式下，開發者只需要關心業務本身，無需運維。

正因開發痛點重重，在想要突破傳統開發模式，探索新型開發方案的過程中，開發者藉助 Serverless 技術架構，基於「無服務開發」理念創造出了一種新型開發模式——小程序·雲開發。

以雲調用功能為例，只要在小程序端觸發雲函數，便將經過微信自動鑒權直接調用，如數據分析、客服消息，插件管理等開放 API 介面。這些開放介面通過系統配置、將大幅提升效率、優化體驗、降低運營成本。

那麼，在用戶量峰值過大或黑客攻擊的情況下，小程序·雲開發是如何保證後台服務性能與安全的呢？首先，小程序·雲開發沒有傳統的後台伺服器，也就沒有被 DDoS 的目標，這是從產品形態上保障用戶業務安全；其次，小程序·雲開發之間的環境是互相隔離的，即便發生攻擊，從架構上將不會相互影響；再次，小程序·雲開發服務構建在騰訊雲基礎設施之上，天然擁有快速擴容和安全防護的能力。

在用戶量突增時，小程序·雲開發的開發人員會立即通過響應的監控及告警發現流量的變化，然後確認是否需要擴容。騰訊雲基礎運維能力也保證了開發者擁有能夠快速擴充服務的能力，以避免對用戶的服務造成影響。

而在突發黑客大流量攻擊（如 DDoS）時，小程序·雲開發的開發及運維人員也會先確認遭受攻擊的真實性，當得到確認後會第一時間與騰訊雲系統運維、騰訊安全中心確認，確保已經對小程序·雲開發的伺服器加強防護，以保護系統服務安全。此外，小程序·雲開發控制台也有響應的流量實時數據告知開發者，開發者可以據此了解服務的流量數據，如有異常可以聯繫小程序·雲開發官方。

小程序·雲開發架構詳解

雲開發是一種 BaaS，在引入了 Serverless 技術架構的同時，讓開發者在構建應用的過程中無需關注計算資源的獲取和運維。在應用端，開發者可以直接使用官方提供的介面。在雲函數端，開發者可以直接使用官方提供的 Node SDK，來操作雲資源。

目前小程序·雲開發一共提供了三大基礎能力，分別是雲函數、資料庫、文檔存儲。簡而言之，就是提供了存文件、存數據和運行業務邏輯的能力。

其中，雲函數能力來源於騰訊雲的「無伺服器雲函數 SCF」 。通過與 SCF 的深度結合應用，可以形成一套比較完整的 Serverless 解決方案。

使用 SCF，可以讓開發者更簡單的管理服務端代碼，無需管理或配置伺服器，只需將代碼上傳至 SCF，就可以自動運行；

可以更高效的利用資源，按照執行時間和調用次數收費，代碼不運行時不產生費用；

可以快速建立持續擴展的能力，每個雲函數互不影響，並行處理不同的邏輯。

此外，小程序·雲開發的資料庫能力則是基於騰訊雲的 NoSQL 資料庫服務，併兼容 MongoDB 協議。每個資料庫資源都會分配一個實例 ID，每一個實例都是至少一主一從的副本集或者包含多個副本集的分片集群，資料庫反向代理轉發請求去最優副本集。

同樣，小程序·雲開發藉助騰訊雲提供的面向非結構化數據——對象存儲（Cloud Object Storage，COS）支持文檔存儲服務的文件上傳、下載和刪除等功能，可以幫助開發者處理文件相關的業務邏輯。所有上傳的文件都會有一個全網唯一的文件 ID，使用文件 ID 可以在 image、audio 等小程序組件中直接訪問文件。通過小程序·雲開發上傳的文件在小程序內默認允許訪問，不需要配置 CDN 域名白名單。

2019 年 1 月，騰訊雲宣布推出總價值超過 10 億元的「小程序·雲開發」資源扶持計劃，對超過一百萬個小程序開發者提供免費資源扶持，全面助力開發者打造優秀小程序。

小程序·雲開發將持續豐富 SDK 能力，釋放騰訊的技術價值，逐漸支持多種開發語言，讓開發更便捷。不僅如此，騰訊雲還會加快豐富雲開發的各類行業解決方案，滿足企業業務不同應用場景需求 。

未來，新的技術層出不窮，但是要知道技術始終是為人服務的。不解決人的問題，技術無法成長壯大。將開發者的精力解放出來，讓他們投入到業務邏輯等更具價值的工作中，從根本上賦能技術發展，才是推動行業」車輪「不斷向前駛進的源動力。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！