轉角遇到你-Serverless

Serverless 最近幾年可謂是一個很是火熱的話題，尤爲在今年（2019），幾乎人人都聽過 Serverless。javascript

全部人都在說 Serverless，幾乎沒人知道怎麼落地 Serverless，可是你們都以爲其餘人都在作 Serverless，因而你們都在聲稱本身在作 Serverless。前端

這句話仍是我當時在螞蟻的時候聽到的，已經忘了是誰說的了，抱歉不能引用做者。java

既然這麼火，那麼什麼是 Serverless 呢？爲何要使用 Serverless？咱們該如何開始學習它？它是否是下一個技術的風口？這一系列的問題一直在困擾着我，想必你們也曾經想過。因而本身嘗試着去研究它，也嘗試着去幫助你們解惑。nginx

什麼是 Serverless

在 web 應用開發早期時代，想要構建 web 應用程序就須要有人去購買服務器硬件，而後在服務器上處理運維部署的事宜，這是一項很是繁瑣而昂貴的事情。再後來，雲出現了在咱們的視野中。能夠經過雲廠商購買固定的服務器資源，而後利用這些資源完成運維部署工做。可是通常狀況下，客戶們會爲了處理流程或業務高峯問題而超額購買一些服務器資源，雖然如今的雲產商提供了自動伸縮能力，可是這些服務器資源的利用率並不高，客戶依然在爲未使用的資源付費。git

無服務器計算（Serverless ）是一種新型的軟件架構。它的命名很奇怪，容易讓人產生誤解。Serverless 並非沒有服務器，只是服務器通常由雲服務器提供商來管理，開發人員無需關心。Serverless 可以提供用戶編寫和部署代碼，提供監控、定時、彈性伸縮等服務。Serverless 讓開發人員無需關心軟件的部署、運維細節以及底層基礎架構。開發人員只需專一於業務自己，將精力集中在爲用戶帶來價值的事情上。Serverless 客戶真正的按需付費，對於未使用的資源客戶不須要付一分錢還能保證服務正常運行。github

在提到 Serverless 時，有幾點須要咱們去了解：web

微服務（Microservices）

上面也說起到在過去咱們的研發模式比較單一，軟件架構也比較傳統簡單。通常一個項目的軟件架構由前端、服務端和數據庫組成。而隨着應用的複雜度上升，過去的應用架構已經開始制約着應用的發展，下圖簡單的描述了應用架構的演進。數據庫

微服務是一種軟件設計架構，微服務從設計上來說傾向於單一職責，每每將一個大型應用按照業務領域、職責劃分等拆分紅多個子服務。就像積木同樣，爲了搭建成一個完整的建築，須要衆多的積木來組合成複雜而龐大的建築。apache

微服務的優點：編程

**彈性：**因爲應用程序已分割，所以應用程序的一部分損壞或崩潰並不必定會影響其他的應用程序
**選擇性可伸縮性：**無需擴展整個應用程序，只能擴展得到大量使用的微服務
**易於添加或更新功能：**能夠一次推出或更新一個功能，而沒必要更新整個應用程序堆棧
**開發人員的靈活性：**微服務能夠用不一樣的語言編寫，而且每種都有本身的庫

爲何須要在 Serverless 中說起微服務。雖然微服務有多種部署方式，可是將微服務部署在 Serverless 中才能將優點體現的很明顯，微服務僅在應用程序須要它們時才運行，而且自然支持彈性伸縮。咱們還能夠根據微服務的大小，分解成爲更小的函數（FaaS）。

函數即服務（FaaS）

在 Serverless 架構裏，FaaS 是一項很重要的技術。它改變了傳統架構的服務模式，Faas 的粒度變爲了函數級別，一個函數即一個服務。可是函數一般是運行在無狀態容器中，這意味着沒法保持狀態，沒法在函數中使用以前的執行上下文，並且函數的執行時間是有限制的，像 AWS Lambda 函數能夠配置爲每次執行最長運行 15 分鐘，因此這也是 FaaS 的限制所在，也就意味着不能執行耗時的任務。 Faas 的執行時機是基於事件觸發的，至於事件的種類依賴於雲廠商，HTTP 觸發器是最多見也是使用最多的一種。FaaS 的運行時如今各大雲廠商提供的也挺多，例如 Node.js、Python、Go、Java 等等。

