"有些鳥兒是關不住的，因為它們的羽翼太過耀眼。"——肖申克的救贖

Serverless 絕對是近兩年最火的詞之一，伯克利論斷它是雲時代的主宰，阿里高級前端專家說它正在顛覆以往的開發模式，騰訊高級前端工程師說它將引發前端的第三次變革。

到底什麼是Serverless呢？

Serverless，直譯過來就是無服務器，它是一種軟件系統架構思想和方法。它的核心思想是讓用戶無須關注支撐應用服務運行的底層資源，比如：CPU、內存和數據庫等，只需要關注自己的業務開發即可。

由於 Serverless 計算在工程效率等方面顛覆式的體驗，迅速成為業界的熱點，被大量的企業和開發者採用。

下面是一份騰訊雲對 Serverless 目前的發展情況統計。

最近幾年，微服務和k8s很火。上圖可以看到Serverless跟他們的熱度對比，其中藍色曲線是Serverless的熱度曲線圖。從2016年開始，Serverless的熱度是要大於微服務和k8s的。

Serverless最初在2010年被提出，2014年AWS推出了lambda服務，把 Serverless產品化，並收到了很好的效果，微軟、Google和IBM看到後，也分別在2016年推出了自己的Serverless產品：Azure function、GCP 和 OpenWisk。阿里雲和騰訊雲也分別在2017年推出了自己的Serverless產品，騰訊雲要早阿里雲一天推出。

01 直觀理解Serverless

我們明白了Serverless大概是什麼，下面這篇“碼農翻身”劉欣老師的文章，會讓我們理解得更加清晰透徹。

原文請戳：我建議你瞭解一點兒Serverless

一個新技術的出現不是無中生有，從石頭中憑空蹦出來的，而是在原有基礎上的繼承和發展。

Serverless也不例外，我們回顧下IT基礎設施的發展就會發現，Serverless自然就會浮現出來，你自己就可以發明它（但是卻實現不了它）。

1. 局域網時代

上世紀90年代，你是一家IT部門的負責人，公司需要建立一個信息管理系統，這時候的系統都是局域網的， 是C/S模式的， 業務邏輯主要在客戶端軟件中， 需要被安裝到各個電腦上去，然後訪問同一個數據庫。

C/S模式就是指客戶端/服務器模式，是計算機軟件協同工作的一種模式。

在部署這個系統之前，你需要做很多的工作：

搭建局域網， 購買交換機，路由器。

買服務器，安裝操作系統，比如Window NT。

安裝數據庫軟件，例如Oracle。

然後再把那些Delphi/VB/PowerBuilder寫的客戶端安裝到電腦上, 整個系統跑起來了。

2. 數據中心

C/S模式的很大弊端就是客戶端更新特別麻煩，服務器能支撐的用戶也不大。

Web興起後，你們公司的應用也與時俱進，從C/S模式變成了B/S模式，用戶主要使用瀏覽器來訪問應用，業務邏輯在服務器端運行。

這時候，你還需要買服務器，然後放到數據中心去託管，畢竟那裡的條件更好，更穩定。

網絡不需要自己來搭建了， 掏錢買數據中心的網絡帶寬就好。還需要自己安裝軟件，比如Linux操作系統，Tomcat，Ngnix，MySQL等等。

隨著功能的增加，你還需要新的服務器來處理緩存，搜索等功能。為了應對高併發，還需要分佈式，負載均衡，數據複製。

你需要仔細地規劃，看看這些緩存，搜索，數據庫，負載均衡等都需要什麼樣的服務器，有些要求CPU很強，有些要求內存很大，有些要求硬盤很快。

總之，運維這樣一套系統，非常麻煩。

3. 虛擬化

但是，如果你的網站沒人訪問了，這一套複雜的系統，這些昂貴的服務器就會變成擺設，你想賣都很難賣掉，這是巨大的浪費。

一個想法就會浮現出來：為什麼要用物理服務器？ 誰要是能提供虛擬機給我就好了！ 用完了就可以“扔掉”！

