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

我建議你瞭解一點兒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)

    分享創造快樂