共計 5201 個字符，預計需要花費 14 分鐘才能閱讀完成。
本篇內容主要講解“Serverless 是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“Serverless 是什么”吧!
要說目前軟件架構中熱度十二分的話題，當屬 Serverless。
通常我們會將其翻譯為“無服務器架構”。
盡管成天被稱為“無服務器”，但該架構與傳統架構不同，顯然并不是真的不需要服務器。
而是選擇將服務器等基礎設施的管理“隱藏”起來，計算資源作為服務而不是作為服務器的概念出現。
兼具事件觸發、短暫以及完全被第三方管理等多重屬性，其中開發者只需關注業務邏輯即可。
那一年，也就是 2012，TA 首次出現在技術人的視野之中。
就在嶄露頭角之后的短短兩年，號稱云計算“3A 巨頭”之一的 AWS，就于當年年底正式推出了 Lambda 產品，標志著 Serverless 的商業化進程隆重被開啟。
當時的 Lambda 曾被大家如此描述：這是一種計算服務，可以根據時間來運行用戶的代碼，無需關心底層的計算資源。
從 2012 年到 2014 年，Lambda 著實不算早到。
但就像云計算 PaaS 初出茅廬時的說法一樣：用戶只管業務就好，底層 IaaS 就交給我們吧！
Serverless 與 PaaS 帶給人們的理念是如此驚人的相似。
隨后的兩年時間內，Google Cloud Function 和微軟 Azure Function 在技術圈子的成功，也就順理成章將 Serverless 推進了熱化階段。
從架構變遷聚焦 Serverless 內涵
對于眾多開發者而言，顯然僅僅知道“Serverless 被定義為無服務器架構”的概念完全不夠，如何將 Serverless 的理解更具象化一些？
恐怕還是要從軟件應用架構演進的角度說起。
或許你可能了解，在十幾年前，單體應用作為最主流的應用架構形式被廣泛認可。
依靠一臺服務器外加一個數據庫，就能讓服務可用性達到峰值狀態。
但隨著服務器老化性能下降甚至自身損壞的情況，再加上企業業務量的逐漸擴大，單體架構再也不是“一招鮮吃遍天”。
哪怕在流量入口加入負載均衡器，讓單體應用可以部署在多臺服務器上來增加彈性，也不能完全解決由代碼無物理邊界所帶來的大量沖突。
至此，單體應用架構第一次有機會進化成微服務架構，而此時的架構師們也就不得不直面分布式帶來的新挑戰。
例如那些年的緩存服務 Redis、狀態協調服務 ZooKeeper、消息服務 Kafka 等。
我們可以簡單理解為，將一個大系統劃分為多個業務模塊，其中的業務模塊又需要分別部署在不同的服務器上，各個業務模塊之間通過接口進行數據交互，這件事兒似乎沒那么簡單。
當然除了分布式環境的特殊性以外，微服務架構也給運維帶來了不小改變。
具體實踐中，由于微服務可以部署在不同的服務器上，也可以部署在相同的服務器卻不同的容器上，包括應用分發標準、生命周期標準以及自動化彈性等能力在內的重要性也就一一凸顯出來。
轉眼到了眾所周知的云原生時代，業務直接上云不說，還能提供標準化的應用托管服務，包括版本管理、發布、上線后的觀測、自愈等，價值紅利得到進一步彰顯。
而此時 Serverless 也正迎著這波技術紅利闖入了大眾的視線，得到關注。
可以看出，在架構的演進中，無論是研發還是運維人員都逐漸將著眼點從機器向平臺系統轉移，而不是單純用人去管理，這或許是對于 Serverless 原理最樸素的闡釋。
總結一下，Serverless 的出現其實是將主機管理、操作系統管理、資源分配等，甚至是應用邏輯全部組件都集成為服務。
如果將其放在當下的云計算場景中，就不能單純狹義理解為“不用關心服務器”那么簡單，畢竟上云的資源除了服務器之外，還涉及基礎計算、存儲資源、網絡資源等諸多，也包括數據庫、緩存以及消息隊列等更上層的范疇。
Serverless 架構類同 FaaS，又做何解？
提及 Serverless，很多人的第一反應都是 FaaS+BaaS。
的確，這是 Serverless 的一種實現形式，也是一種比較主流的理解。
所謂“FaaS+BaaS”，其實就是函數即服務與后端即服務的結合體。
具體來說，BaaS（Backend as a Service）可以被解釋為“后端即服務”。
一般是 API 調用后端或別人已經實現好的程序邏輯，通常用來管理數據。
例如，亞馬遜 RDS 可以替代自己部署的 MySQL，當然其中還有各種其它數據庫、中間件的作用。
FaaS（Functions as a Service）則是函數即服務，作為無服務器計算的一種形式，當前使用最廣泛的當屬 AWS 的 Lambada。
經過長期實踐我們認為，Serverless 架構可以提供一種更加“代碼碎片化”的軟件架構范式，而所謂的“函數”（Function），則是提供相比微服務更加細小的程序單元。
進一步來說，究竟該如何理解“函數即服務”的概念？
大致上是開發者先將函數定義封裝在容器中，通過調用函數來實現調用后端存儲等服務。
本質上，FaaS 是一種事件驅動的由消息觸發的服務。
與傳統的服務器端軟件的不同，經應用程序部署到擁有操作系統的虛擬機或者容器中，一般需要長時間駐留在操作系統中運行。
而 FaaS 則可以直接將程序部署上到平臺上，當有事件到來時觸發執行，執行完了就可以消滅。
更重要的一點，FaaS 產品不需要對特定框架或庫進行編碼。
還是以 AWS Lambda 函數為例，函數可以在 Javascript、Python、Go 等，也就是任何 JVM 語言（Java，Clojure，Scala 等）或.NET 語言中實現；但與此同時，Lambda 函數還可執行與其部署工件捆綁在一起的另一個進程。
在 FaaS 環境中，用戶將函數功能代碼上傳到 FaaS 提供商，其中對的水平擴展是完全自動彈性的。
而“函數”還可以代表客戶所要執行的每個操作，即每個函數完成一個相對簡單的業務邏輯，一個完整的應用由若干個函數組成，主要包括創建、讀取、更新以及刪除等。
目前，函數即服務（Function as a Service，FaaS）是當下 Serverless 實現的技術基礎。
因為 FaaS 和 Serverless 之間關系密切，所以 FaaS 的特點也可以被認為是 Serverless 平臺的特點，但如果單純認為 Serverless 就是 FaaS，就比較狹義了。
BaaS 時代僅僅以 API 的方式提供應用依賴的后端服務；而在 FaaS 時期，用戶與開發者不再關注底層，這么說 Serverless 繁榮也是合理有據的事兒。
使用 Serverless，也是一把雙刃劍
據實際觀察，一直以來企業使用 Serverless 通常會涉及幾方面因素，其中“減少運營成本”被認為是最直觀有效的原因之一。
的確，應用 Serverless 后，企業就無需再為潛在的流量高峰買進大部分時間都可能空閑的服務器機架，而是根據流量進行自動伸縮，采用按請求量來付費的靈活方式。
此外“自動按需擴展”可以發揮到極致：隨時擴展到當前的使用量，消除了意外或者季節性流量高峰的困擾。
更重要的是，Serverless 不需要關心內存泄露，還具備將云數據庫、云消息隊列等服務囊括在內的完善配套設施，極大減少工作量。
哪怕企業中大部分的開發人員都出身軟件，對修復保護以及管理并不擅長，一樣可以做到專注軟件開發，Serverless 絕對沒問題。
基于此，一直以來國內外都有很多企業致力于提供基于 Serverless 框架的能力服務，接受程度更是水漲船高，簡單盤點下，尤其是幾家大型的公有云廠商。
例如里程碑式的 AWS Lambda。
作為 AWS 針對 Serverless 架構推出的 FaaS 云服務，AWS Lambda 自 2014 年上線以后就受到廣泛關注，除了滿足大家對 Serverless 的期望之外，更重要的是 AWS 平臺的成功。
AWS Lambda 的優勢可以簡單總結為：
成熟度高：第一個在主流公有云平臺上的 Serverless FaaS 平臺，已經有數年的發展和沉淀用戶基數大：AWS Lambda 有較大的用戶基數，參考案例很多活躍的社區：目前開源社區有很多圍繞 AWS Lambda 展開的開源項目 AWS 的整合：AWS Lambda 天然和 AWS 平臺上的服務有良好集成緊隨其后，Microsoft Azure 也在 2016 年推出了事件驅動的函數式云計算服務 Azure Functions。
其支持用戶以多種語言進行函數開發，包括 Java、Node.js、PHP、C#、F#、Bash 及 Microsoft Windows 的 PowerShell 腳本等。
此外，Azure Functions 除了提供公有云的版本之外，還提供私有化（On-premises）部署的版本 Azure Functions Runtime。
產品功能也是可圈可點：
完整性：Azure Functions 是一個功能比較完備的 Serverless FaaS 平臺整合：Azure Functions 天然與 Azure 云平臺上各類服務有良好的集成平臺：對于使用微軟體系產品和工具構建 IT 能力的企業而言，Azure Functions 是 Serverless 轉型的首選平臺私有化：提供帶有商業支持的私有化部署版本，可滿足不同層面的用戶的需求同樣是在 2016 年，Google Cloud Platform 推出了 Google Cloud Functions 平臺，也同時加入 Serverless 領域的競爭序列。
同為 FaaS 平臺，Google Cloud Functions 與 AWS Lambda 和 Microsoft Azure 在功能上最大的區別有啥？
細數以后，可能在于 Google Cloud Functions 目前僅支持 JavaScript 作為函數開發語言，運行環境為 Node.js。
2018 年 7 月，Google 又順勢公布了開源項目 Knative，定位為 Kubernetes 的 Serverless 插件，推出后得到了 Pivotal、IBM 以及 Red Hat 的大力支持。
國外爭先恐后，國內也是蜂擁而至。阿里云作為國內第一批推出 Serverless 平臺的公有云廠商，其 FaaS 平臺產品被稱為阿里云函數計算。
如果從事件觸發、支持語言以及用戶體驗等方面考量，該產品也有很多數據值得關注：
事件觸發：阿里云函數計算可以被阿里云上的服務事件觸發，例如阿里云對象存儲（OSS）支持語言：阿里云函數計算目前支持的開發語言為 Node.js，并計劃后續將支持 Java 及 Python 整個函數代碼的部署包大小不能超過 50MB，部署包解壓后的代碼不能超過 250MB 用戶體驗：阿里云函數計算提供了基于 Web 的控制臺和 SDK；用戶可以通過 Web 控制臺管理函數應用，也可以通過交互式的命令行來操作服務規格：一個服務下最多包含 50 個函數和 10 個觸發器。在運行時，函數最長的運行時間為 300s，即 5min，一個函數的最大并發數為 100 同為國內云計算競爭的翹楚，無服務器云函數（Serverless Cloud Function，SCF）是騰訊云推出的函數式計算平臺，根據官方的資料，其發布時間是 2017 年 4 月 26 日。
總結下騰訊云 Serverless 平臺的特點：
函數運行時：騰訊云 SCF 目前支持 Python、Java 及 Node.js 作為函數的開發語言用戶可以以壓縮包的形式從本地上傳代碼，也可以引用騰訊云對象存儲中的代碼文件事件觸發：目前騰訊云 SCF 支持的事件觸發源有騰訊云對象存儲 COS、定時器、騰訊云消息服務 CMQ，以及用戶手動通過 API 及控制臺觸發服務規格：每個函數將在一個基于 CentOS Linux 的環境中被執行。函數執行的內存范圍為 128MB 至 1536MB，單個區域支持的最大函數定義數量為 20 個，函數執行的最大時長為 300 秒，最大的并發數為 5 以上我們探討的基本是大型公有云服務商針對 Serverless 的技術實踐。
其實與公有云相比，在私有環境中構建 Serverless 平臺，在技術上并沒有什么太多障礙，自然也有不少領先的技術嘗試，對于此我們會專門成文詳細探討。
可以發現，哪怕是擁有世界范圍影響力的公有云服務商針對 Serverless 的技術探究似乎也出現了缺乏統一認知以及相應標準，無法適應所有的云平臺的情況，例如支持的開發語言不同，事件觸發的機制有差異等。
畢竟 Serverless 從來都不是一款產品，也不是一個工具，而是一整套能力的合集。
甚至在實踐中還會出現業務輕量化困難、難以在秒級甚至毫秒級別擴容出業務實例；基礎設施響應能力不足導致服務發現和日志監控系統等問題。
進而帶來大量其他 web 服務器托管提供商可能會倒閉，很多 SaaS 平臺受到沖擊以及運維和實施人員的生存空間進一步縮小等行業現象。
但不容規避的一點，Serverless 架構的興起使“去服務器化”真正造福了開發者，讓基礎設施管理出現了新契機。
到此，相信大家對“Serverless 是什么”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
