歡迎光臨
每天分享高質量文章

我建議你瞭解一點兒Serverless

來自:碼農翻身(微信號:coderising)
一個新技術的出現不是無中生有,從石頭中憑空蹦出來的,而是在原有基礎上的繼承和發展。 

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的懷抱?

 

慢著!

 

為了達到上面的標的,你必須得犧牲一個很重要的東西:狀態

 

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

 

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

 

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

 

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

 

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

    已同步到看一看
    赞(0)

    分享創造快樂