無服務(wù)器技術(shù)架構(gòu)概述

1、 Page * MERGEFORMAT 18無服務(wù)器技術(shù)架構(gòu)概述云計算的下一個紀(jì)元目 錄 TOC o 1-3 h z u HYPERLINK l _Toc44528924 一、前言 PAGEREF _Toc44528924 h 3 HYPERLINK l _Toc44528925 二、什么是Serverless PAGEREF _Toc44528925 h 4 HYPERLINK l _Toc44528926 三、Serverless的歷史 PAGEREF _Toc44528926 h 9 HYPERLINK l _Toc44528927 四、無服務(wù)器計算的優(yōu)缺點 PAGEREF _Toc44

2、528927 h 13 HYPERLINK l _Toc44528928 五、無服務(wù)器是未來嗎 PAGEREF _Toc44528928 h 16前言傳統(tǒng)上，Web應(yīng)用程序通常部署在Web服務(wù)器上。為了使應(yīng)用程序在服務(wù)器上運行，可能需要花費數(shù)小時來下載、編譯、安裝、配置和連接各種組件。計算機(jī)的操作系統(tǒng)也需要不斷進(jìn)行升級和修補(bǔ)，以解決安全漏洞。而管理服務(wù)器是一項非常耗時的工作，通常需要專門且經(jīng)驗豐富的系統(tǒng)操作人員，這讓很多工程師感覺到身心俱疲。服務(wù)器維護(hù)是什么感覺?大都會(1927年電影)而過去十年來，云計算發(fā)展得如火如荼，涌現(xiàn)出了很多改變傳統(tǒng)IT架構(gòu)和運維方式的新技術(shù)，比如虛擬機(jī)、容器和微服務(wù)

3、等，而Serverless（無服務(wù)器）架構(gòu)的出現(xiàn)，掀起了一場不小的波瀾，亞馬遜、微軟、谷歌等大型廠商已經(jīng)在無服務(wù)器架構(gòu)領(lǐng)域重資投入，追趕革命的浪潮。有人說Serverless架構(gòu)的興起，將云計算的發(fā)展拉入了下一個紀(jì)元時代?！袄^OpenStack、Docker、MiscroService、Unikernel、Kubernetes和Mesos之后，Serverless正成為Google、Amazon乃至創(chuàng)業(yè)公司暗戰(zhàn)的新戰(zhàn)場?！蹦敲碨erverless到底是什么？圖源科技云報道什么是Serverless無服務(wù)器計算是一種按需提供后端服務(wù)的方法，可將對常見基礎(chǔ)結(jié)構(gòu)管理任務(wù)（例如擴(kuò)展，調(diào)度，修補(bǔ)，配置等

4、）的責(zé)任轉(zhuǎn)移給云提供商和工具，從而使工程師可以將時間和精力集中在針對其應(yīng)用程序的業(yè)務(wù)邏輯上或過程。無服務(wù)器計算是IaaS演進(jìn)的下一個階段，從根本上說，無服務(wù)器是要花更多的時間在代碼上，而不是在基礎(chǔ)架構(gòu)上。所以很多人將Serverless視為開發(fā)人員的“靈丹妙藥”。亞馬遜CTO Werner Vogels比喻道:“以前，你的服務(wù)器就像寵物一樣。如果它們生病了，你就得把它們養(yǎng)好。它們像是牛，你必須放他們?nèi)コ圆荨５跓o服務(wù)器中沒有這樣的牛，只有您的應(yīng)用程序。您甚至不需要考慮恢復(fù)其健康或獲得新的應(yīng)用程序，其中的所有的任務(wù)都能自動執(zhí)行?！?無服務(wù)器計算中是否有服務(wù)器？與無服務(wù)器計算相關(guān)的最大爭議不是圍繞

5、它的價值、用例或哪些供應(yīng)商提供的產(chǎn)品適合于哪些工作，而是“無服務(wù)器”這個名稱本身。關(guān)于無服務(wù)器的一個持續(xù)爭論是該名稱到底合不合適，因為無服務(wù)器計算中仍然有服務(wù)器。就像WIFI在某處有網(wǎng)線一樣，無服務(wù)器架構(gòu)仍然在某處有具體的服務(wù)器。之所以使用“無服務(wù)器”這個名稱，是因為該名稱描述了最終用戶的體驗。在一種稱為“無服務(wù)器”的技術(shù)中，底層服務(wù)器的管理需求對于最終用戶是不可見的。服務(wù)器仍然在那里，只是看不到它們或與之交互。2Serverless = FaaS + BaaSServerless是云平臺幾次迭代的高潮，從云計算發(fā)展的過程來看，早期大多數(shù)企業(yè)采用的是物理機(jī)托管方式，云時代后，隨著虛擬化的發(fā)展，

