前言：如今，越來越多的大廠企業開始大規模使用Serverless，處于變革中的開發者，大多已從觀望狀態轉向嘗試階段，越來越多Serverless落地場景被解鎖。作為基礎研發底座，越來越多企業開始接受Serverless，并將其應用于業務實踐中。預計Serverless架構將引領云計算的下一個十年已成為共識。這個Serverless不僅適合與小場景，同樣適用與大廠秒殺，12306搶票的大業務場景。Serverless不是不需要Server，而是需要我們前端較少的關注服務器端，前端程序員可以好好研究一下。

目錄

?

培養自己的Serverless思維與認知

Serverless的使用價值及常見的架構模式

函數計算介紹及其應用

函數的測試與部署

Serverless容器服務及部署

Serverless應用引擎

常見的業務場景及經典案例

---

培養自己的Serverless思維與認知

以前很多開發者都是采用的單體架構，為了保證服務的穩定性，只需要維護一臺服務器及數據庫就可以啦，但是隨著業務的增長會面臨兩個問題，如果流量比較大，這個服務器可能頂不住這么大的流量，其次硬件啥的損壞也會導致整個系統癱瘓。

解決這個問題的辦法就是使用負載均衡，分擔各個服務器的壓力。然后整個系統就有一定的水平伸縮能力，如果一臺服務器壞了，其它的服務器也能正常運行，保證系統穩定運行。

隨著業務的進一步增長，增加大量的開發人員去處理這種單體應用，就會出現大量的沖突問題，這個就需要管理者進行人工協調，公司整體研發效率比較低，后臺大家想到一個好辦法就是把這個單體應用分為一個個獨立開發、測試及部署。每個環節都是獨立而又有一定的聯系，這個就是微服務的雛形。服務和服務之間采用API通信，這種微服務架構大大提升了研發人員的工作效率。

再到后來，估計大家都有所了解，如果從物理的角度思考這個問題就會發現分布式的一些困難與挑戰，比如大家使用分布式服務及框架，使用一些Redis緩存、配置服務ACM以及分布式追蹤系統等。這個微服務架構給運維也帶來不少的難題，感覺運維大哥都快成全能底層人才了，以前運維只需要維護一個應用，現在估計一個人都得看幾十個、幾百個應用。對應用分發、自動化彈性等能力有一定的要求。

現在很多人都談云計算，云架構，簡單理解就是這個架構長在“云”上就是云架構。有了應用分發的標準和生命周期的標準，云就能提供標準化的應用托管服務。在整個架構的演變的過程中，我們發現，研發運維人員希望用平臺系統的去管理機器，而不是人去管理這些個玩意。這可能就是server is less.

Serverless的使用價值及常見的架構模式

我們拋去這些抽象的概念，看一下這個Serverless的使用價值主要有以下幾點：

1.不用過多的關注服務器。

（Serverless平臺具備自動識別故障，移除故障的能力）

2.自動彈性。

（Serverless平臺自動及時穩定的實現自動彈性）

3.按照實際資源的消耗進行計費。

（Serverless模式下，按照實際消耗資源及使用存儲進行計費）

4.更少的代碼，更快的交付速度。

（Serverless提供成熟的代碼構建發布、版本切換等特性，交付速度更快）

Serverless由開發者實現的服務端邏輯運行在無狀態的計算容器中，它由事件觸發， 完全被第三方管理，其業務層面的狀態則被開發者使用的數據庫和存儲資源所記錄。Serverless涵蓋了很多技術，分為兩類：FaaS和BaaS。

FaaS（Function as a Service，函數即服務）

FaaS意在無須自行管理服務器系統或自己的服務器應用程序，即可直接運行后端代碼。其中所指的服務器應用程序，是該技術與容器和PaaS（平臺即服務）等其他現代化架構最大的差異。

FaaS可以取代一些服務處理服務器（可能是物理計算機，但絕對需要運行某種應用程序），這樣不僅不需要自行供應服務器，也不需要全時運行應用程序。

FaaS產品不要求必須使用特定框架或庫進行開發。在語言和環境方面，FaaS函數就是常規的應用程序。例如AWS Lambda的函數可以通過Javascript、Python以及任何JVM語言（Java、Clojure、Scala）等實現。然而Lambda函數也可以執行任何捆綁有所需部署構件的進程，因此可以使用任何語言，只要能編譯為Unix進程即可。FaaS函數在架構方面確實存在一定的局限，尤其是在狀態和執行時間方面。