於是那些有實力的大廠就這麼做了，把這些物理服務器的計算能力，存儲能力統一管理，統一調配，對外提供的就是虛擬機。

他們把這種方式叫做雲計算，你使用了雲計算以後，有很多好處：

物理服務器不用買了，申請虛擬機就可以了。什麼樣的CPU，多少內存，多大的硬盤，對應的價格也不同。

操作系統會按照你的要求自動給你安裝好。網絡自然不用操心，要多大帶寬直接買就行。

對於PaaS來講，連運行時環境都安裝好了，直接使用就行。

這些虛擬機可以包月，包年計費。但是，如果沒有人訪問你的應用，沒有流量，你也得掏錢。

4. 理想模式

想必你的腦海中已經浮現出瞭解決方案：

不要再考慮什麼物理服務器/虛擬機了， 把代碼上傳到雲端，直接運行。

按使用情況（如CPU時間、內存大小）來收費。

（IBM： 我的大機一直按使用情況收費，你們玩了幾十年，終於回到我這裡了 ^-^）

如果沒有人訪問你的應用，就不要部署它，這樣只會佔用一點點存儲空間，不用使用CPU和內存；如果有人訪問，把應用部署到某個服務器上，執行這次請求，返回給用戶，然後卸載這個應用。

和之前的方式相比，最大的特色是即用即走，不會在服務器/虛擬機中常駐。

但是這麼做可能嗎？ 不行！應用的粒度太大，一個應用幾十，上百模塊，每個請求來了就部署整個應用，只執行那麼一點兒代碼， 然後就卸載掉。 如果每個請求這麼來回地部署和卸載，你是瘋了嗎，兄弟？

那微服務呢？粒度還是太大 ！ 如果是微服務中的一個API，或者說就是一個“函數”呢？ 這個粒度應該差不多了。

這裡說的函數到底是什麼？ 需要看具體的業務來劃分，比如搜索產品，圖像轉換，它需要足夠小，足夠單一，能快速啟動，運行，卸載。

一個“函數”真的只做一件事情，並且不保持狀態。 這樣一來它可以輕鬆地被擴展到任意多的服務器/虛擬機/docker容器中去。請求多了就擴容，請求少了，就收縮，請求沒了，就卸載，實在是太爽了。

這種方式現在稱為Serverless，並不是說沒有服務器，而是說服務器對用戶來說是透明的。應用的裝載、啟動、卸載，路由是需要平臺來搞定。

Serverless的開發模式和運行模式類似這樣：

1. 程序員編寫完成業務的函數代碼

2. 上傳到支持Serverless的平臺，設定觸發的規則

3. 請求到來，Serverless平臺根據觸發規則加載函數，創建函數實例，運行

4. 如果請求比較多，會進行實例的擴展，如果請求較少，就進行實例的收縮

5. 如果無人訪問，卸載函數實例

02 瞭解Serverless架構

Serverless架構或者Serverless工程的核心思想是函數即服務。從技術角度來講，互聯網上最準確的 “Serverless計算” 的定義如下：

“Serverless計算又稱為函數即服務（FAAS），它是一種雲計算和代碼執行模型，其中雲提供商管理函數的容器——平臺即服務（PaaS）——的啟動和停止。”

定義中的“函數即服務”，就是說任何Serverless模型都有一個在雲平臺上運行的函數。這些函數只不過是代碼塊，它們的執行取決於與之相關聯的觸發器。

下圖展示了AWS Lambda環境中的所有觸發器。

只要有觸發器觸發了某個函數，雲平臺就會啟動一個容器，用來執行該函數。一旦該函數執行成功並返回結果，或者運行超時，那麼運行該函數的容器就將被雲平臺回收或者銷燬。在高負載的情況下，或者當兩個觸發器之間幾乎存在時間間隔時，這種回收機制使得容器能夠被重複利用。

定義中的“函數的容器”，就是說函數在容器中啟動和執行。

