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

[[262656]]

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

局域網時代

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

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

 

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

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

買服務器，安裝操作系統(tǒng)，比如Window NT

安裝數(shù)據庫軟件，例如Oracle。

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

 

數(shù)據中心

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

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

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

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

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

 

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

總之，運維這樣一套系統(tǒng)，非常麻煩。

虛擬化

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

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

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

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

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

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

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

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

理想模式

想必你的腦海中已經浮現(xiàn)出了解決方案：

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

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

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

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

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

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

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

 

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

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

Serverless 的特點

Serverless的開發(fā)模式和運行模式類似這樣：

1. 程序員編寫完成業(yè)務的函數(shù)代碼

2. 上傳到支持Serverless的平臺，設定觸發(fā)的規(guī)則。

3. 請求到來，Serverless平臺根據觸發(fā)規(guī)則加載函數(shù)，創(chuàng)建函數(shù)實例，運行

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

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

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

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

 

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

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

 

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

慢著!

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

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

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

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

如果你的應用無法拆分成無狀態(tài)的函數(shù)，是無法享受Serverless帶來的種種好處的。

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

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

 

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