入門 Serverless：如何實作 Hello World？

近年來，IT 技術的更新迭代速度非常快，每個時間點都有典型的代表名詞以及概念，就目前而言，人工智能領域中的機器學習、深度學習、強化學習等名詞和概念就非常熱，同時區塊鏈、物聯網等技術發展也是例外火熱，

在云計算領域，有這樣一個技術被眾多云廠商認為是“風口專案”，甚至可以顛覆現有云計算中的某些格局，為此包括 AWS、谷歌以及騰訊云、阿里云等在內的云廠商，都為此投入了重大人力以及精力進行相關產品建設，它就是 Serverless 技術，

自 2006 年 8 月 9 日，Google 首席執行官埃里克·施密特（Eric Schmidt）在搜索引擎大會（SESSanJose2006）首次提出“云計算”（Cloud Computing）的概念之后，云計算的發展可以用日新月異這個詞來形容，

在短短十幾年的發展程序中，云計算也從 IaaS 到 PaaS，再到 SaaS，逐漸將去服務器化趨勢表現得愈發明顯，就目前的情況來看，全球各大 IT 企業，都在緊羅密布的部署自己的“云事業”，尤其是 Serverless 相關概念的推廣和產品的推出以及專案的落地，包括 AWS、Google Cloud、Azure、阿里云、騰訊云、華為云等在內的云廠商，無一例外的向 Serverless 進軍，或許云計算下一個階段，可能就是 BaaS+FaaS+Others，即 Serverless，當然也可能這個階段就是！

什么是 Serverless

Serverless 可以說是一種架構，一種云計算發展的產物，至于具體說什么是 Serverless，可能沒有誰無法給一個明確的概念，如果非要給出一個概念，那或許可以參考 Martin Fowler 在《Serverless Architectures》中對 Serverless 這樣定義：

Serverless was first used to describe applications that significantly or fully incorporate third-party, cloud-hosted applications and services, to manage server-side logic and state. These are typically “rich client” applications—think single-page web apps, or mobile apps—that use the vast ecosystem of cloud-accessible databases (e.g., Parse, Firebase), authentication services(e.g., Auth0, AWS Cognito), and so on. These types of services have been previously described as “(Mobile) Backend as a service", and I use “BaaS” as shorthand in the rest of this article. Serverless can also mean applications where server-side logic is still written by the application developer, but, unlike traditional architectures, it’s run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a third party. One way to think of this is “Functions as a Service” or “FaaS”.(Note: The original source for this name—a tweet by @marak—isno longer publicly available.) AWS Lambda is one of the most popular implementations of a Functions-as-a-Service platform at present, but there are many others, too.

當然這個描述貌似很長，讀起來也有點干澀難懂，不過，大家可以簡單粗暴的把 Serverless 認為是 BaaS + FaaS，如果用一張圖來表示上面的描述，可以是：

說到這里，不同的人可能已經對 Serverless 有了不同的勾勒，但是可能普遍還有一個疑問，我怎么用 Serverless？向云服務器上傳我專案？還是像一種框架，用來寫代碼？用了它我可以得到什么？性能的提升？效率的提高？成本的降低？

首先，我們以一個常見的 Web 服務為例：

在這個圖中，服務器中可能涉及路由規則、鑒權邏輯以及其他各類復雜的業務代碼，同時，開發團隊要付出很大的精力在這個服務器的運維上面，包括客戶量突然增多時是否需要擴容服務器；服務器上的腳本，業務代碼等是否還在健康運行；是否有黑客在不斷地對服務器發起攻擊；也就是說，當我們把這個思路切換到 Serverless 的邏輯之后，上圖就變成了這樣：

可以認為，當客戶端和資料庫未發生變化的前提下，服務器變化巨大，之前需要開發團隊維護的路由模塊以及鑒權模塊都將接入服務商提供的 API 網關系統以及鑒權系統，開發團隊無須再維護這兩部分的業務代碼，只需要持續維護相關規則即可，同時業務代碼也被拆分成了函式粒度，不同函式表示不同的功能，同時，在這個結構下，我們已經看不到服務器的存在，是因為 Serverless 的目的是讓使用者只關注自己的業務邏輯即可，所以一部分安全問題、資源調度問題（例如用戶量暴增、如何實作自動擴容等）全都交給云廠商負責，并且相對于傳統專案而言，傳統專案無論是否有用戶訪問，服務都在運行中，都是有成本支出，而 Serverless 而言，只有在用戶發起請求時，函式才會被激活并且執行，按量收費，相對來說，可以在有流量的時候才有支持，沒有流量的時候就沒有支出，成本會進一步降低，

