歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~
本文由騰訊雲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 送你一份技術課程大禮包！
海量技術實踐經驗，盡在雲加社群！