導語 | Serverless Components 是 Serverless Framework 推出的最新解決⽅案,具備基礎設施編排能⼒,開發者經過使⽤ Serverless Components,能夠靈活構建、組合和部署 Serverless 應⽤。本文是對騰訊云云函數團隊前端負責人蔡衛峯在雲+社區沙龍online的分享整理,介紹Serverless Components在騰訊雲的落地和實踐,但願與你們一同交流。
Serverless是一個重開發和部署的產品應用,服務提供了彈性伸縮、自動運維的能力,開發者主要關心開發和部署。因此,開發和部署的體驗對於serverless業務來講是很是重要的。java
Serverless的函數自己只是提供了計算的資源,要想實現一個完整的應用,必然會涉及到雲上的其餘資源,好比網關、cdn、數據庫等。node
若是是控制檯操做,須要在不一樣的服務之間跳來跳去,比較割裂。若是能有一個基於應用的統一的命令行管理工具,對於開發者必然會方便不少web
Serverless CLI 是用戶受權後,經過命令行工具,調用雲API幫助用戶管理雲資源,方便對雲上資源進行比較完整的操做。數據庫
Serverless Framework 如今大量的使用者是 web 服務的開發者,主要定位於 web 服務場景,它是北美研發團隊開源的一個項目,是業界⾮常受歡迎的⽆服務器應⽤框架,開發者⽆需關⼼底層資源便可部署完整可⽤的 Serverless 應⽤架構。小程序
Serverless Framework 定義了一套完整的標準化規範,各公有云的插件遵循這套規範,經過對雲上資源的編排,覆蓋編碼、調試、部署、排障等全⽣命週期,幫助開發者經過聯動雲資源,迅速構建 Serverless 應⽤。後端
Serverless Framework CLI 是一個開源命令行工具,它使用基於事件觸發的計算資源,例如騰訊云云函數,AWS Lambda,阿里雲函數計算等。安全
Serverless Framework 爲開發和部署 Serverless 架構提供腳手架,自動化工做流以及最佳實踐。而且它支持經過豐富的插件進行功能擴展。 服務器
Serverless Framework 在 Github 有將近 4 萬的 Star,在國外比較受歡迎。咱們團隊最開始也維護了一個本身的 CLI,可是維護成本比較高,想作體驗好操做流暢的 CLI 須要投入大量人力精力,Serverless Framework 的 CLI 開發者接受程度比較高,它的協議也開放,因此按照規範接入便可。微信
咱們也有用戶原來用 Serverless Framework 的命令行工具,從 AWS 遷移到騰訊云云函數環境時候提出了這樣的要求。對用戶而言底層的雲資源操做是屏蔽的,只須要跟Serverless Framework打交道就能夠了,但願咱們也能夠提供對接 Serverless Framework 的方式,這樣遷移到騰訊雲上比較方便。
經過和 Serverless Framework 團隊的溝通,他們正好也有意願打入國內市場,雙方的合做也就水到渠成了。
Serverless Framework 強於 CLI 總體的體驗,可是對騰訊雲自己的瞭解比較少,因而就有了基本的合做模式,北美團隊負責 CLI 的開發和總體體驗,騰訊雲團隊負責具體落地到騰訊雲的 components 的開發和維護。雙方協力,打造 Serverless Framework 在國內的實際落地方案。
Serverless Components 是 Serverless Framework 的一個解決方案,自己具有快速部署、靈活配置、模板共享的理念。
公有云對接 Serverless Framework 後具備了公有云基本的操做能力,可是落地到具體的應用場景就會變得複雜。
外部應用不是單純靠計算資源,也會涉及到靜態資源,好比圖片、CSS、JS 文件的託管和域名的管理,涉及到底層數據庫的管理,也有一些更復雜的應用會涉及到更多的雲上的資源。
若是開發者要想實現一個應用的管理,則須要經過一系列的操做才能完成一個應用管理和部署,而 Serverless Components 是爲了適配各類具體化的應用場景而開發的模板能力。
Serverless Components 是 Serverless Framework 推出的最新解決方案,具備基礎設施編排能力,開發者經過使用 Serverless Components,能夠靈活構建、組合和部署 Serverless 應用。
Serverless Components 部署的完整全流程,首先讀取 .env 文件,在 .env 文件中能夠輸入騰訊雲固定的密鑰信息進行受權,也能夠經過微信掃碼賦予 CLI 臨時的受權,受權 Serverless Components CLI 在某一段時間能夠操做雲上某些資源的能力。
同時在 .env 文件裏面能夠注入相應環境變量,你能夠直接在 serverless.yml 中經過 ${env} 的方式,直接引用環境變量配置(包含 .env 文件中的環境變量配置,以及手動配置在環境中的變量參數)。
接着讀取 yaml 配置。yaml 文件要指定使用到的組件名以及組件相應的輸入參數,每一個組件由於涉及的操做會不同,因此每一個組件對參數也有本身的一套固定的規範。
經過 CLI 的命令進行部署的時候,會把用戶代碼壓縮以後上傳。首先壓縮指定的代碼目錄,上傳到一個公共的 COS 裏面。而後新建或者更新組件的狀態,同時會在服務端把代碼下載下來,並注入 Proxy 代碼。
proxy 代碼都實現了什麼能力呢?雲函數主要的適用場景是事件驅動型的,對於 http 請求的實現是經過 API 網關觸發器轉發的。網關接收到的 http request 會轉換爲雲函數須要的參數對象,在函數執行包裝後的 web 框架,執行完後再把 http response 轉換成 API Gateway 須要的結構返回給網關,網關再把 response 轉換成標準的 http response 返回,這樣就實現了整個 HTTP 的訪問。
用戶不須要關注這部分的實現,按照正常的開發就能夠,Components 部署的時候會自動注入這部分轉換邏輯的代碼。服務端在注入完 proxy 代碼後會把代碼上傳到用戶 COS 裏面,而後建立或更新雲函數,同時會再建立或者更新 API 網關的配置。
這個時候再把整個建立的過程以及建立的狀態保存到服務端,控制檯再輸出整個組件最終須要給用戶看到的一些雲上資源的信息,好比 SCF 的信息、API 網關的信息、CDN 的數據和數據庫信息等,整個部署就算是完成了。
應用部署完後會返回 API 網關公用的二級域名的一個訪問地址,跟正常的函數與本身組裝資源去訪問應用方式是同樣的。
你們能夠看到,咱們抹平了一些雲函數和正常服務器差別化的實現,抹平後經過 Serverless Components 能夠不用關心這些特殊的邏輯邏輯,也不須要關心其餘的雲上的資源。
若是本身要建立一個應用,同時要建立雲函數,代碼裏面要本身轉換 HTTP 請求,而後建立一個觸發器綁定到雲函數。
若是須要作靜態資源的加速,須要拆分靜態資源部署到 COS,並配置一個 CDN。這中間涉及到多個雲資源的操做。而咱們在 Serverless Components 中已經將整套都實現了,只須要在 yaml 文件裏把這些配置進去就能夠,部署完成後就能夠看到你的應用了。
如上圖所示,其中列舉了一些用戶使用比較多的 Serverless Components 組件,還有一些沒有列舉出來的,這些基礎的組件包括了騰訊雲上的各類經常使用的基礎資源。能夠經過對多個組件的組合來組成完整的應用,也能夠直接使用現有的高階組件。
咱們也歡迎第三方開發者貢獻他們的組件,如今就已經有不少第三方的開發者在貢獻他們的組件。
接下來詳細介紹一個 Serverless Components 的具體實現。以 Next jS 項目爲例,首先是初始化一個項目,安裝 CLI,原來的項目不須要作什麼改動,按照 Serverless Components 要求的規範進行配置後,直接用命令行工具進行部署。
執行部署後 component 會幫用戶經過 CLI 進行代碼的構建,完成構建後會把代碼部署到雲函數上,建立 API 網關代理 web 服務,同時部署靜態資源,會把目錄下的靜態文件自動拆分,並部署到 COS 上面。
咱們後面也會作更加智能化的優化,next 框架代碼比較大,每次部署都要上傳兩三百兆代碼,對上傳的效率和啓動效率也有影響。
騰訊雲提供 layer 的能力,咱們會自動拆分用戶的n ode_modules 到 layer,以後的部署只須要把業務代碼上傳和部署就能夠了,對部署效率有很大的提高。
這裏是部署一個有一些複雜度的 next 應用的屏幕截圖,能夠看到完成部署僅需 31 秒,部署效率很是高
從開始合做到如今已經有一年多了,還在不斷的磨合中。下面是我總結下來的,咱們在一年多的合做裏面具體的挑戰,與你們一塊兒分享交流。
因爲時差,語言表達,以及東西方思考方式的差別,致使總體的溝通效率比較低 。
他們那邊是游擊隊的開發模式,有一些研發發佈比較隨意,致使了一些線上的問題。而咱們實際上是有比較嚴格的開發流程,發佈前的驗證,發佈後的確認,監控告警的體系等等,都有嚴格的要求。
慢慢把咱們這一套嚴格的規範灌輸給他們,並要求他們可以按照咱們的要求執行。
因爲整套體系比較龐大,你們在前面也看到了,一個完整的 component 的生命流程比較長,步驟比較多,以前也沒有統一的日誌收集體系和系統,致使出現了用戶問題定位花費比較長的時間。
兩個團隊的目標導向不徹底同樣,咱們更注重用戶雲上資源的安全,對於密鑰的使用及權限控制比較嚴格,而他們更多的考慮的是使用上的便利。
整套體系採用 nodejs 開發,涉及到後端、存儲、數據庫等方方面面,對於開發的要求比較高。
另外,須要開發和產品有技術運營的理念,有開放的心態。對於英語也有必定的要求,最好能和北美的開發團隊直接對話。
國內外開發者習慣是有差異的,國外比較多的開發者更容易接受命令行工具,而國內開發者對這套東西不熟悉,須要有一個接受的過程。
咱們也會作一些妥協,好比後面能夠考慮提供界面化的配置方式等。其實對於 Serverless Framework 與 Serverless Components,騰訊雲本地化的運營方式和引導上跟國外會有所差異,咱們會針對國內開發者作一些貼合開發者習慣的嘗試。
其實在跨國合做中涉及 CLI 的時候,咱們一直很迷惑。雖然咱們很想把事情作好,可是對命令行工具的設計和交互設計方面受限於騰訊雲的產品,沒法突破本身的框架。
經過跟北美團隊的交流合做,對咱們的思路也有很大的開拓,咱們跟他們學習到了他們的產品設計理念,在產品設計方面,AWS 和周圍的生態確實對於咱們是很好的借鑑意義。
進行大型開源項目的實現,合做過程當中對協做方式也學習到了很多,對於整個後期的開源項目推動,後面再去參加別的開源項目,對於咱們而言都是很是寶貴的經驗。
同時,咱們也把嚴格的軟件開發經驗輸出給北美,並得到了他們的承認,對於咱們而言也是比較自豪的一件事。之前軟件開發方面北美領先於咱們,全部方面咱們向他們學習。如今並不徹底是這樣了,咱們比較嚴格的軟件開發規範比他們走得更靠前,把咱們的規範輸出給他們的同時也獲得了北美團隊的承認。
同類型開源項目的借鑑和學習開拓了咱們的視野,北美團隊也會常常發一些他們可以瞭解到的信息同步給咱們,咱們可以從中獲得借鑑和學習,並獲得本身的增加。因此將來也會更加緊密合做。
Q:Serverless現階段適用和適用的場景,騰訊內部有哪些業務在用?
A:全部的場景都是能夠的。小程序雲開發底層雲函數的能力就是用咱們 Serverless 的實現,騰訊內部還有好比微信支付、微信讀書、騰訊視頻、騰訊課堂有很多場景在用 Serverless 的服務。
Q:部署而言Serverless相對TKE有什麼優點和劣勢?
A:TKE 自己是須要本身管理的,可是 Serverless 在計算資源方面徹底不須要本身去管理,咱們有一個徹底的動態彈性伸縮能力,會根據訪問的請求量去作自動的伸縮,基本上省去了運營的須要。
Q:監控方面有什麼成熟組件的接入?
A:正常的外部應用都是能夠接入的,和虛擬機、容器等計算資源使用的方式相同。咱們平臺也提供了一些基礎的監控和日誌能力,另外一方面,也在聯合騰訊雲的監控團隊作了自定義監控組件上報能力的接入,能夠在代碼裏面自定義的上報到騰訊雲監控,自定義監控平臺能夠看到監控的數據。
Q:Serverless對業務較複雜的大型項目是否適合?
A:確定適合,好比微信支付、微信讀書、騰訊視頻、騰訊課堂都有很多場景在用Serverless的服務。
Q:穩定性保障的狀況如何?
A:Serverless 是基於騰訊雲整套體系來建設的,穩定性方面也是通過了大規模的壓測,有可靠的保障。比較大型的項目提早跟架構師溝通,來作資源的預留或者是資源等級的提高
Q:學習路線是什麼?
A:部署本身的業務到 Serverless 服務上面來,能夠在實踐中不斷的熟悉。還能夠加入咱們的微信或者qq羣,和大量的開發者一塊兒學習和探討,這樣在不斷的討論和學習過程當中能夠獲得不斷的成長。有使用上的疑問或者問題也能夠直接和咱們的開發或者架構師溝通。
Q:冷啓動支持須要有低延時的應用嗎?
A:若是對冷啓動比較敏感的業務,能夠經過預置併發來應對冷啓動的問題,設置了預置併發後,服務保留必定的最小資源量,這些資源量長時間存在,更大的併發到來時再經過自動伸縮去拉起,就能夠保證服務既能夠解決低延時的問題也能夠應對大請求的流量
Q:若是部署在騰訊雲的Serverless服務受到DDoS攻擊怎麼收費?
A:用戶能夠設置併發的上限,更多的請求自動幫着擋住,不會把這些流量放進來,實際消費用到消耗的 Serverless 請求才會收費,其餘的擋在控制併發外的請求咱們不會收費。
Q:平臺具體實施中如何避開Serverless的劣勢?
A:關於 Serverless 的劣勢,一是冷啓動,二是開發習慣的一些改變,這些劣勢能夠經過一些手段避開。冷啓動的問題能夠經過預置併發等高階能力解決,web 場景用 Serverless Components 的能力就能夠幫助抹平中間的差別
Q:企業應該如何設置Serverless Components?
A:要看具體的應用場景,騰訊內部的團隊在使用上也有各類差異,主要仍是依賴具體的應用場景和需求。
Q:Java這種啓動慢的語言,將來能夠在Serverless上應用嗎?
A:其實國內 java 開發者比較多,我以爲這是很是有潛力的發展方向,咱們也在考慮啓動比較慢的 java 應用如何部署到 SCF 上面,這是咱們努力的一個方向。