入門 Serverless：如何實現 Hello World？

• 2020 年 4 月 9 日
• 筆記

近年來，IT 技術的更新迭代速度非常快，每個時間點都有典型的代表名詞以及概念，就目前而言，人工智慧領域中的機器學習、深度學習、強化學習等名詞和概念就非常熱，同時區塊鏈、物聯網等技術發展也是異常火熱。在雲計算領域，有這樣一個技術被眾多雲廠商認為是「風口項目」，甚至可以顛覆現有雲計算中的某些格局，為此包括 AWS、Google以及騰訊雲、阿里雲等在內的雲廠商，都為此投入了重大人力以及精力進行相關產品建設，它就是 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：如何實現 Hello World？

傳統意義上，一台伺服器能接受多大的流量，峰值是多少，是需要我們進行評估的，同時後期也要不斷維護和更新數據的。但是在 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 Framework 免費試用計劃

Serverless Framework 免費試用名額已開放，我們誠邀您來試用和體驗最便捷的 Serverless 開發和部署方式。包括服務中使用到雲函數 SCF、API 網關、對象存儲 COS 等產品，均在試用期內提供免費資源，並伴有專業的技術支援，幫助您的業務快速、便捷實現 Serverless ！

Serverless Framework 落地 Serverless 架構的全雲端開發閉環體驗，覆蓋編碼、運維、調試、部署等開發全生命周期。使用 Serverless Framework 即可在幾秒鐘內將業務部署至雲端。

具體免費詳情可查閱：https://cloud.tencent.com/document/product/1154/38792