在遷往FaaS的過程中，唯一需要修改的代碼是“主方法/啟動”代碼，其中可能需要刪除頂級消息處理程序的相關代碼（“消息監聽器接口”的實現），但這可能只需要更改方法簽名即可。在FaaS的世界中，代碼的其余所有部分（例如向數據庫執行寫入的代碼）無須任何變化。

相比傳統系統，部署方法會有較大變化 – 將代碼上傳至FaaS供應商，其他事情均可由供應商完成。目前這種方式通常意味著需要上傳代碼的全新定義（例如上傳zip或JAR文件），隨后調用一個專有API發起更新過程。

FaaS中的函數可以通過供應商定義的事件類型觸發。對于亞馬遜AWS，此類觸發事件可以包括S3（文件）更新、時間（計劃任務），以及加入消息總線的消息（例如Kinesis）。通常你的函數需要通過參數指定自己需要綁定到的事件源。

大部分供應商還允許函數作為對傳入Http請求的響應來觸發，通常這類請求來自某種該類型的API網關（例如AWS API網關、Webtask）。

BaaS（Backend as a Service，后端即服務）

BaaS（Backend as a Service，后端即服務）是指我們不再編寫或管理所有服務端組件，可以使用領域通用的遠程組件（而不是進程內的庫）來提供服務。理解BaaS，需要搞清楚它與PaaS的區別。

首先BaaS并非PaaS，它們的區別在于：PaaS需要參與應用的生命周期管理，BaaS則僅僅提供應用依賴的第三方服務。典型的PaaS平臺需要提供手段讓開發者部署和配置應用，例如自動將應用部署到Tomcat容器中，并管理應用的生命周期。BaaS不包含這些內容，BaaS只以API的方式提供應用依賴的后端服務，例如數據庫和對象存儲。BaaS可以是公共云服務商提供的，也可以是第三方廠商提供的。其次從功能上講，BaaS可以看作PaaS的一個子集，即提供第三方依賴組件的部分。

BaaS服務還允許我們依賴其他人已經實現的應用邏輯。對于這點，認證就是一個很好的例子。很多應用都要自己編寫實現注冊、登錄、密碼管理等邏輯的代碼，而對于不同的應用這些代碼往往大同小異。完全可以把這些重復性的工作提取出來，再做成外部服務，而這正是Auth0和Amazon Cognito等產品的目標。它們能實現全面的認證和用戶管理，開發團隊再也不用自己編寫或者管理實現這些功能的代碼。
?

函數計算介紹及其應用

從用戶角度，他需要做的只是編碼，然后把代碼上傳到函數計算中。上傳代碼就意味著應用部署。當有高并發請求涌入時，開發者也無需手動擴容，函數計算會根據請求量毫秒級自動擴容，彈性可靠地運行任務，并內置日志查詢、性能監控、報警等功能幫助開發者發現問題并定位問題。

函數計算是事件驅動的無服務器應用，事件驅動是說可以通過事件源自動觸發函數執行，比如當有對象上傳至OSS中時，自動觸發函數，對新上傳的圖片進行處理函數計算支持豐富的事件源類型，包括日志服務、對象存儲、表格存儲、消息服務、API網關、CDN等。

除了事件觸發外，也可以直接通過API/SDK直接調用函數。調用可以分為同步調用與異步調用，當請求到達函數計算后，函數計算會為請求分配執行環境，如果是異步調用，函數計算會將請求事件存入隊列中，等待消費。

函數的測試與部署

服務是函數計算資源管理的單位，同一個服務下有很多函數，這些函數共享服務的網絡 配置、權限配置、存儲配置、日志配置。 服務可以對應成一個“應用”，這個應用由很多函數共同組成，這些函數具有相同的訪 問權限、網絡配置，日志也記錄到相同的 logstore。這些函數本身的配置可以各不相同， 比如同一服務下有的函數內存是 3G，有的函數內存是 512M，有些函數用 Python 寫， 有些函數用 Node.js 寫。

開發流程

函數測試部分，Serverless稍微薄弱一點，軟肋，這個調試一般可以采用云調試、命令行工具、VSCode 插件、無工具調試等方式，具體怎么調試我就不一一說明了，有興趣的可以嘗試一下。 至于部署，比較簡單，我們可以使用在線部署、客戶端部署（通過命令行工具、通過 VSCode 插件）。命令行工具的 - h 指令真的很棒， 無論使用什么指令，我們都可以通過 - h 查看到使用方法。

Serverless容器服務及部署

