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

[[262656]]

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

局域網時代

上世紀90年代，你是一家IT部門的負責人，公司需要建立一個信息管理系統，

這時候的系統都是局域網的， 是C/S模式的， 業務邏輯主要在客戶端軟件中， 需要被安裝到各個電腦上去，然后訪問同一個數據庫。

 

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

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

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

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

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

 

數據中心

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

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

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

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

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

 

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

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

虛擬化

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

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

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

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

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

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

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

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

理想模式

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

1. 不要再考慮什么物理服務器/虛擬機了， 把代碼上傳到云端，直接運行。
2. 按使用情況(如CPU時間、內存大小)來收費

(IBM： 我的大機一直按使用情況收費，你們玩了幾十年，終于回到我這里了 ^-^)

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

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

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

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

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

 

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

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

Serverless 的特點

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

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

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

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

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

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

如果有多個函數，怎么確定調用哪一個? 肯定需要一個東西來轉發一下。

(微服務： 我就是這么玩兒的啊!)

 

如果業務比較復雜，一個函數搞不定怎么辦? 可以把多個函數給編排起來!

(SOA： 我早就這么做了!)

 

按需裝載，自動伸縮，不用你苦逼地去規劃硬件，安裝軟件，還可以按照使用情況付費，這么好的東西，我們是不是馬上投入serverless的懷抱?

慢著!

為了達到上面的目標，你必須得犧牲一個很重要的東西：狀態。

函數沒有狀態的，每次啟動都可能會被部署到一個全新的“服務器”中，這就有兩個問題：

• 用戶的會話狀態肯定是無法保持的，像session sticky 這樣的功能就別想了。
• 函數無法做本地的持久化，沒法訪問本地硬盤的任何東西(服務器看不見了，怎么能看見硬盤呢?)。

所有想持久化的東西必須得保存到外部的系統或者存儲中，例如Redis，MySQL等。 很明顯，這些東西也應該以“服務”的方式來呈現，即Backend as a Service (BaaS)。

如果你的應用無法拆分成無狀態的函數，是無法享受Serverless帶來的種種好處的。

Serverless更適合那些無狀態的應用，例如圖像和視頻的加工，轉換， 物聯網設備狀態的信息處理等等。

【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】

 

戳這里，看該作者更多好文