下一個時代的發展架構居然是它！FaaaaaaaaS究竟是個啥？

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文由騰訊雲serverless團隊發表於雲+社區專欄

導讀：2018年7月6 - 7日，一年一度的技術圈盛會ArchSummit全球架構師峯會在深圳華僑城洲際酒店舉辦。100餘位國內外技術專家齊聚深圳，分享各種技術架構最佳實踐。來自騰訊技術工程事業羣架構平臺部的jerome做了主題爲《基於彈性計算的無服務器化實踐》的分享，如下爲現場演講內容。

據Gartner和麥肯錫統計，全球的服務器CPU平均利用率只有6%到12%。國內阿里，騰訊等大型互聯網企業CPU平均利用率均10%出頭左右，這裏主要是三種緣由致使：

• 單一業務難以均衡利用各種資源致使99%狀況下有資源閒置

• 在線服務的特色決定了有30%的時間段處於低負載

• 服務器流轉過程可能形成5%的時間段閒置

理想的狀況是像Google那樣有公司級borg資源調度平臺，各業務基於統一平臺構建，共享資源池混搭調度，但基於BG分開運營的歷史現狀，公司運管聯合架平彈性計算及各BG運營部門聯合打造的共享算力平臺，嘗試收集全公司的空閒資源，從現網中挖掘金礦，以docker容器的形式知足計算類的需求。

通過一年的建設，當前已挖掘了約140w核，支持了億級的視頻轉碼，圖片壓縮以及騰訊圍棋，王者榮耀等遊戲AI，手機瀏覽器等，但當前依然存在許多挑戰，好比：

好比業務接入門檻較高，須要業務理解多樣變化彈性的資源並作好適配，長尾業務接入困難；另外利用率也不受控，有些有狀態的業務利用率跑不高，且無法自動擴縮容；小資源碎片，好比剩下1核1GB這種用不出去；最後平臺無法準確監控業務的運行狀態和質量，好比請求延時等，總結起來，當前困境根源仍是咱們只是提供資源層面的服務，而資源要用好確依賴不少業務層面的工做。回顧集羣資源管理平臺走過的歷程，從最開始使用物理機（Nothing-as-Service）到IaaS虛擬機服務，再到PaaS容器服務，其實每一步都在嘗試爲業務作更多的事情，解放更多的生產力同時提高利用效率，下一步資源管理平臺可否直接跳出資源服務層級，讓業務只需關係業務邏輯，按需付費即可以了呢？

答案是確定的，它名字叫serverless，serverless不是指沒有服務器，而是指用戶無須關注服務器的存在，廣義上來說，如今的SaaS,BaaS,FaaS,PaaS均可以稱爲serverless，區別是從下到上平臺控制力愈來愈強，從左到右，平臺通用性愈來愈好；但Serverless真正廣爲人知，是由於以aws lambda爲表明的FaaS函數即服務的出現，因此當前狹義上來說，Serverless通常指FaaS函數即服務，咱們今天就用Serverless來指代函數即服務。

Serverless正好是解決咱們當前問題的答案，業務接入門檻高，用serverelss能夠不用關心資源，作到更快業務上線；利用率不受控，用serverless平臺能夠徹底控制資源的分配，利用率再也不受制於人；碎片資源用不出去，用serverless可讓業務把計算切成函數更小粒度的函數級別；業務質量難以監控，用serverless咱們感知業務的每次調用與返回，知道延時及返回結果。

因而咱們基於現有的容器平臺構建了serverless雲函數平臺，主要包括：

• 構建函數管理模塊來管理函數的配置，包括元數據，代碼，權限，觸發方式等；

• 構建函數調用模塊來分發調用函數，解決負載均衡，故障容災，擴縮容等問題；

• 構建多語言的運行時環境，代理函數的網絡監聽請求，運行用戶函數代碼，監控函數運行過程，收集函很多天志等；

• 構建函數觸發器等模塊，實現雲函數事件觸發式的自動調用；

新平臺的構建有諸多考慮點，好比怎麼作到足夠的易用，使得業務能夠樂於嘗試；怎麼作到足夠的穩定，來留住業務；如何作到比容器平臺的成本更加節省，讓業務看到實實在在的好處；如何作到更快、更安全、能持續發展等，本文將一一分享。

足夠易用的關鍵在於可否讓用戶作更少的事情，在開發上，雲函數提煉業務邏輯以外的部分代爲實現，好比網絡數據包收發，負載均衡，擴縮容，故障容災等，平臺把龍畫好，只須要業務最後點睛便可上線；在運維上，託管代碼包管理，服務器故障處理，服務質量監控及容災、負載均衡、擴縮容等配置；甚至在應用上，提供文件上傳\刪除，定時器，主題的消息時等事件觸發式自動調用，雖然當前一些微服務平臺也在作相似的事情，但依然以容器爲維度，容器內部對平臺而言是黑盒；雲函數參與了容器內部每一次用戶請求調用和返回的過程，能夠獲取更多業務維度的信息，使得在資源調度和質量控制上能夠更加的精準。