Docker公司將“容器”的概念發揚光大，它對“容器”的標準定義為：

“容器映像是一個輕量級、獨立且可執行的軟件包，其中包含了軟件運行所需的一切：代碼、運行時、系統工具、系統庫、設置。”

容器的作用是將函數的代碼、運行時環境等打包到單個部署包中，以實現無縫執行。部署包中包含了該函數的主代碼文件，以及執行該函數所需的所有非標準庫。部署包的創建過程與Python虛擬環境的創建過程非常相似。

因此，我們可以明確地指出，對於採用Serverless架構的應用程序，其服務器不會一直運行。

03 Serverless常見誤解

由於Serverless架構以函數即服務的形式運行，而函數由一組可用的觸發器來觸發，所以Serverless架構經常被用作實時系統。

但是，單純將Serverless架構看作實時系統是一種常見的誤解，因為Serverless系統除了可用作實時系統之外，也適用於批處理架構。

並不是所有的研發團隊都需要使用或者擁有實時系統，因此學會將Serverless系統用作批處理架構會給研發團隊帶來更多的可能性。

可以通過如下方式將Serverless系統用作批處理架構：

• 觸發器的cron功能
• 隊列

首先來了解一下觸發器的cron功能。

我們可以在雲平臺的Serverless系統中設置監控器，將監控器設置為一個普通的cron任務，該監控器便會每隔幾分鐘或者幾小時觸發一次觸發器。這有助於把Serverless配置為cron批處理任務。在AWS環境中，Lambda可以通過AWS CloudWatch作為cron觸發，為此，可以手動輸入時間間隔來設置cron任務的頻率，也可以在cron格式中選擇間隔。

還可以利用隊列來構建Serverless批處理架構。讓我們設置一個示例數據管道，以此來理解隊列的概念。假設我們要構建一個系統來執行以下任務。

1. 用戶或者服務將一些數據發送到數據庫或者更簡單的數據存儲系統中，例如AWS的S3
2. 一旦數據存儲系統中的文件數量超過100，就執行一項任務。比如，對文件進行一些分析，例如計算文件的總頁數

該系統可以通過隊列來實現。這個例子是一個相對簡單的Serverless系統。它可以通過以下方式實現。

1. 用戶或者服務將數據上傳或者發送到我們選好的數據存儲系統中。
2. 為這個任務配置一個隊列。
3. 為S3存儲桶或者數據存儲系統配置一個事件，這樣，只要有數據進來，就向上一步配置的隊列中發送消息。
4. 設置監控系統以監控隊列中的消息數量。建議你使用雲提供商的監控系統，以便保持系統完全Serverless化。
5. 為監控系統設置告警，並配置告警閾值。例如，一旦隊列中的消息數量達到或者超過100就觸發告警。
6. 該告警可以扮演Lambda函數觸發器的角色。Lambda函數首先接收隊列消息，然後使用消息中的文件名來查詢數據存儲系統，以此對文件進行分析。
7. 文件由Lambda函數分析之後，將被髮送到另外一個數據存儲系統中存放。
8. 所有任務完成之後，運行Lambda函數的容器或者服務器將自動終止，因此整個傳輸流程完全Serverless化。

04 Serverless優缺點

我們需要了解Serverless系統的優缺點，以便軟件開發人員和架構師決定何時在現有系統中利用Serverless範式。

Serverless系統的優點如下。

• 降低了運營成本：部署了Serverless系統，服務器就不再需要晝夜不停地運轉，因此設備成本得以大幅縮減。當函數被觸發時服務器才會啟動，而當函數執行完畢時服務器會自動停止，因此用戶只需為函數運行的時間段付費。
• 減少了維護工作：鑑於以上情況，我們不再需要對服務器進行持續不斷的監控和維護。由於函數和觸發器高度自動化，因此Serverless系統幾乎不需要維護。
• 提升了開發效率：由於開發人員不需要操心服務器的維護工作以及宕機情況的發生，因而可以專注於提升軟件質量的相關工作，例如擴展和設計功能。

