共計 7370 個字符，預計需要花費 19 分鐘才能閱讀完成。
本篇文章給大家分享的是有關 Serverless 如何實現(xiàn) Hello World，丸趣 TV 小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。
近年來，IT 技術的更新迭代速度非常快，每個時間點都有典型的代表名詞以及概念，就目前而言，人工智能領域中的機器學習、深度學習、強化學習等名詞和概念就非常熱，同時區(qū)塊鏈、物聯(lián)網(wǎng)等技術發(fā)展也是異常火熱。
在云計算領域，有這樣一個技術被眾多云廠商認為是“風口項目”，甚至可以顛覆現(xiàn)有云計算中的某些格局，為此包括 AWS、谷歌以及騰訊云、阿里云等在內(nèi)的云廠商，都為此投入了重大人力以及精力進行相關產(chǎn)品建設，它就是 Serverless 技術。
什么是 Serverless
Serverless 可以說是一種架構，一種云計算發(fā)展的產(chǎn)物，至于具體說什么是 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，如果用一張圖來表示上面的描述，可以是：
說到這里，不同的人可能已經(jīng)對 Serverless 有了不同的勾勒，但是可能普遍還有一個疑問，我怎么用 Serverless？向云服務器上傳我項目？還是像一種框架，用來寫代碼？用了它我可以得到什么？性能的提升？效率的提高？成本的降低？
首先，我們以一個常見的 Web 服務為例：
在這個圖中，服務器中可能涉及路由規(guī)則、鑒權邏輯以及其他各類復雜的業(yè)務代碼，同時，開發(fā)團隊要付出很大的精力在這個服務器的運維上面，包括客戶量突然增多時是否需要擴容服務器；服務器上的腳本，業(yè)務代碼等是否還在健康運行；是否有黑客在不斷地對服務器發(fā)起攻擊；也就是說，當我們把這個思路切換到 Serverless 的邏輯之后，上圖就變成了這樣：
可以認為，當客戶端和數(shù)據(jù)庫未發(fā)生變化的前提下，服務器變化巨大，之前需要開發(fā)團隊維護的路由模塊以及鑒權模塊都將接入服務商提供的 API 網(wǎng)關系統(tǒng)以及鑒權系統(tǒng)，開發(fā)團隊無須再維護這兩部分的業(yè)務代碼，只需要持續(xù)維護相關規(guī)則即可。同時業(yè)務代碼也被拆分成了函數(shù)粒度，不同函數(shù)表示不同的功能。同時，在這個結(jié)構下，我們已經(jīng)看不到服務器的存在，是因為 Serverless 的目的是讓使用者只關注自己的業(yè)務邏輯即可，所以一部分安全問題、資源調(diào)度問題（例如用戶量暴增、如何實現(xiàn)自動擴容等）全都交給云廠商負責，并且相對于傳統(tǒng)項目而言，傳統(tǒng)項目無論是否有用戶訪問，服務都在運行中，都是有成本支出，而 Serverless 而言，只有在用戶發(fā)起請求時，函數(shù)才會被激活并且執(zhí)行，按量收費，相對來說，可以在有流量的時候才有支持，沒有流量的時候就沒有支出，成本會進一步降低。
通過分析和描述，不難看出，Serverless 架構相對于傳統(tǒng)的開發(fā)模式有什么區(qū)別。但是問題來了，很多工作都不需要我們做了，都交給云廠商做了，那么我們做什么？
使用 Serverless 架構，用戶不需要自己維護服務器，也不需要自己操心服務器的各種性能指標和資源利用率，而是可以讓用戶付出更多的時間和精力去關心應用程序本身的狀態(tài)和邏輯。同時 Serverless 應用本身的部署十分容易，我們只要上傳基本的代碼，例如 Python 程序只需要上傳其邏輯與依賴包，C/C++、Go 等語言只需上傳其二進制文件，Java 只需要上傳其 Jar 包等即可，同時不需使用 Puppet、Chef、Ansible 或 Docker 來進行配置管理，大大降低了運維成本。對于運維來說，Serverless 架構也不再需要監(jiān)控底層的數(shù)據(jù)，例如不再需要監(jiān)控磁盤使用量、CPU 使用率等，可以更加專注的將監(jiān)控目光放到監(jiān)控應用程序本身的度量。同時在 Serverless 架構上，運維人員的工作角色會有所轉(zhuǎn)變，部署將變得更加自動化，監(jiān)控將更加面向應用程序本身。
總而言之，Serverless 是在傳統(tǒng)容器技術和服務網(wǎng)格上發(fā)展起來，它更多指的是后端服務與函數(shù)服務的結(jié)合，對于開發(fā)者而言，會更多關注在函數(shù)服務商，讓使用者只關注自己的業(yè)務邏輯即可。Serverless 是云計算發(fā)展到一定階段的必然產(chǎn)物，云計算作為普惠科技，發(fā)展到最后一定是綠色科技（最大程度利用資源，減少空閑資源浪費），大眾科技（成本低，包括學習成本及使用成本）的產(chǎn)品，而 Serverless 將很好的詮釋這些！Serverless 架構被稱為是“真正實現(xiàn)了當初云計算的目標”，這種說法雖然有些夸張，但是也從另一方面表現(xiàn)出了大家對 Serverless 架構的期盼和信心，自 2012 年被提出至今，Serverless 架構也是經(jīng)歷了 7 年多的時間，正在逐漸的走向成熟。
入門 Serverless
說起 Serverless，就不得不說 BaaS 和 FaaS，BaaS 服務更多是云廠商給我們提供 / 維護，所以開發(fā)者精力可以更多放在 FaaS 層面，或者說是在函數(shù)計算層面。
接下來，我們來體驗一下 Serverless。以騰訊云為例，我們通過騰訊云控制臺，選擇 Serverless 分類下的云函數(shù)：
接下來就可以看到 Serverless 中的一部分：函數(shù)計算部分。此時，我們可以新建一個函數(shù)，進行基本的測試，體驗一下 Serverless 下的 Hello World 和我們傳統(tǒng)的 Hello World 有什么不同。
新建函數(shù)：
選擇運行時（就是我們要用的編程語言）：
進行代碼的編寫：
點擊完成，即可保存代碼
進行代碼測試：
可以看到測試結(jié)果：
至此，我們完成了一個函數(shù)的基本編寫，但是仔細想一下：貌似和一些在線編程工具差不多，可以在線編寫代碼、運行。BaaS 體現(xiàn)在了哪里？體現(xiàn)在提供了運行環(huán)境？除了寫了一個 hello world，我還能干什么？
接下來，我們進行觸發(fā)器的體驗。所謂的觸發(fā)器，是指我們的函數(shù)一般情況下都是 休息 的，只有在一個 東西觸碰它，“激活它”，才會起來干活。剛剛我們是怎么讓函數(shù) 起來工作的？是通過屏幕上的 測試按鈕，所以說這也算是一個觸發(fā)器。那么除了這個觸發(fā)器，還有那些？
可以看到，目前騰訊云提供給我們的觸發(fā)器包括：
定時觸發(fā)器（顧名思義，就是定好時間進行函數(shù)的觸發(fā)，例如說每天幾點觸發(fā)一次，或者說每隔多久觸發(fā)一次，這類操作適合我們做定時任務，例如進行數(shù)據(jù)采集 / 數(shù)據(jù)聚合，消息推送等。）
COS 觸發(fā)器 我們可能會將文件存儲到文件系統(tǒng)，在傳統(tǒng)的云主機中，我們可以存到機器本身，但是 Serverless 架構下，由于函數(shù)是無狀態(tài)的，所以我們不能做持久化，那么就需要一個外部的媒體，對象存儲 就是我們常用的持久化文件產(chǎn)品，可以將一些文件存儲在上面，例如圖片、文檔、可執(zhí)行程序…，同時也可以通過存入到上面一個文件，來觸發(fā)我們的函數(shù)。例如當有圖片上傳到對象存儲中，函數(shù)計算會下載這個圖片，進行圖片壓縮和水印等處理。
CMQ 主題訂閱觸發(fā)器 CMQ 主題訂閱是指，當我們 CMQ 中有隊列存在，就可以將內(nèi)容發(fā)給云函數(shù)，云函數(shù)來進行消費處理。
Ckafka 觸發(fā) 與上面說的 CMQ 主題訂閱觸發(fā)器基本一樣，只不過這個是 Ckafka。當 Ckafka 中消息出現(xiàn)（可以是每條觸發(fā)也可以是最多多少條觸發(fā)），會讓函數(shù) 起來工作，進行數(shù)據(jù)處理、完成消費。
API 網(wǎng)關觸發(fā)器 是和函數(shù)關系非常緊密的一個服務。通過 API 網(wǎng)關觸發(fā)，可以讓函數(shù)具備被訪問能力。什么叫做被訪問呢？就是說可以通過瀏覽器 / 接口直接使用，所以 API 網(wǎng)關觸發(fā)器和云函數(shù)結(jié)合通常可以作網(wǎng)站、后臺服務等。
此時，我們可以建立一個 API 網(wǎng)關觸發(fā)器，看看函數(shù)和 API 網(wǎng)關結(jié)合所帶來的有趣碰撞：
初探 API 網(wǎng)關與函數(shù)
我們新建一個 API 網(wǎng)關服務：
創(chuàng)建完成，系統(tǒng)會給我們分配一個地址：
通過瀏覽器打開這個地址：
這時，我們就成功的搭建了一個 Web 服務，后臺會展示 Hello World，如果是傳統(tǒng)開發(fā)條件下，做一個這樣的頁面，需要做哪些工作？
使用框架開發(fā)一個 Hello World
購買服務器，并配置服務器的環(huán)境
將本地開發(fā)好的項目上傳到服務器中
購買域名 / 使用服務器 IP，綁定我們的項目
這個過程可能涉及到的有常用的 Web 框架（例如 Django，Spring，Express…），服務器的軟件（Nginx，Apache，Tomcat…）等等，甚至我們還要考慮網(wǎng)站的流量有多大，買多大內(nèi)存的機器，啟動多少進程，多少線程，還要想辦法對服務器進行各種優(yōu)化。
但我們剛剛做的操作只有：
建立函數(shù)
增加 API 網(wǎng)關觸發(fā)器
其余的一切操作都不用我們關心，我們可以將更多的精力放在了 Coding。
用函數(shù)和 API 網(wǎng)關做點有趣的
在生產(chǎn)生活中，我們經(jīng)常需要獲取 IP 地址進行某些工作，例如我之前做了一個網(wǎng)站，這個網(wǎng)站的用戶簽名體系包括了用戶的 IP，而客戶端想獲得用戶 IP 是一個比較復雜的過程。一般情況下是需要通過訪問服務端的獲取 IP 接口來獲得客戶端對應的 IP 地址。那么通過函數(shù)計算和 API 網(wǎng)關，我們應該怎么做呢？
剛才說到了觸發(fā)器，每種觸發(fā)器都會和函數(shù)有一個規(guī)約，我給你一種什么樣的格式數(shù)據(jù)，通過函數(shù)下面的測試模板可以看到：
通過這里，可以看到 API 網(wǎng)關和函數(shù)約定的一個結(jié)構：
{
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
}
同時，函數(shù)會將這個結(jié)構作為入?yún)⒅粋鬟f給開發(fā)人員，例如騰訊云將這個參數(shù)命名為 event，也就是說，開發(fā)者可以通過函數(shù)入口的 event 參數(shù)進行 API 網(wǎng)關相關內(nèi)容的解析。
那么什么是函數(shù)的入口呢？
入口函數(shù)實際上就是用戶代碼中的文件名 + 方法名，這里面默認設定就是 index 文件中的 main_handler 方法，可以看到 main_handler 方法，確實有一個參數(shù)是 event，這個參數(shù)就是觸發(fā)器傳遞過來的數(shù)據(jù)結(jié)構。另外一個 context 參數(shù)是上下文，用戶對上下文內(nèi)容的處理，例如上游資源產(chǎn)生的 RequestId、環(huán)境信息、密鑰信息等。
通過上面的數(shù)據(jù)接口，可以看到在 requestContext 中 sourceIp，是用戶的 IP 地址，那么我們是否就可以把這個 IP 直接返回給用戶，實現(xiàn) IP 查詢功能呢？
# -*- coding: utf8 -*-
import json
def main_handler(event, context):
return({ip : event[ requestContext][sourceIp]})
通過 4 行代碼編寫之后，我們綁定 API 網(wǎng)關，并且通過瀏覽器訪問可以看到：
是的，這樣一個功能，只需要 4 行代碼就可以搞定。
再說說 Serverless
剛剛我們已經(jīng)入門了云函數(shù)，對云函數(shù)也有了一個初步的了解了，那么接下來，我們說說 Serverless 架構有哪些優(yōu)點和缺點。
優(yōu)點
彈性伸縮
傳統(tǒng)意義上，一臺服務器能接受多大的流量，峰值是多少，是需要我們進行評估的，同時后期也要不斷維護和更新數(shù)據(jù)的。但是在 Serverless 架構下，用戶不需要考慮這個問題，云廠商將會為用戶實現(xiàn)彈性伸縮的能力。當平臺接收到第一個觸發(fā)函數(shù)的事件時，將啟動容器來運行你的代碼。如果此時收到了新的事件，而第一個容器仍在處理上一個事件，平臺將啟動第二個代碼實例來處理第二個事件。SCF 的這種自動零管理水平縮放，將持續(xù)到有足夠的代碼實例來處理所有的工作負載。當并發(fā)出現(xiàn)的時候，云廠商會啟動多個容器來應對 流量洪峰，相對于傳統(tǒng)服務器來說，在這一層面上，Serverless 架構或者說云函數(shù)真的是很方便了。
按量付費
按量付費是 Serverless 架構的一個優(yōu)點，傳統(tǒng)服務器，無論是否有流量，我們都要進行成本支出，并且服務器配置還要按照某個時間段最大流量來進行配置，所以支出情況實際上是不合理的。但是函數(shù)計算實際上是按量收費，而且相對來說價格很低，尤其對不同時間段資源消耗峰值低谷有較大差距的項目而言，是真的很棒。
缺點
冷啟動
說到 Serverless 架構的缺點就不得不說冷啟動問題，冷啟動無論是 AWS 還是 Google 還是騰訊云、阿里云，都是普遍存在的。一般情況下來說，冷啟動就是函數(shù)在 睡覺，突然有一個觸發(fā)的過程，后臺拉起容器、下載代碼、啟動進程、觸發(fā)入口方法的一個過程，所以一般情況下，容器在首次啟動的時候都會有冷啟動，通過上圖可以看到，函數(shù)冷啟動可能達到幾百毫秒甚至數(shù)秒，這對一些業(yè)務可能是致命打擊，當然各個云廠商也在努力通過各種策略、方案降低冷啟動率。
調(diào)試困難
云函數(shù)的另一個缺點是調(diào)試困難，由于它提供給我們的是一個函數(shù)運行的容器，而且很多基本業(yè)務又是和廠商綁定的，這就導致我們調(diào)試困難。例如，我們要調(diào)試一個函數(shù)，本來可以通過模擬一些觸發(fā)器情況進行調(diào)試，但是，如果函數(shù)中涉及到了一些內(nèi)網(wǎng)資源，例如與 redis 相關，只能通過 vpc 訪問的資源，那么這個時候進行本地調(diào)試困難度就會成倍增加，在線調(diào)試又可能因為日志輸出過慢，導致調(diào)試整體體驗極差。
云計算的發(fā)展，Serverless 是一個必然的產(chǎn)物。Serverless 作為一個新技術或者說是一個新架構，很難通過一篇文章進行描述清楚，其優(yōu)點和缺點都不只是上文中描述的那兩個，我們只是挑了比較典型的列出了而已。Serverless 在使用的時候也會有很多坑，有的時候真的是從入門到放棄，有的時候也會覺得真的很方便，又從放棄到入坑，但是無論怎么說，作為一個相對來說比較新鮮的事物，Serverless 有更多的領域和價值在等待我們?nèi)ラ_發(fā)和探索，包括 Serverless 的應用領域、使用經(jīng)驗等。
Serverless 架構被稱為是“真正實現(xiàn)了當初云計算的目標”，這種說法雖然有些夸張，但是也從另一方面表現(xiàn)出了大家對 Serverless 架構的期盼和信心，自 2012 年被提出至今，Serverless 架構也是經(jīng)歷了 7 年多時間，正在逐漸的走向成熟。隨著容器技術、IoT、5G、區(qū)塊鏈等技術的快速發(fā)展，技術上對去中心化、輕量虛擬化、細粒度計算等技術需求愈發(fā)強烈，相信未來 Serverless 將在云計算的舞臺上大放異彩！
以上就是 Serverless 如何實現(xiàn) Hello World，丸趣 TV 小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學到更多知識。更多詳情敬請關注丸趣 TV 行業(yè)資訊頻道。