對比傳統的分佈式系統，雲函數平臺要作到足夠穩定還須要解決好函數調用流的問題，最簡單的調用流程是從雲api進來，走invoker作分發，再到計算節點執行，在同步調用一來一回的場景這樣沒問題，由於同步調用失敗時業務能夠自行重試；但異步調用時不會返回調用結果給用戶，請求丟了用戶感知不到，因此須要有持久化方式保存全部的異步調用，以避免丟失；另異步調用業務沒法自行重試，當平臺自動重試依然失敗時，需持久化保存便於問題追溯；重試自己也須要謹慎的設計，由於資源是調用請求到來時實時分配，重試可能會形成後臺資源成倍增長，且在某些流式計算場景，計算有嚴格的時序要求，重試的時候還須要阻塞整個流的計算等。穩定性最多見的挑戰是熱更新能力，而Serverless雲函數平臺天生支持熱更新，由於能獲知業務的每次請求和返回，且能控制業務請求的分發過程，作熱更新，其實就是簡單的禁掉節點，等待請求結束，更新後再從新啓用節點。

雲函數平臺要比容器平臺作到更低成本，須要儘可能避免閒置及無效浪費的資源，在傳統的業務架構下，一個業務模塊最少須要1個實例，若是要容災，至少須要2個；而云函數平臺被設計爲調用時實時分配資源，業務模塊最小實例數能夠縮減到0，無負載時不保留資源，收到業務請求時再實時分配資源；業務申請資源時，會按照峯值指定cpu核心數，內存大小，磁盤容量，網絡帶寬等一系列資源參數，但絕大多數狀況下用不完，因此雲函數平臺通常只讓用戶配置內存大小，由於內存是不可壓縮資源，少了程序跑不起來，而對於cpu，帶寬等可壓縮資源，都由平臺方根據內存大小及實際所需來配置且動態調整，以免因爲業務過量申請資源形成的浪費；另外雲函數有一個特殊點是支持事件觸發執行，但觸發配置不當可能形成無效循環形成資源浪費，好比配置文件上傳時執行某函數，但函數內又上傳了文件造成循環觸發，因此雲函數會監控函數調用流，發現無效循環，避免資源浪費。

因爲雲函數的資源是收到請求後實時分配並初始化的，而用戶能容忍的等待時間通常不超過3s，故第一次請求的冷啓動的時間要足夠的快，而函數的初始化須要作不少的事情：先要申請資源，肯定位置後要下載鏡像，下載函數代碼，啓動容器，初始化函數後才能執行函數，返回結果。其中鏡像下載的時間通常都超過3s，因此咱們用了不少預處理，緩存和並行化的方式來提高性能，好比鏡像預分發到服務器避免實時下載，容器資源使用多級緩存以重利用，小到用指針代替內存拷貝來傳遞參數等，這裏有個小問題，一個用戶函數用過的容器能夠交給另外一個用戶去使用嗎？並行化容器啓動與代碼下載流程，函數大參數傳遞使用共享內存指針方式傳遞等，最終將冷啓動的時間控制到200ms，熱啓動的時間控制到了5ms內，達到業界一流水準。

雲函數平臺因爲共享粒度更細，不可避免須要共享服務器內核，在安全方面挑戰會更大一些，因此咱們在docker隔離的基礎上，額外作了一些安全措施，好比限制函數運行時環境只有/tmp目錄可寫，經過seccomp等內核特性限制端口監聽，端口掃描等敏感系統調用；但作安全的同時，也關注業務兼容性，好比你們習慣性的使用root來運行程序，禁止root可能會給用戶帶來一些額外的適配成本，因此咱們使用root namespace技術把容器內的root映射成了容器外的普通用戶以控制權限，另外因爲咱們沒法審覈用戶代碼，而用戶技術上能夠寫代碼去作嘗試作任何事情，好比收集運行環境信息，窺探管理服務器位置等，爲了安全，對比開源的serverless平臺，實現了函數運行環境和管理環境的分離，函數網絡包收發代理及日誌收集等均放在容器外，容器內函數運行時環境不感知管理節點的的任何IP，端口信息及平臺日誌等信息。