Serverless系統的缺點：

• 函數運行有時限：無論是AWS Lambda還是GCP雲，其函數運行時長的上限都是5分鐘，這使得計算密集型的任務變得難以運行。為了解決這個問題，可以用nohup模式來執行配置工具的腳本。然而，配置腳本、設置容器以及其他工作也必須在5分鐘內完成。一旦超過5分鐘的時限，容器便會自動終止。
• 無法控制容器環境：開發人員無法控制用來執行函數的容器環境。操作系統、文件系統等均由雲供應商一手掌控。比如，執行AWS Lambda函數的容器運行著亞馬遜的Linux操作系統。
• 缺乏對容器的監控：雲提供商通過其內部監控工具為用戶提供了基本的監控功能，除此之外，沒有為執行Serverless函數的容器提供詳細監控服務的其他機制。當擴展Serverless系統以適應分佈式系統時，監控工作將變得更為艱難。
• 無法控制安全性：由於缺乏對容器環境的監控，所以無法保證數據流的安全性。但是，容器可以在開發人員選擇的VPC和子網中運行，這有助於解決該問題。

然而，Serverless系統可以擴展到執行大規模計算的分佈式系統中，此時開發人員不必擔心時限問題。

05 Serverless注意事項

為了直觀地瞭解如何在單個整體式系統上選擇Serverless系統來執行大規模計算，讓我們看看在做這種架構決策時需要注意的重要事項。

將Serverless系統擴展到分佈式系統時的注意事項如下。

• 要想將Serverless系統擴展到Serverless的分佈式系統，需要知道nohup的運行方法。它是一個允許程序和進程在後臺運行的POSIX命令。
• 正確記錄nohup進程的日誌，包括輸出日誌和錯誤日誌。進程的所有信息都應記錄在日誌中。
• 需要一個配置工具，例如Ansible、Chef或者類似工具，用來創建一個master-worker架構，並在執行Serverless函數的容器中以nohup模式運行它。
• 對於所有由配置工具的master服務器執行的任務，需要進行正確的監控並記錄其日誌，因為一旦所有設置執行完畢，就無法獲取其日誌了。
• 使用雲提供商的臨時憑證工具來適當保證安全性。
• 應確保系統正確關閉。所有的worker及master任務在執行完成之後應當立即自行終止。這一點非常重要，它是保證系統Serverless化的關鍵。
• 通常，大多數環境中臨時憑證的有效期為3600秒。因此，如果開發人員使用臨時憑證執行任務的時間超過憑證的有效期，那麼憑證就存在過期的風險。
• 調試分佈式Serverless系統是一項非常困難的任務，原因如下。1. 監控和調試nohup進程非常困難。其調試方法有兩種：一種是參考進程創建的日誌文件，另一種是通過進程ID將nohup進程殺死，然後手動運行腳本進行調試。
• 2. 由於所有任務在配置工具中按順序執行，因此任務實例存在被終止的風險，原因是開發人員在調試進程之前可能會忘記殺死nohup進程。
• 3. 因為這是一個分佈式系統，所以毫無疑問，該架構在任何失敗或者出錯的情況都應當能夠自我修復。一個示例場景是：一個worker任務在對一堆文件執行某種操作時發生了崩潰，導致所有文件都丟失了，而且沒有辦法恢復。
• 4. 另一個更嚴重的災難場景是兩個worker任務在操作文件時發生崩潰。在這種情況下，開發人員並不知道哪些文件已成功執行，哪些沒有。
• 確保所有worker任務獲得相同數量的負載是一種很好的做法，這可以實現分佈式系統的負載均衡，同時使得時間和資源得到很好的優化

06 類似架構（微服務）的優缺點

與Serverless的概念類似，面向微服務的設計策略最近也非常流行。這種架構設計在Serverless的概念出現以前就已經存在很長時間了。就像我們試圖通過互聯網上的技術定義來理解Serverless架構一樣，我們也應通過互聯網上的技術定義來理解微服務。微服務的技術定義如下：