通過分析和描述，不難看出，Serverless 架構相對于傳統的開發模式有什么區別，但是問題來了，很多作業都不需要我們做了，都交給云廠商做了，那么我們做什么？

使用 Serverless 架構，用戶不需要自己維護服務器，也不需要自己操心服務器的各種性能指標和資源利用率，而是可以讓用戶付出更多的時間和精力去關心應用程式本身的狀態和邏輯，同時 Serverless 應用本身的部署十分容易，我們只要上傳基本的代碼，例如 Python 程式只需要上傳其邏輯與依賴包，C/C++、Go 等語言只需上傳其二進制檔案，Java 只需要上傳其 Jar 包等即可，同時不需使用 Puppet、Chef、Ansible 或 Docker 來進行配置管理，大大降低了運維成本，對于運維來說，Serverless 架構也不再需要監控底層的資料，例如不再需要監控磁盤使用量、CPU 使用率等，可以更加專注的將監控目光放到監控應用程式本身的度量，同時在 Serverless 架構上，運維人員的作業角色會有所轉變，部署將變得更加自動化，監控將更加面向應用程式本身，

總而言之，Serverless 是在傳統容器技術和服務網格上發展起來，它更多指的是后端服務與函式服務的結合，對于開發者而言，會更多關注在函式服務商，讓使用者只關注自己的業務邏輯即可，Serverless 是云計算發展到一定階段的必然產物，云計算作為貧訓科技，發展到最后一定是綠色科技（最大程度利用資源，減少空閑資源浪費），大眾科技（成本低，包括學習成本及使用成本）的產品，而 Serverless 將很好的詮釋這些！Serverless 架構被稱為是“真正實作了當初云計算的目標”，這種說法雖然有些夸張，但是也從另一方面表現出了大家對 Serverless 架構的期盼和信心，自 2012 年被提出至今，Serverless 架構也是經歷了 7 年多的時間，正在逐漸的走向成熟，

入門 Serverless

說起 Serverless，就不得不說 BaaS 和 FaaS，BaaS 服務更多是云廠商給我們提供 / 維護，所以開發者精力可以更多放在 FaaS 層面，或者說是在函式計算層面，

接下來，我們來體驗一下 Serverless，以騰訊云為例，我們通過騰訊云控制臺，選擇 Serverless 分類下的云函式：

接下來就可以看到 Serverless 中的一部分：函式計算部分，此時，我們可以新建一個函式，進行基本的測驗，體驗一下 Serverless 下的 Hello World 和我們傳統的 Hello World 有什么不同，

• 新建函式：
  
• 選擇運行時（就是我們要用的編程語言）：

• 進行代碼的撰寫：

• 點擊完成，即可保存代碼
• 進行代碼測驗：

• 可以看到測驗結果：

至此，我們完成了一個函式的基本撰寫，但是仔細想一下：貌似和一些在線編程工具差不多，可以在線撰寫代碼、運行，BaaS 體現在了哪里？體現在提供了運行環境？除了寫了一個 hello world，我還能干什么？

接下來，我們進行觸發器的體驗，所謂的觸發器，是指我們的函式一般情況下都是 " 休息 " 的，只有在一個 " 東西觸碰它 "，“激活它”，才會起來干活，剛剛我們是怎么讓函式 " 起來作業的 "？是通過螢屏上的 " 測驗按鈕 "，所以說這也算是一個觸發器，那么除了這個觸發器，還有那些？

可以看到，目前騰訊云提供給我們的觸發器包括：

• 定時觸發器（顧名思義，就是定好時間進行函式的觸發，例如說每天幾點觸發一次，或者說每隔多久觸發一次，這類操作適合我們做定時任務，例如進行資料采集 / 資料聚合，訊息推送等，）
• COS 觸發器 我們可能會將檔案存盤到檔案系統，在傳統的云主機中，我們可以存到機器本身，但是 Serverless 架構下，由于函式是無狀態的，所以我們不能做持久化，那么就需要一個外部的媒體，" 物件存盤 " 就是我們常用的持久化檔案產品，可以將一些檔案存盤在上面，例如圖片、檔案、可執行程式…，同時也可以通過存入到上面一個檔案，來觸發我們的函式，例如當有圖片上傳到物件存盤中，函式計算會下載這個圖片，進行圖片壓縮和水印等處理，
• CMQ 主題訂閱觸發器 CMQ 主題訂閱是指，當我們 CMQ 中有佇列存在，就可以將內容發給云函式，云函式來進行消費處理，
• Ckafka 觸發 與上面說的 CMQ 主題訂閱觸發器基本一樣，只不過這個是 Ckafka，當 Ckafka 中訊息出現（可以是每條觸發也可以是最多多少條觸發），會讓函式 " 起來作業 "，進行資料處理、完成消費，
• API 網關觸發器 是和函式關系非常緊密的一個服務，通過 API 網關觸發，可以讓函式具備被訪問能力，什么叫做被訪問呢？就是說可以通過瀏覽器 / 介面直接使用，所以 API 網關觸發器和云函式結合通常可以作網站、后臺服務等，