Serverless Kubernetes 是以容器和 kubernetes 為基礎的 Serverless 服 務，它提供了一種簡單易用、極致彈性、最優成本和按需付費的 Kubernetes 容器服務， 其無需節點管理和運維，無需容量規劃，讓用戶更關注應用而非基礎設施的管理。我們可以把把 Serverless Kubernetes 簡稱為 ASK。

當下各大云廠商都推出了自己的 Serverless 容器服務，上圖為 Gartner 評估機構 整理的 Serverless 容器產品 Landscape，其中阿里云有 Serverless Kubernetes ASK 和 ECI；AWS 有 Fargate，基于 Fargate 有 EKS on Fargate 和 ECS on Fargate 兩種形態；Azure 有 ACI。另外 Gartner 也預測，到 2023 年，將有 70% 的 AI 應用以容器和 Serverless 方式運行。

在對 Serverless Kubernetes 的基礎概念有了充分了解之后，我們直接進入容器服務控制臺進行集群的創建。集群創建完成后，接下來我們部署一個無狀態的 nginx 應用，主要分成三步：

1.應用基本信息：名稱、POD 數量、標簽等；?

2.容器配置：鏡像、所需資源、容器端口、數據卷等；

3.高級配置：服務、路由、HPA、POD 標簽等

創建完成后，在路由中就可以看到服務對外暴露的訪問方式了。

Serverless應用引擎

主要的挑戰：

1.開發難度和入門門檻高，業務輕量化困難，不能平滑地遷移現有應用 ；

2.擔心被云廠商鎖定，如 FaaS 形態的 Serverless 產品，每個廠商都希望推出自己的 標準，缺乏開源的規范和開源的生態支持。相似的一幕曾經在容器領域上演，直到后來 Kubernetes 成為事實標準，Serverless 還在尋找自己的事實標準；

3.如何方便地本地開發調試、監控，和現有業務做深度整合。

低門檻，無需任何代碼改造就能直接使用的 Serverless PaaS 平臺（SAE），是企業在線業 務平滑上云的最佳選擇。

SAE 提供了成本更優、效率更高的應用托管方案。底層基于統一的 K8s 技術底座， 幫用戶屏蔽復雜的 IaaS 層和 K8s 集群運維，提供計算資源、彈性、隔離性等能力，用 戶只需關心應用實例的規格和實例數。 在應用層，除提供了生命周期管理、多發布策略外，還提供監控、日志、微服務治理能 力，解決應用可觀測性和治理需求。同時提供一鍵啟停、應用編排等高級能力，進一步提效 和降本。核心場景主要面向在線應用：微服務應用、Web 應用、多語言應用等。 在開發者工具方面，和 CI/CD 工具做了良好的集成，無論是 Jenkins 還是云效，都 能直接部署應用到 SAE，也可以通過 Cloud Toolkit 插件工具實現本地一鍵部署應用到 云端，可以說SAE覆蓋了應用上云的完整場景

常見的業務場景及經典案例

至于行業一些經典案例這個場景，這個簡單提一下 ，不過多介紹，有興趣的可以查閱項目資料。

比如：Serverless 應用引擎彈性伸縮實踐、基于函數計算實現 AI 推理、基于函數計算實現快速建站、基于函數計算快速搭建 Hexo 博客系統等等，然后再提一下相關的產品吧，比如函數計算（Function Compute）是一個事件驅動的全托管 Serverless 計算服務， 您無需管理服務器等基礎設施，只需編寫代碼并上傳，函數計算會為您準備好計算資源，并 以彈性、可靠的方式運行您的代碼。Serverless 應用引擎（Serverless App Engine，簡稱 SAE）實現 Serverless 架構 + 微服務架構的完美融合，真正按需使用、按量計費，節省閑置計算資源，同時免去 IaaS 運維，有效提升開發運維效率。彈性容器實例 ECI提供安全的 Serverless 容器 運行服務。您無需管理底層服務器，只需要提供打包好的 Docker 鏡像，即可運行容器， 并僅為容器實際運行消耗的資源付費。GPU 云服務器基于 GPU 應用的計算服務，多適用于 AI 深度學習、視頻處理、 科學計算、圖形可視化等應用場景等。

?

好啦，本期內容就分享到這里，我們下期見！

?

【本文正在參與"100%有獎|我的Serverless實戰"征稿活動】，活動地址：https://marketing.csdn.net/p/15940c87f66c68188cfe5228cf4a0c3f

?

總結

以上是生活随笔為你收集整理的我的Serverless实战——引领云计算的下一个十年的全部內容，希望文章能夠幫你解決所遇到的問題。

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