6、開始在云環(huán)境上托管虛擬機(jī)，基礎(chǔ)設(shè)施即服務(wù)（IaaS）開始流行；在容器平臺時代到來后，開發(fā)者開始去關(guān)注應(yīng)用層所需要的計算資源和存儲資源的使用，這也就是平臺即服務(wù)（PaaS）。但這并不是旅程的終點，因為現(xiàn)在已經(jīng)轉(zhuǎn)向了無服務(wù)器架構(gòu)。PaaS 多通過容器平臺呈現(xiàn)，運維人員和開發(fā)人員已經(jīng)開始進(jìn)行抽離，在進(jìn)一步發(fā)展后開始實現(xiàn)函數(shù)即服務(wù)（FaaS），此時運營人員并不需要關(guān)注底層的能力，而只需要關(guān)注業(yè)務(wù)相關(guān)的事情，這就使得整體業(yè)務(wù)實現(xiàn)了輕量化。而 Serverless 更關(guān)注的就是上層業(yè)務(wù)的展示，可以將其描述為兩種思想的結(jié)合：函數(shù)即服務(wù)（FaaS）和后端即服務(wù)（BaaS）。FaaS 將服務(wù)器端代碼從長期運行的

7、組件移至臨時函數(shù)實例，而 BaaS 是指我們不再編寫或管理所有服務(wù)端組件，可以使用領(lǐng)域通用的遠(yuǎn)程組件來提供服務(wù)。由于這些都不需要感知底層服務(wù)器架構(gòu)，所以二者合起來就被稱為 Serverless 架構(gòu)。3與傳統(tǒng)模式架構(gòu)的區(qū)別傳統(tǒng)的架構(gòu)模式是使用C/S架構(gòu)的，在典型的web應(yīng)用程序中，服務(wù)器接收前端的HTTP請求處理，在保存或查詢數(shù)據(jù)庫之前，數(shù)據(jù)可能會經(jīng)過多個應(yīng)用層，最終后端會返回一個響應(yīng)。在Serverless架構(gòu)中，應(yīng)用業(yè)務(wù)邏輯是基于FaaS架構(gòu)形成多個相互獨立的功能組件的。并且以API服務(wù)的形式向外提供服務(wù)，在FaaS中，后端的應(yīng)用被拆分成為一個個函數(shù)，我們只需要編寫完成函數(shù)后部署到serv

8、erless服務(wù)即可。后續(xù)我們無須管理和操作云端或本地的服務(wù)器。Serverless的歷史AWS Lambda 作為Serverless最早的框架產(chǎn)品由亞馬遜在2014年推出，但最早Serverless概念的并不是由亞馬遜提出的。Serverless這個詞首次出現(xiàn)是在2012年，云基礎(chǔ)設(shè)施服務(wù)提供商Iron的副總裁Ken Form所寫的一篇名為Why The Future of Software and Apps is Serverless的文章。圖源Bk小凱筆記2014年，亞馬遜發(fā)布AWS Lambda，在這之后，Serverless開始變得流行起來，它為云中運行的應(yīng)用程序提供了一種全新的系

9、統(tǒng)體系結(jié)構(gòu)。至此再也不需要在服務(wù)器上持續(xù)運行進(jìn)程以等待HTTP請求或API調(diào)用，而是可以通過某種事件機(jī)制觸發(fā)代碼的執(zhí)行，通常這只需要在AWS的某臺服務(wù)器上配置一個簡單的功能。盡管AWS被公認(rèn)為是第一個使用無服務(wù)器計算平臺進(jìn)入市場的公司，但從那時起，其他主要的IaaS公共云提供商也紛紛效仿。亞馬遜，谷歌和微軟主導(dǎo)著當(dāng)今的無服務(wù)器市場。阿里巴巴，IBM，Oracle和許多較小的供應(yīng)商正在將自己的無服務(wù)器平臺和支持技術(shù)推向市場。同時，OpenFaas和Kubeless等開源項目正在嘗試將無服務(wù)器技術(shù)從云引入內(nèi)部部署。主要的無服務(wù)器計算供應(yīng)商包括：Google Cloud功能，它于2017年由Goog

10、le發(fā)布，支持Node.js JavaScript，Python和Go，但允許無限的函數(shù)執(zhí)行時間。Google Cloud Functions還可以與許多其他Google服務(wù)進(jìn)行交互，從而使開發(fā)人員幾乎無需考慮基礎(chǔ)服務(wù)器即可快速創(chuàng)建和管理復(fù)雜的企業(yè)級應(yīng)用程序。IBM Cloud 功能，它基于Apache OpenWhisk，支持JavaScript（Node.js），Swift和Cloudflare Workers，后者運行用JavaScript編寫的功能以及可以編譯為WebAssembly的任何語言。AWS Lambda。它于2014年推出，是Amazon Web Services（AWS）