例如咱們實現一個 helloworld 函數，你只須要在 Serverless 平臺中上傳這份代碼片斷，就能夠經過觸發器來完成執行。執行完畢後直接輸出 hello world!，真的是太方便了。

module.exports = {
  foo: function (event, context) {
    return 'hello world!';
  }
}

複製代碼

上述代碼可經過該連接訪問。

後端即服務（BaaS）

BaaS 做爲在 Serverless 架構裏另一項重要的技術，旨在提供業務依賴的服務，例如數據庫、消息通知等服務。這些 BaaS 服務通常由雲廠商提供，像被谷歌收購的的數據庫服務 FireBase 以及身份驗證 Auth0。配合 FaaS，能夠輕鬆完成業務開發。BaaS 提供基礎服務，FaaS 負責業務邏輯組合，組織 BaaS 基礎服務，相互協做，相互配合，真正的讓開發人員只關心本身的業務。

例如咱們想要實現個文件上傳服務，在過去，咱們須要創建數據庫、配置存儲空間、編寫服務端代碼等等，複雜狀況還須要考慮分佈式存儲、併發等等狀況。在 Serverless 中，咱們只須要寫一個 FaaS 來完成文件上傳這個事件，而後文件存儲調用 BaaS 對象雲存儲服務 SDK ，再配合數據庫存儲 BaaS 服務 SDK，完成這樣常見的文件上傳服務。結合這個流程來看其實真正咱們作的工做就是編寫 FaaS，大大減輕了開發的負擔，縮短了研發週期。並且還不用考慮存儲併發等等問題，由於 Serverless 幫助咱們作了這些。

正常狀況下 BaaS 提供商可以提供如下功能，例如：

數據庫管理
雲存儲
用戶認證
推送通知
遠程更新

冷啓動（Cold Start）

因爲函數是運行在容器中的，所以啓動容器須要必定的時間，這也被稱爲冷啓動。通常當你的函數執行完畢，容器通常會保留一段時間（AWS Lambda 爲 5 分鐘），若是在這段時間內沒有新的事件請求過來，這個容器將被銷燬掉。

冷啓動的持續時間取決於特定雲服務商的實現。在 AWS Lambda 上，它的範圍從幾百毫秒到幾秒不等。它可能取決於使用的運行時（或編程語言）、函數（以包的形式）的大小，固然，還取決於所討論的雲服務商。多年以來，隨着雲服務商在優化時延方面變得愈來愈出色，冷啓動已經大爲改善。

熱啓動（Warm Start）

上面提到了冷啓動，那麼就有對應的熱啓動，熱啓動在 Serverless 中指的是函數容器冷啓動後在限制的時間內

依然保持啓動狀態不被銷燬，來了新的事件請求後可以立馬提供服務。一般咱們能夠利用一些小技巧，例如經過定時器每隔幾分鐘來觸發一個事件，使得咱們對應的函數可以繼續被執行，可以保持運行狀態。

API 網關（API Gateway）

API Gateway 在微服務領域是個必備的技術。它可以處理全部來自客戶端的請求，而後根據網關配置，轉換和轉發請求到合適的微服務。在 Serverless 架構裏面，因爲都是 FaaS，不能直接對外服務。前面說到 FaaS 是基於事件機制，事件有不少觸發器，最多見的就是 HTTP 觸發器。那麼這麼多的 FaaS 服務若是想要以 HTTP 對外服務，那麼就須要網關的配合了。就像在微服務領域同樣，網關負責將各種 FaaS 服務的觸發器捆綁，繼而向外暴露安全服務。

爲何要用 Serverless

到目前爲止，我嘗試着解釋了下 Serverless 架構的一些知識點。如今，咱們未來從 Serverless 的優缺點來一塊兒探討下咱們爲何要用 Serverless。