此時，我們可以建立一個 API 網關觸發器，看看函式和 API 網關結合所帶來的有趣碰撞：

初探 API 網關與函式

我們新建一個 API 網關服務：

創建完成，系統會給我們分配一個地址：

通過瀏覽器打開這個地址：

這時，我們就成功的搭建了一個 Web 服務，后臺會展示Hello World，如果是傳統開發條件下，做一個這樣的頁面，需要做哪些作業？

• 使用框架開發一個Hello World
• 購買服務器，并配置服務器的環境
• 將本地開發好的專案上傳到服務器中
• 購買域名 / 使用服務器 IP，系結我們的專案

這個程序可能涉及到的有常用的 Web 框架（例如 Django，Spring，Express…），服務器的軟體（Nginx，Apache，Tomcat…）等等，甚至我們還要考慮網站的流量有多大，買多大記憶體的機器，啟動多少行程，多少執行緒，還要想辦法對服務器進行各種優化，

但我們剛剛做的操作只有：

• 建立函式
• 增加 API 網關觸發器

其余的一切操作都不用我們關心，我們可以將更多的精力放在了 "Coding"，

用函式和 API 網關做點有趣的

在生產生活中，我們經常需要獲取 IP 地址進行某些作業，例如我之前做了一個網站，這個網站的用戶簽名體系包括了用戶的 IP，而客戶端想獲得用戶 IP 是一個比較復雜的程序，一般情況下是需要通過訪問服務端的獲取 IP 介面來獲得客戶端對應的 IP 地址，那么通過函式計算和 API 網關，我們應該怎么做呢？

剛才說到了觸發器，每種觸發器都會和函式有一個規約，我給你一種什么樣的格式資料，通過函式下面的測驗模板可以看到：

通過這里，可以看到 API 網關和函式約定的一個結構：

{
  "requestContext": {
    "serviceId": "service-f94sy04v",
    "path": "/test/{path}",
    "httpMethod": "POST",
    "requestId": "c6af9ac6-7b61-11e6-9a41-93e8deadbeef",
    "identity": {
      "secretId": "abdcdxxxxxxxsdfs"
    },
    "sourceIp": "10.0.2.14",
    "stage": "release"
  },
  "headers": {
    "Accept-Language": "en-US,en,cn",
    "Accept": "text/html,application/xml,application/json",
    "Host": "service-3ei3tii4-251000691.ap-guangzhou.apigateway.myqloud.com",
    "User-Agent": "User Agent String"
  },
  "body": "{\"test\":\"body\"}",
  "pathParameters": {
    "path": "value"
  },
  "queryStringParameters": {
    "foo": "bar"
  },
  "headerParameters":{
    "Refer": "10.0.2.14"
  },
  "stageVariables": {
    "stage": "release"
  },
  "path": "/test/value",
  "queryString": {
    "foo" : "bar",
    "bob" : "alice"
  },
  "httpMethod": "POST"
}

同時，函式會將這個結構作為入參之一傳遞給開發人員，例如騰訊云將這個引數命名為event，也就是說，開發者可以通過函式入口的event引數進行 API 網關相關內容的決議，

那么什么是函式的入口呢？

入口函式實際上就是用戶代碼中的檔案名 + 方法名，這里面默認設定就是 index 檔案中的 main_handler 方法，可以看到 main_handler 方法，確實有一個引數是 event，這個引數就是觸發器傳遞過來的資料結構，另外一個 context 引數是背景關系，用戶對背景關系內容的處理，例如上游資源產生的 RequestId、環境資訊、密鑰資訊等，

通過上面的資料介面，可以看到在 requestContext 中 sourceIp，是用戶的 IP 地址，那么我們是否就可以把這個 IP 直接回傳給用戶，實作 IP 查詢功能呢？

