溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章給大家分享的是有關Serverless如何實現Hello World，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
近年來，IT 技術的更新迭代速度非常快，每個時間點都有典型的代表名詞以及概念，就目前而言，人工智能領域中的機器學習、深度學習、強化學習等名詞和概念就非常熱，同時區塊鏈、物聯網等技術發展也是異常火熱。
在云計算領域，有這樣一個技術被眾多云廠商認為是“風口項目”，甚至可以顛覆現有云計算中的某些格局，為此包括 AWS、谷歌以及騰訊云、阿里云等在內的云廠商，都為此投入了重大人力以及精力進行相關產品建設，它就是 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，就不得不說 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 網關服務：
創建完成，系統會給我們分配一個地址：
通過瀏覽器打開這個地址：
這時，我們就成功的搭建了一個 Web 服務，后臺會展示Hello World，如果是傳統開發條件下，做一個這樣的頁面，需要做哪些工作？
使用框架開發一個Hello World
購買服務器，并配置服務器的環境
將本地開發好的項目上傳到服務器中
購買域名 / 使用服務器 IP，綁定我們的項目
這個過程可能涉及到的有常用的 Web 框架（例如 Django，Spring，Express…），服務器的軟件（Nginx，Apache，Tomcat…）等等，甚至我們還要考慮網站的流量有多大，買多大內存的機器，啟動多少進程，多少線程，還要想辦法對服務器進行各種優化。
但我們剛剛做的操作只有：
建立函數
增加 API 網關觸發器
其余的一切操作都不用我們關心，我們可以將更多的精力放在了 "Coding"。
在生產生活中，我們經常需要獲取 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 架構下，用戶不需要考慮這個問題，云廠商將會為用戶實現彈性伸縮的能力。當平臺接收到第一個觸發函數的事件時，將啟動容器來運行你的代碼。如果此時收到了新的事件，而第一個容器仍在處理上一個事件，平臺將啟動第二個代碼實例來處理第二個事件。SCF 的這種自動零管理水平縮放，將持續到有足夠的代碼實例來處理所有的工作負載。當并發出現的時候，云廠商會啟動多個容器來應對 " 流量洪峰 "，相對于傳統服務器來說，在這一層面上，Serverless 架構或者說云函數真的是很方便了。
按量付費
按量付費是 Serverless 架構的一個優點，傳統服務器，無論是否有流量，我們都要進行成本支出，并且服務器配置還要按照某個時間段最大流量來進行配置，所以支出情況實際上是不合理的。但是函數計算實際上是按量收費，而且相對來說價格很低，尤其對不同時間段資源消耗峰值低谷有較大差距的項目而言，是真的很棒。
冷啟動
說到 Serverless 架構的缺點就不得不說冷啟動問題，冷啟動無論是 AWS 還是 Google 還是騰訊云、阿里云，都是普遍存在的。一般情況下來說，冷啟動就是函數在 " 睡覺 "，突然有一個觸發的過程，后臺拉起容器、下載代碼、啟動進程、觸發入口方法的一個過程，所以一般情況下，容器在首次啟動的時候都會有冷啟動，通過上圖可以看到，函數冷啟動可能達到幾百毫秒甚至數秒，這對一些業務可能是致命打擊，當然各個云廠商也在努力通過各種策略、方案降低冷啟動率。
調試困難
云函數的另一個缺點是調試困難，由于它提供給我們的是一個函數運行的容器，而且很多基本業務又是和廠商綁定的，這就導致我們調試困難。例如，我們要調試一個函數，本來可以通過模擬一些觸發器情況進行調試，但是，如果函數中涉及到了一些內網資源，例如與 redis 相關，只能通過 vpc 訪問的資源，那么這個時候進行本地調試困難度就會成倍增加，在線調試又可能因為日志輸出過慢，導致調試整體體驗極差。
云計算的發展，Serverless 是一個必然的產物。Serverless 作為一個新技術或者說是一個新架構，很難通過一篇文章進行描述清楚，其優點和缺點都不只是上文中描述的那兩個，我們只是挑了比較典型的列出了而已。Serverless 在使用的時候也會有很多坑，有的時候真的是從入門到放棄，有的時候也會覺得真的很方便，又從放棄到入坑，但是無論怎么說，作為一個相對來說比較新鮮的事物，Serverless 有更多的領域和價值在等待我們去開發和探索，包括 Serverless 的應用領域、使用經驗等。
Serverless 架構被稱為是“真正實現了當初云計算的目標”，這種說法雖然有些夸張，但是也從另一方面表現出了大家對 Serverless 架構的期盼和信心，自 2012 年被提出至今，Serverless 架構也是經歷了 7 年多時間，正在逐漸的走向成熟。隨著容器技術、IoT、5G、區塊鏈等技術的快速發展， 技術上對去中心化、輕量虛擬化、細粒度計算等技術需求愈發強烈，相信未來 Serverless 將在云計算的舞臺上大放異彩！
以上就是Serverless如何實現Hello World，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