與傳統的基於雲或以服務器爲中心的基礎架構相比，Serverless 具備不少優點。對於開發人員而言，Serverless 提供了更大的靈活性以及更快的發佈時間。藉助 Serverless，開發人員無需擔憂購買，供應和管理後端服務器。可是，無服務器計算並非全部 Web 應用程序開發人員的靈丹妙藥。對於企業而言，Serverless 這種按需收費模式將爲企業節省很大一筆的資金，尤爲對於創業型企業來說，能夠將資金放到最關鍵的創造用戶價值的事情上去。

優勢

下降運維成本

在當前的開發模式下，運維人員須要處理各類繁瑣的事情，例如數據庫維護、服務器管理等等。在 Serverless 架構下，雖然程序仍是跑在服務器上，但運維人員是無需去管理這些服務的，這些事情將交給雲產商管理。這能夠減小在運維中的資金投入，從而下降支出，還可使開發人員騰出時間來建立和擴展其應用程序而不受服務器容量的限制。

使用 Serverless 架構，減少了部署發佈的難度、縮短了部署的時間。運維人員無需發佈代碼到服務器進行配置便可發佈新版本，轉而向雲產商上傳代碼片斷，這是一種思惟上的轉變。

下降開發成本

開發系統一般最麻煩的事情是配置開發環境，而在 Serverless 架構中，你只須要一個能夠文本編輯器或者只須要一個瀏覽器。最方便快捷的是使用雲廠商提供的雲端編輯器，你只須要在編輯器中編寫函數便可。編輯完成後通常 Serverless 雲廠商提供了部署相關的按鈕，點擊它便可完成函數的部署。在將來的雲端 IDE 編程時代，這也將是一個極大的吸引點。

由於是 FaaS，運行時和開發語言也沒什麼限制，團隊在招人技術棧方面也不須要花費更多的精力，能夠直接面向業務，也無需關心複雜的系統架構，這樣給與了前端開發人員更多的領域涉及的可能。

在系統的更新迭代上，開發人員能夠根據更新的內容選擇更新部分函數，更新完成後只須要部署這個更新的函數而不須要從新部署整個系統，沒必要對整個系統進行更改。

結合 BaaS 服務後，開發一個應用程序將會變得更爲簡單高效，那些通用的能力交給第三方去管理，縮短的開發時間週期放到更爲緊要的事情上去，尤爲在創業型互聯網企業中來說，時間就是金錢，更快的上線對他們來說是相當重要的。

下降拓展成本

Serverless 架構的另外一優勢就是水平拓展是徹底自動的、彈性的而且這種行爲是由雲廠商提供的。這個特性很直接的好處是咱們真的是按需付費。

舉個例子，假設咱們有一個應用程序每分鐘有 1 個請求，若是咱們有 10 臺機器作爲集羣，每臺機器處理每一個請求的平均 CPU 利用率爲 1%。那麼站在機器利用率的角度來說，一萬個相似的應用程序能夠跑在這 10 臺機器中，可是如今很明顯的是利用率極低。這是一種假想的情形，實際上你可能考慮會下架掉其餘機器，以保證經濟成本。

可是咱們來換一種場景，咱們的運營們上線了一個營銷活動，這個活動持續的時間是 1 天，帶來的結果是如今每分鐘有 100 請求，如今的壓力是之前的 100 倍。在傳統情形中，處於提早應對峯值的考慮，咱們須要提早將硬件總數提高到當前的 100 倍，假設爲 1000 臺，而後就是須要部署下這 1000 臺機器作爲集羣。這其中的工做量以及成本都是很是之大。當活動結束後，這些剩餘的計算能力將是一筆巨大的浪費，還須要處理下架的機器。

固然如今的雲廠商也提供了自動縮放的能力，可是也有着它的缺陷，就是這些自動縮放的機器可能須要很長的時間來啓動和註冊，可能會錯太高峯時間。

可是在 Serverless 架構中，因爲 Serverless 具備天生的水平拓展能力，這將再也不是一個問題。從上面的示例來看，很明顯有一個特色，就是流量的不穩定，存在流量的波峯和波谷。在波峯時，Serverless FaaS 會自動拓展，幫助應用度太高峯期流量。波谷時，在 FaaS 中咱們提到，FaaS 容器會必定時間內若是沒有請求過來，將會釋放掉該容器，以保證資源不被浪費。基於此，Serverless 能夠幫助咱們節省一筆資金，還能平穩度過流量高峯。

