Serverless 架構落地實踐及案例解析

語言: CN / TW / HK

簡介: 技術演進的本質是更好服務業務,傳統開發方式使企業花費更多的精力打磨底層技術細節,而 Serverless 架構就是讓開發者專注業務實現從而創造更大的業務價值。

作者 | 丹坤
整理 | 徐詩瑤
出品 | CSDN 雲原生

網際網路軟體架構演進

我們先簡單回顧下網際網路軟體架構的演進之路。

單機部署

在單機部署中,將所有的業務和資料庫都部署在一臺主機中。

此架構的優點是:開發、部署以及運維都非常簡單。缺點是:一旦遇到流量過大或者機器故障,整個系統癱瘓,甚至丟失業務資料,造成巨大業務損失。

叢集化部署

針對上述架構問題,常用的解決方案是採取水平擴容的方式進行叢集化部署。引入 SLB 的流量閘道器路由,進行負載均衡。叢集化部署本質上是單體架構,開發人員在專案開發的時候需要額外注意,比如要使用 cookie 進行鑑權,session 就不能儲存在本地,需要引入 Redis 進行單獨儲存。叢集化部署可以通過快速水平擴容解決流量突增或機器故障的問題。

微服務拆分

隨著業務的發展以及團隊規模的擴張,單體架構這樣緊耦合的方式會帶來越來越多的問題,架構的靈活性和可擴充套件性成為阻礙業務發展的重大挑戰。微服務架構應運而生。

對比單體架構,微服務架構遠比其複雜,也衍生了很多新技術,比如:API 閘道器、服務註冊、服務發現、RPC 通訊。

Serverless 架構

從單體架構到微服務架構,從單機部署到叢集化部署,網際網路軟體架構越來越複雜,公司需要投入大量精力和成本進行底層技術的升級和維護。下圖是 Serverless 架構,和單體架構不同的是將對應的元件換成 Serverless 雲產品。


技術演進的本質是更好服務業務,傳統開發方式使企業花費更多的精力打磨底層技術細節,而 Serverless 架構就是讓開發者專注業務實現從而創造更大的業務價值。

Serverless 架構的優勢很明顯:

●不關注底層基礎設施,專注業務價值創造

●自動彈性,從容面對突增流量

●按資源使用計費,避免資源閒置浪費Serverless 架構探討先來看一下 FaaS 的執行過程。藍色部分是使用者手動管理,只需要交付程式碼,其他的啟動、執行、運維等都是在 FaaS 平臺進行。

但是此架構會產生一些問題:

●程式碼碎片化,無法統一管理和部署

●本地環境和線上環境不一致,無法處理依賴相容性問題

●進行本地 Debug 和線上除錯困難

●FaaS 廠商對程式碼包有限制,無法部署大程式碼包

●沒有統一的標準,導致廠商鎖定問題Serverless Devs針對上述問題,Serverless Devs 可以幫助開發者更好地開發管理 Serverless 應用

它具備以下幾個特點:

●無廠商鎖定,Serverless Devs 幫助開發者將應用部署在各個廠商上面

●開源開放,程式碼邏輯無任何黑洞

●功能可插撥,Serverless Devs 通過元件的形式提供,開發者完全可以根據需求,快速開發適合自己的工具套件

●專案全生命週期管理能力,Serverless Devs 是使用者進行專案初始化建立、開發、除錯、部署等全生命週期管理的工具,簡化 Serverless 應用開發如果說 Serverless 架構可以幫助開發者開發應用,那麼 Serverles Devs 就是幫助 Serverless 開發者更好地開發 Serverless 應用!

Serverless 架構實踐

Serverless Devs 官網實踐通過上面的介紹可以看出 Serverless Devs 開發者工具並沒有提供業務,業務的實現由元件提供,而元件本身分散在不同的 GitHub 倉庫中。

Serverless Devs 官網有下面幾個訴求:

●不同倉庫下 GitHub 源中的文件彙集在一個介面進行展示

●元件開發者專注元件文件編寫,文件自動實時同步到官網●元件一旦有變動,官網能夠自動部署和構建整體方案如下:

開發者在 GitHub 更新文件,觸發 webhook 鉤子配置的 Http Serverless 函式。這裡需要注意的是:由於元件的文件數目不定以及 GitHub 網路不穩定等問題,如果所有的工作都在 Http 函式中處理,非常容易導致超時,所以將所有的處理邏輯放在非同步呼叫中,執行完後將處理的結果投遞到釘釘或者郵件等渠道。

阿里雲函式計算控制檯實踐

阿里雲函式計算 FC 控制檯是使用者使用函式計算產品的第一站,控制檯的使用者體驗至關重要。

在架構上面臨幾個問題:

●後端採用中心化部署模式,使用者在海外訪問延時非常高

●需要使用者手動建設監控、日誌、灰度等能力,導致運維成本偏高

●研發效率較低,開發過程中前後端需要協調溝通,協作成本較大整體解決方案如下:

左側是阿里雲通用的閘道器,負責統一鑑權和安全等邏輯,抽離出 BFF(Backend for Frontend)層,這部分的特點如下:

●整體 BFF 部署在阿里雲函式計算 FC 上,開發者無需手動運維
●BFF 層由前端工程師負責,前端工程師更好地深入業務,提供優秀的使用者體驗
●後端工程師專注於底層穩定性和原子能力的提供,通過 SDK 的方式進行交付給 BFF

通過 Serverless 實現的 BFF 不僅給業務帶來了極大的靈活性,對於前端工程師這個群體也有質的改變:從之前的技術視角轉變到更加關注業務價值和使用者體驗提升。

CD 構建實踐

常規的自建 CD 構建叢集方案通過 Jenkins 或 Tekton 框架實現業務邏輯的編排,資源層面使用 K8s 部署,實現彈性伸縮。如果需要實現簡單的雲端構建 CD 方案,採用上文的架構略顯複雜。

CI/CD 的業務場景有以下幾個特性:

●通過事件觸發執行

●流量無法提前預估

●需要長時間在後臺執行,對延時不敏感

●由於網路時延等問題,需要設計失敗重試機制這些特性完全是為 Serverless 量身打造的。實現方案還使用了非同步函式,將構建的所有流程導到非同步函式中處理,整個編排邏輯通過 Serverless Devs 進行,完美實現了一個性能穩定的 CD 構建叢集。阿里雲函式計算應用中心這款產品的底層的 CD 能力完全基於上述的原理進行實踐,大家可以自行體驗。

非同步函式

實踐中有非常多使用到非同步函式的場景,這裡簡單介紹下非同步函式。

總結來看,非同步函式有四個特點:

1、可長時間執行,兩個小時到一天不等
2、可以設定自動終止,自由調節時間,節約資源
3、可把觸發結果分發給各個事件兌現中心
4、有三次機會可在失敗的情況下自動重試

原文連結:http://click.aliyun.com/m/1000347072/

本文為阿里雲原創內容,未經允許不得轉載。