“微服務又稱為微服務架構，它是一種架構風格，將應用程序構建為一組松耦合的服務，以實現業務功能。”

與Serverless架構一樣，規劃和設計微服務形式的架構同樣有利有弊。我們要熟知微服務架構的優缺點，以便使用時能夠揚長避短。在闡述微服務的缺點之前，先來看看它的優點。

微服務能夠幫助軟件團隊保持敏捷和逐步改進。簡單來說，由於各個服務之間彼此分離，因此升級和改進一項服務非常容易，並且不會導致其他服務崩潰。例如，在社交網絡軟件中，如果聊天和訂閱功能都是微服務，那麼當軟件團隊嘗試升級或者修復聊天服務時，訂閱服務完全不會受影響。然而，在大型整體式系統中，很難像微服務那樣將功能獨立開來。因此，在整體式架構中，即使是一個小組件的修復或者升級都會導致所有服務的停止，而修復所需的時間也往往超出預期。

整體式架構的代碼量非常龐大，任何一個小故障都會影響整個系統的運轉。微服務則對代碼進行了精簡和細分，從而極大地提升了開發人員的工作效率。開發人員可以在開銷極小甚至為零並且不需要停機的情況下修復和改進服務。容器可以讓我們更好地利用微服務，它提供了有效且完整的虛擬操作系統環境，能夠隔離進程，並且提供底層硬件資源的專屬訪問權限。

當然，微服務也有缺點，其中最主要的一點是，它依賴分佈式系統。由於各個服務之間是相互獨立的，所以架構師需要弄清楚各個服務之間的交互方式，從而構建出功能完整的產品。因此，服務之間的交互方式，以及它們之間數據的傳輸策略，都是架構師需要認真考慮的問題。分佈式系統的主要問題，比如共識、CAP定理、維持共識的穩定性以及連接，都是工程師在構建微服務時需要處理的問題。確保和維護安全性也是分佈式系統和微服務中的主要問題。你需要為每個微服務制定單獨的安全模式和層級，還需要為服務之間的數據交互制定安全策略。

本文中，我們瞭解了什麼是Serverless。最重要的是，知道了如何判斷Serverless能否為其團隊或項目所用，以及如何從現有基礎設施轉換或者遷移到Serverless範式。

我們還研究了微服務範式及其如何幫助實現輕量級和高度敏捷的架構，並且詳細介紹了團隊何時應該考慮採用微服務，以及何時可以將其現有的整體式服務遷移到或者分解為微服務等。

想繼續深入學習，可以閱讀下面這本書，上面大部分內容來源於這本書。

《Serverless架構應用開發：Python實現》

作者：[印] Jalem Raj Rohit

手把手教你用 Python 建立

無須專人託管的服務器

本書主要基於雲架構的Python示例來講解Serverless的概念。

本書採用目前流行的Python語言，通過雲架構中的示例，手把手教你在AWS和微軟Azure Functions中構建Serverless架構、部署Serverless API、處理日誌和監控、將Lambda函數部署為基礎設施即代碼，等等。本書還詳細介紹了VPC和SAM等技巧。

本書分為三個模塊：第一個模塊解釋Serverless架構的基本原理以及AWS lambda函數的作用；第二個模塊教你構建、發佈並部署應用到生產環境；第三個模塊將帶領你完成高級主題，例如為應用構建Serverless API。你還將學習如何擴展Serverless應用並處理生產中的分佈式Serverless系統。在本書的最後，你將能夠使用Serverless框架構建可擴展的高效Python應用程序。

https://www.ituring.com.cn/book/tupubarticle/27778

https://www.infoq.cn/article/SZzkUKeqdxpP5FkNPZOQ

https://blog.csdn.net/cpongo3/article/details/89026731

https://mp.weixin.qq.com/s/k0RVMNhBa-VS6IHHuZ1CNQ

https://zhuanlan.zhihu.com/p/84054729