# -*- coding: utf8 -*-
import json
def main_handler(event, context):
    return({"ip": event['requestContext']['sourceIp']})

通過 4 行代碼撰寫之后，我們系結 API 網關，并且通過瀏覽器訪問可以看到：

是的，這樣一個功能，只需要 4 行代碼就可以搞定，

再說說 Serverless

剛剛我們已經入門了云函式，對云函式也有了一個初步的了解了，那么接下來，我們說說 Serverless 架構有哪些優點和缺點，

優點

• 彈性伸縮

傳統意義上，一臺服務器能接受多大的流量，峰值是多少，是需要我們進行評估的，同時后期也要不斷維護和更新資料的，但是在 Serverless 架構下，用戶不需要考慮這個問題，云廠商將會為用戶實作彈性伸縮的能力，當平臺接收到第一個觸發函式的事件時，將啟動容器來運行你的代碼，如果此時收到了新的事件，而第一個容器仍在處理上一個事件，平臺將啟動第二個代碼實體來處理第二個事件，SCF 的這種自動零管理水平縮放，將持續到有足夠的代碼實體來處理所有的作業負載，當并發出現的時候，云廠商會啟動多個容器來應對 " 流量洪峰 "，相對于傳統服務器來說，在這一層面上，Serverless 架構或者說云函式真的是很方便了，

• 按量付費

按量付費是 Serverless 架構的一個優點，傳統服務器，無論是否有流量，我們都要進行成本支出，并且服務器配置還要按照某個時間段最大流量來進行配置，所以支出情況實際上是不合理的，但是函式計算實際上是按量收費，而且相對來說價格很低，尤其對不同時間段資源消耗峰值低谷有較大差距的專案而言，是真的很棒，

缺點

• 冷啟動

說到 Serverless 架構的缺點就不得不說冷啟動問題，冷啟動無論是 AWS 還是 Google 還是騰訊云、阿里云，都是普遍存在的，一般情況下來說，冷啟動就是函式在 " 睡覺 "，突然有一個觸發的程序，后臺拉起容器、下載代碼、啟動行程、觸發入口方法的一個程序，所以一般情況下，容器在首次啟動的時候都會有冷啟動，通過上圖可以看到，函式冷啟動可能達到幾百毫秒甚至數秒，這對一些業務可能是致命打擊，當然各個云廠商也在努力通過各種策略、方案降低冷啟動率，

• 除錯困難

云函式的另一個缺點是除錯困難，由于它提供給我們的是一個函式運行的容器，而且很多基本業務又是和廠商系結的，這就導致我們除錯困難，例如，我們要除錯一個函式，本來可以通過模擬一些觸發器情況進行除錯，但是，如果函式中涉及到了一些內網資源，例如與 redis 相關，只能通過 vpc 訪問的資源，那么這個時候進行本地除錯困難度就會成倍增加，在線除錯又可能因為日志輸出過慢，導致除錯整體體驗極差，

總結

云計算的發展，Serverless 是一個必然的產物，Serverless 作為一個新技識訓者說是一個新架構，很難通過一篇文章進行描述清楚，其優點和缺點都不只是上文中描述的那兩個，我們只是挑了比較典型的列出了而已，Serverless 在使用的時候也會有很多坑，有的時候真的是從入門到放棄，有的時候也會覺得真的很方便，又從放棄到入坑，但是無論怎么說，作為一個相對來說比較新鮮的事物，Serverless 有更多的領域和價值在等待我們去開發和探索，包括 Serverless 的應用領域、使用經驗等，

Serverless 架構被稱為是“真正實作了當初云計算的目標”，這種說法雖然有些夸張，但是也從另一方面表現出了大家對 Serverless 架構的期盼和信心，自 2012 年被提出至今，Serverless 架構也是經歷了 7 年多時間，正在逐漸的走向成熟，隨著容器技術、IoT、5G、區塊鏈等技術的快速發展， 技術上對去中心化、輕量虛擬化、細粒度計算等技術需求愈發強烈，相信未來 Serverless 將在云計算的舞臺上大放異彩！

傳送門：

• GitHub: github.com/serverless
• 官網：serverless.com

歡迎訪問：Serverless 中文網，您可以在 最佳實踐 里體驗更多關于 Serverless 應用的開發！

推薦閱讀：《Serverless 架構：從原理、設計到專案實戰》

標籤：其他

上一篇：prometheus（九） 收集kube-state-metrics指標資訊

下一篇：圖解kubernetes批處理Job控制器的關鍵設計