若是你的應用流量一直很平穩，可以充分利用硬件資源，那可能 Serverless 不是你很好的選擇，因此須要你很好的進行評判與計算，選擇最適合本身業務的解決方案。

缺點

雲廠商鎖定

在應用初期，你極可能是選擇一個特定的雲廠商來做爲 Serverless 提供商。初期的架構設計都依賴於特定的雲廠商，因爲各大雲廠商的設計方案不一致，若是要更換雲廠商，也就意味着須要修改代碼以適應雲廠商之間的差別。這將又會是一個成本的問題。

即便在軟件設計前期考慮了多個雲廠商，可是一旦受到某個廠商的變動的影響，仍是會存在遷移的成本，如此一來，很大可能就會被雲廠商鎖死。

在將來，隨着 Serverless 的發展，各大雲廠商一定會根據規範來讓客戶能夠平滑遷移，達成一致的使用體驗。

安全性

在使用 Serverless 也會帶來一些安全問題，知道這些潛在的安全問題也會讓咱們更好的去使用 Serverless 從而能夠避開一些風險。

將源碼部署到雲廠商服務器而不是公司的私有服務器這自己就會有安全隱患，固然這不是 Serverless 獨有的問題。因此在雲廠商選型時，咱們應當選擇可靠的雲廠商，例如阿里雲、亞馬遜等等。另一個問題是雲廠商並不會給客戶單獨分配機器，而是以多租戶的模式來運行。多租戶模式可能會影響應用的性能，若是雲廠商的多租戶配置不合理可能會致使客戶的數據泄露。

使用 Serverless 將會和傳統的應用架構的安全性有所區別，一些安全的訪問將直接遷移到雲廠商提供的安全平臺上，這可能也會形成一些潛在的風險，須要特別注意下。

Serverless 的適用場景

在談論 Serverless 的適用場景以前，咱們仍是要回顧下 Serverless 的特性。在文章前面部分咱們有向你們介紹過 FaaS。前面有介紹到 FaaS 的執行時機是基於事件觸發的而且函數的執行時間是有限制的，那麼綜合考慮這兩點，咱們能夠想象下當今哪些業務場景是此中類型的。

咱們很容易就想到 IoT、消息通知、定時任務、圖像處理等等。很明顯針對須要長時間通訊的場景 Serverless 並不適用。

前面咱們有講到 HTTP 觸發器是 FaaS 事件觸發最多見的一種，那麼和 HTTP 相關的又符合上面兩點的業務那是最合適不過了，例如 RESTful API、SSR 服務和 BFF。

另外最值得一提的一種業務場景就是小程序。雖然叫小程序，可是一個穩定的小程序對於後端的整個架構而言幾乎是五臟俱全。本身去搭建這樣一套架構不是一件輕鬆的事情，而 Serverless 就能夠幫助咱們解決這些棘手的問題，提供 FaaS、雲存儲等等服務，可以快速幫助小程序上線。並且不擔憂前期服務器費用，按量付費模式，減輕開發門檻，下降開發成本，就能夠更專一於產品打造。我相信有了 Serverless 的輔助，將來會有更多更好用的小程序會上架。其實相似小程序場景均可以藉助於 Serverless 快速上線產品、快速變現。在今年，阿里雲和騰訊雲都相繼推出了小程序 Serverless，這也能夠看出各廠商對於 Serverless 的重視，其中騰訊雲今年還與 serverless.com 達成戰略合做成爲大中華區獨家合做夥伴。

開源 Serverless 產品

kubeless

kubeless 是基於 k8s 原生的無服務器框架，可以讓您部署少許代碼而沒必要擔憂基礎架構的問題。

fission

fission 是基於 k8s 的快速無服務器框架，專一於開發人員的生產力和高性能。

OpenWhisk

OpenWhisk 是一種雲優先的基於事件的分佈式編程服務。它提供了一種編程模型，可將事件處理程序上傳到雲服務，並註冊處理程序以響應各類事件。

案例

notes.devops.godotdotdot.com