因爲業務除核心邏輯以外的非功能性需求都依託雲函數實現，對雲函數平臺必然會有更多的需求，爲支持業務可持續發展，跟上業務迭代速度，咱們也作了一些優化，好比在過去一年，業務對咱們平臺提得最多的需求是支持各類編程語言，運行時環境安裝各類庫等，爲了加快迭代效率，咱們提煉了各種語言運行時環境的公共部分用C語言實現，由於各類高級語言均易實現對C庫的直接調用，這樣新增長一種語言支持可以在1~2周內完成，在庫更新方面，咱們把全部的運行時庫部署到母機上，經過目錄mount的方式掛進容器，使得庫的更新無須變動運行時環境鏡像。

彙總一下剛纔的關鍵設計，咱們經過讓用戶作得更少來提高易用性；謹慎的設計異步調用及重試來提高穩定性；消除閒置及過量申請來下降成本；利用緩存及並行來提高啓動速度；經過內核層技術及管理環境與運行環境隔離來提高安全性；經過提煉公共功能及避免重製鏡像來提高迭代速度，那實際效果怎樣呢？接下來給你們分享一下咱們當前的一些用戶案例及經驗教訓。

當前雲函數平臺在內部最大的用戶是遊戲AI的特徵提取，遊戲AI在整個行業目前還處於摸索階段，算法變化很快，程序常常更新，計算量很是巨大，好比王者榮耀1天需執行上億錄像文件的特徵提取。若是基於雲函數實現，只須要AI工程師用python寫兩個函數，一個腳本將從錄像文件中提取特徵，生成HDF5文件，另外一個函數將HDF5文件打散隨機化再推送到訓練平臺進行訓練，算法更新時，提交新的函數便可，能夠更專一於算法研究，無需再關心服務器的管理，計算的分佈，擴縮容，故障容災等。除遊戲AI以外，微信小程序的開發者工具也開始集成雲函數正在內測中，歡迎你們體驗。

回顧這1年多來的建設歷程，最大的教訓主要有2點：

• 前不久騰訊云云函數出現了一個安全漏洞，在雲函數的上下文經過bash反射，嘗試各類linux命令可獲知k8s的kubelet訪問地址，且因爲k8s沒有配置鑑權，用戶可直接控制k8s去獲取其它容器內部數據，形成安全隱患，幸好公司安全團隊及時發現未形成嚴重後果，這個問題的緣由在於咱們對k8s的安全機制缺少了解，給咱們的教訓是每引入一個開源組件，都須要吃透後再開放服務；

• 因爲雲函數平臺被設計爲7*24不間斷工做，每次計算節點升級時須要經歷屏蔽，等待函數執行完，升級再啓用的過程，早年未作自動化，整個集羣升級一次要耗費將近一週的時間，拖慢了版本迭代過程；

同時，咱們以爲好的經驗主要有2點：

• 設計之初就考慮了平臺的平滑升級，因此一年來變動了大大小小50來個版本，從未讓業務停過機；

• 另外咱們重視了平臺公共功能的提取，好比多語言支持方面，1~2周可搞定一種新編程語言，遠比其它serverless平臺快；

在推廣serverless雲函數平臺的過程當中，咱們發現對於無狀態微服務，負載波動大，對延時不敏感的場景，比較容易服務好，但對於有狀態的服務，須要業務自行保存狀態，對於持續高負載的業務，無法發揮資源按需取用的優點，對於延時敏感應用，因爲中間函數的分發多了一層，延時有差很少5ms的損耗，對這些場景，serverless當前還不太適合。

但將來,serverless是能夠期待的，當前serverless已經成了各大公有云的標配，對於公有云而言，serverless不只僅是一種新形態的計算服務，更能充當整個雲平臺的粘合劑，便於打包推廣其它雲服務，讓公有云從各個分散的雲產品集合變成了有機的總體，成爲用戶公共的雲後臺；在開源社區，serverless平臺也蓬勃發展，每隔一段時間都會出現新的值得關注學習的serverless平臺；雖然當前serverless主要戰場在數據中心，但隨着IOT的發展，IOT邊緣設備可能成爲serverless更大的戰場，由於邊緣設備的計算資源管理，軟件包發佈更爲複雜，更加有挑戰性，能解決好至關於雪中送炭。

武學修爲對各路招數融匯貫通時，能夠達到無招勝有招的境界，對於咱們作集羣資源調度的程序員來講，能把資源調度作到極致，讓業務根本感知不到服務器的存在，是咱們最高的追求。

問答
Serverless：如何刪除一個函數？
相關閱讀
使用 SCF 無服務器雲函數定時撥測站點並郵件告警
使用 SCF 無服務器雲函數定時備份數據庫
使用 Serverless 進行 AI 預測推理
雲學院 · 課程推薦 | 騰訊專項技術測試組長，結合8年經驗爲你細說冷熱分離法則

此文已由做者受權騰訊雲+社區發佈，更多原文請點擊

搜索關注公衆號「雲加社區」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！