11、的FaaS產(chǎn)品。AWS Lambda函數(shù)可以用Java，Go，PowerShell，Node.js JavaScript，C，Python和Ruby編寫。Microsoft Azure功能，微軟于2016年推出了Azure Functions，以與AWS Lambda競爭。它支持Bash，批處理，C，F(xiàn)，Java，JavaScript（Node.js），PHP，PowerShell，Python和TypeScript?，F(xiàn)在隨著容器技術(shù)，IoT，5G，區(qū)塊鏈等技術(shù)的快速發(fā)展，從物理機(jī)到云主機(jī)，到Serverless架構(gòu)，去服務(wù)器化開始越來越明顯。無服務(wù)器計算的優(yōu)缺點與傳統(tǒng)的基于云或以服務(wù)器為中心

12、的基礎(chǔ)架構(gòu)相比，無服務(wù)器計算具有許多優(yōu)勢。對于許多開發(fā)人員而言，無服務(wù)器體系結(jié)構(gòu)可提供更高的可伸縮性，更大的靈活性和更快的發(fā)布時間。1優(yōu)點無需服務(wù)器管理：盡管“無服務(wù)器”計算實際上是在服務(wù)器上進(jìn)行的，但開發(fā)人員無需預(yù)置或維護(hù)任何服務(wù)器。它們由供應(yīng)商管理。這可以減少在DevOps中的必要投資，從而降低支出，還可以使開發(fā)人員騰出空間來創(chuàng)建和擴(kuò)展其應(yīng)用程序，而不受服務(wù)器容量的限制。比傳統(tǒng)云便宜：開發(fā)人員僅需為使用的內(nèi)容付費，為一致的吞吐量或執(zhí)行持續(xù)時間（而不是服務(wù)器單元）付費。相比之下，在傳統(tǒng)的“服務(wù)器”架構(gòu)中，開發(fā)人員必須預(yù)先計劃所需的服務(wù)器容量，然后購買該容量，而不管最終是否會使用到?？蓴U(kuò)展：試

13、想一下，如果郵局可以以某種方式隨意地增加和取消運輸車輛，隨著郵件數(shù)量的增加而擴(kuò)大運輸隊的規(guī)模，在較少運輸?shù)臅r候縮小規(guī)模。從本質(zhì)上講，這就是無服務(wù)器應(yīng)用程序能夠做到的。使用無服務(wù)器基礎(chǔ)結(jié)構(gòu)構(gòu)建的應(yīng)用程序?qū)㈦S著用戶群的增加或使用量的增加而自動擴(kuò)展。如果某個功能需要在多個實例中運行，則供應(yīng)商的服務(wù)器將根據(jù)需要啟動，運行并結(jié)束它們。但是，無服務(wù)器計算并不是所有開發(fā)人員的靈丹妙藥，它也有著一定程度上的缺點。2缺點供應(yīng)商鎖定：允許供應(yīng)商為應(yīng)用程序提供所有后端服務(wù)將不可避免地增加對該供應(yīng)商的依賴。與一個供應(yīng)商建立無服務(wù)器架構(gòu)可能會導(dǎo)致在必要時難以切換供應(yīng)商，尤其是因為每個供應(yīng)商提供的功能和工作流程都略有不同

14、。安全問題：當(dāng)供應(yīng)商運行整個后端時，可能無法完全審查其安全性，這對于處理個人或敏感數(shù)據(jù)的應(yīng)用程序是一個大問題。性能會受到影響：因為它不是一直在運行，所以使用無服務(wù)器代碼時可能需要“啟動”。啟動時間可能會降低性能。但是，如果定期使用一段代碼，則無服務(wù)器提供程序?qū)⑹顾S時處于激活狀態(tài)。對此現(xiàn)成代碼的請求稱為“熱啟動”，對一段時間未使用的代碼的請求稱為“冷啟動”。無服務(wù)器是未來嗎無服務(wù)器標(biāo)志著云計算旅程的下一步，在過去的幾年里，AWS推出其Lambda平臺之后，無服務(wù)器已經(jīng)成為BBC，Airbnb，Netflix，耐克等品牌的主流架構(gòu)，并且更多采用新方法來處理其后端。事實證明，Lambda在AWS中運行容器的公司中特別受歡迎，截至2020年1月，AWS中近80的運行容器的組織都采用了Lambda。根據(jù)報告顯示，到2021年，無服務(wù)器市場預(yù)計將以32.7的速度增長。但相對來說，無服務(wù)器仍然是一個新世界，Gartner分析師Lowery表示，市場是如此年輕，以至于還沒有贏家和輸家。他說，真正的關(guān)鍵在于確定無服務(wù)器系統(tǒng)的用途。FaaS可以是一個強(qiáng)大的工具，可以將特定供應(yīng)商的云中的各種服務(wù)“粘合”在一起。另一方面，其他物聯(lián)網(wǎng)事件驅(qū)動的用例可能并不局限于特定供應(yīng)商的云。參考資料：/weixin_341