繼虛拟機，容器技術之後，無伺服器化成為新的行業熱點，無伺服器雲函數可以讓使用者無需關心伺服器的部署營運，隻需開發最核心的業務邏輯，即可實作上線營運，具備分布容災能力，可依據負載自動擴縮容，按照實際調用次數與時長計費。本次主要分享騰訊雲無伺服器雲函數在技術實作上的挑戰及架構實作原理。
歡迎大家前往騰訊雲技術社群，擷取更多騰訊海量技術實踐幹貨哦~
分享人：陳傑，騰訊雲架構平台部技術專家，10年雲計算經驗，現供職于騰訊架構平台部，負責彈性計算及雲函數技術研發，緻力于提供領先的基礎設施平台以提升資源使用率及優化提升程式員開發運維效率。
繼虛拟機，容器技術，無伺服器化成為新的行業熱點，無伺服器雲函數可以讓使用者無需關心伺服器的部署營運，隻需開發最核心的業務邏輯，即可實作上線營運，具備分布容災能力，可依據負載自動擴縮容，按照實際調用次數與時長計費。本次主要分享騰訊雲無伺服器雲函數在技術實作上的挑戰及架構實作原理。
主要從以下四個方面來分享一下無伺服器雲函數：
1.雲函數的價值及使用場景
2.雲函數架構原理
3.雲函數關鍵技術點
4.雲函數行業進展趨勢
無伺服器雲函數(Serverless Cloud Function)是騰訊雲提供的無伺服器(serverless)執行環境，幫助使用者在沒有購買和管理伺服器時仍能運作代碼。使用者隻需要使用雲平台支援的語言編寫核心代碼及設定代碼運作的條件，代碼即可在騰訊雲基礎設施上彈性、安全地運作，并可完全管理底層計算資源，包括伺服器CPU、記憶體、網絡、代碼部署、彈性伸縮、負載均衡等服務。
使用無伺服器雲函數将可免除所有運維性操作，企業和開發者可以更加專注于核心業務的開發，實作快速上線和疊代，把握業務發展的節奏。
一、雲函數的價值及使用場景
随着雲計算服務市場的成熟，使用者對雲計算接受程度逐漸提高，借助各類基礎雲元件，将業務上線時間從月級縮短到天級，但對比傳統模式，使用者仍需基于雲元件重構非功能性需求。
雲函數嘗試将業務算法和流程提煉出來交由使用者實作，打通各種雲服務，并實作通用的負載均衡、自動伸縮、故障容災、安全監管等通用功能，真正使得使用者像搭積木一樣打造個性化服務，将業務上線時間從天級縮短到分鐘級。
相比雲主機，雲函數更适合于支援微服務架構業務場景。以圖檔多規格壓縮服務為例，該服務在使用者上傳圖檔至COS時，自動将原始圖檔壓縮成适配手機、平闆、電腦等多種大小的規格。如利用雲函數實作該服務，使用者隻需建立函數，定義函數觸發條件為“圖檔上傳”，線上編輯或使用IDE完成代碼編寫後上傳，服務即建構完成。使用者上傳圖檔時，自動調用定義的函數完成圖檔的多規格壓縮，雲函數平台根據上傳并發量自動擴縮容函數執行個體，并最終按照實際調用消耗計費。
從該示例可以看出，雲函數為使用者帶來的主要價值為：
- 加快使用者服務上線時間，使用者隻需實作業務算法及流程，上線時間縮短為分鐘級;
- 減少使用者的營運負擔，使用者無須承擔服務擴容，故障恢複運維工作;
- 消除使用者的資源成本，使用者無需承擔資源閑置費用，隻為實際調用消耗付費
二、雲函數架構原理
雲函數平台整體架構原理如圖所示。
雲函數為使用者提供SDK/WEBUI兩種使用方式，并通過事件注冊與回調機制與其它雲元件打通，提供标準的API接口；調用分發根據函數所屬的區域，使用者，名字，版本号，鑒權等資訊申請函數執行個體，并将調用均勻的分發到可用函數執行個體；函數管理負責建立/修改/删除函數，并提供函數代碼管理，版本管理等功能；函數排程根據函數資源需求選擇合适的位置建立/銷毀函數執行個體；函數執行個體部署使用者定義的函數，負責函數的執行及監管。
從雲函數的定位及架構原理看，衡量雲函數平台的關鍵技術名額可概括為：
- 不僅支援業務快速上線，且能實作持續發展;
-
不僅支援業務按需取用，且能釋放閑置資源
;
- 不僅支援業務永不中斷，且能擴充運作範圍;
- 不僅支援業務自由運作，且能避免幹擾入侵;
下文将展開詳述。
三、支援業務快速上線，且能實作持續發展
支援業務分鐘級上線，需要盡可能的減少使用者研發工作量，雲函數使用者僅需提供簡單的函數配置及代碼即可完成上線。以圖檔壓縮為例，使用者自行編輯python代碼如下，即可實作一個圖檔壓縮服務：
其中第1行引入依賴庫，第4~9行解析輸入參數，第11行調用庫完成圖檔壓縮，12~15行判斷結果及傳回。使用者可線上完成代碼的編輯并送出，也可像開發本地程式一樣使用喜歡的IDE編輯，調試通過後打成zip包通過SDK送出，送出成功服務即上線。
支援業務可持續發展，需提供使用者函數平滑更新及版本變更能力，當使用者更新函數代碼或配置後，新調用請求被分發至新函數執行個體，原調用請求執行完成後，舊函數執行個體自動消亡，服務在客戶不感覺情況下平滑更新。即将支援使用者函數多版本管理，将函數别名映射至使用者指定版本，在客戶不感覺情況下實作多版本間平滑切換。
函數運作過程中間，使用者列印日志，标準輸出/錯誤輸出日志分類上傳至騰訊雲日志服務平台，使用者可實時監控函數運作情況。
四、支援業務按需取用，且能釋放閑置資源
要支援雲函數真正按需取用，需實作使用者第一次調用時延遲配置設定資源，函數調用過程如下圖所示：
雲函數平台在調用分發時，會判斷是否有函數執行個體存在，如若不存在，則實時啟動執行個體，執行個體啟動完成後，才開始執行函數調用。為了達到第一次調用足夠快的目标，在調用過程中需分階段逐層優化：
- 分發調用階段：需減少調用分發層級，比如對于使用者主動發起的http同步調用，正常路徑可免去存入持久化隊列過程;
- 鏡像及代碼下載下傳階段：需盡量預部署以減少下載下傳時間，比如對新送出函數，并行啟動預加載，使得第一次調用發起時無須再去實時下載下傳;
- 容器啟動過程：需簡化容器啟動腳本，使得啟動過程盡量輕量，對于對延時敏感的業務，提供執行個體預留機制，使用者可選擇預留少量執行個體以減少第一次調用的額外延時;
- 執行函數調用：需盡量減少函數參數，傳回資料及日志傳遞導緻的記憶體拷貝次數;
- 傳回調用：需盡量減少傳回層級;
通過逐層優化，第一次調用平台耗時可控制在2s左右，後續調用平台耗時控制在5ms左右。随着客戶請求量的增加或減少，函數執行個體随着自動擴縮容，一般算法如下：
If 目前請求數/目前執行個體數 > 擴容門檻值：擴容執行個體
else 目前請求數/目前執行個體數 < 縮容門檻值：縮容執行個體 當縮容至最後一個函數執行個體時，為避免函數執行個體短時間内重複啟動/停止導緻客戶調用延時增加，需保留一段時間延遲釋放。
五、支援業務永不中斷，且能擴充運作範圍
要支援雲函數永不中斷，需實作2個容災目标：
- 硬體故障時服務不中斷
- 平台更新時服務不中斷
為實作這三個容災目标，整體架構需實作set化，且在各層均需對應的支援：
- 接入層：基于騰訊雲CLB實作橫向擴充，負載均衡，7層路由能力;
- 邏輯層：實作子產品無狀态化，子產品内部無狀态資料，可随意啟停替換;
- 資料層：采用一緻性存儲倉庫存儲關鍵資料;
- 節點層：實作快速節點故障檢測及替換恢複
比如平台内部Invoker子產品執行個體硬體故障時，如下圖所示，由于invoker子產品無狀态，故障時可由接入層CLB子產品自動剔除，剔除後新請求分發至剩餘invoker子產品執行個體，已接收的異步事件可由其它invoker重試完成，同步http調用會直接傳回給使用者錯誤請求，由使用者重試，在故障invoker執行個體恢複後，自動添加至CLB中，繼續分擔負載。
當平台需要更新API接口時，采用隻增不改政策，提供新版本API接口，保持使用者原有服務相容性，使用者采用新接口時，CLB通過7層路由，路由至新版本invoker子產品執行個體，舊版本執行個體随着負載的降低逐漸縮容，新版本執行個體随着負載升高逐漸擴容，以此實作了使用者透明的版本平滑更新。
要實作雲函數需與各類雲元件打通，需要雲元件提供事件注冊及回調機制，雲元件提供可注冊事件及對應的回調接口，雲函數確定雲元件通信的使用者權限打通傳遞。目前雲函數實作了與騰訊雲COS存儲元件的打通，馬上将實作與騰訊雲CMQ、雲監控等其它雲産品的打通，并将運作範圍擴充至CDN節點及IOT裝置網關，實作邊緣計算。
六、支援業務自由運作，且能避免幹擾入侵
雲函數需支援使用者本地測試通過的代碼無縫在雲函數平台，需具備足夠的相容性，及使用者函數運作時環境，需要具備和使用者開發測試環境類似的軟體包，安全等配置;同時避免函數間幹擾，防止惡意入侵。
為了避免使用者函數間幹擾，雲函數使用了Docker容器來封裝函數執行個體，通過docker的名字隔離、空間隔離、權限限制等機制實作使用者間隔離，輔以實時沖突監控排程等措施及時處理幹擾。
為了避免使用者執行代碼影響整個雲函數平台，如下圖所示，實作了雲函數管理平台與使用者函數的隔離，使用者函數無法感覺管理平台的網絡位址，運作日志等資訊，進而無從影響雲函數平台的運作。
為了避免使用者惡意代碼對網絡的探測和入侵，如下圖所示，使用者函數執行個體被限制到了受限的公共VPC網絡，需通過網關實作與外網服務、其它函數執行個體、雲元件的互訪，同時，為了支援使用者函數執行個體與個人CVM虛拟機的內建，雲函數平台通過彈性網卡打通了與其私有VPC的網絡通信。
七、雲函數行業進展趨勢
近年Serverles、微服務等理念逐漸深入人心，雲函數開始被使用者了解接受。為了滿足使用者對于更快速上線、更低成本、更優架構的求索，騰訊雲推出了雲函數産品。使用者不妨從解決實際問題開始試用雲函數，比如實作一個簡單的服務撥測工具，實作一個定時任務，實作存儲于COS的圖檔、視訊、檔案的計算等。。随着雲函數可關聯雲元件的拓展，支援語言的豐富，調試工具，流程引擎等逐漸完善，雲函數會逐漸成為整個雲平台的粘合劑，将各種雲元件融合一起，讓雲成為你的公共背景，到時可支援更為複雜的狀态服務場景，成為使用者通用體貼厚實的後盾。
歡迎試用騰訊雲無伺服器雲函數産品，雲函數解決安全接入、故障容災、自動伸縮、成本優化、版本管理等背景通用問題，使用者可更省心專注的投入到業務創新。希望通過雲函數能更深入的開放騰訊多年在海量服務耕耘修煉的能力，共享給廣大使用者使用，與大家一起成長。
Q&A
Q：請問代碼怎麼部署到docker中?
- A：直接将代碼下載下傳至母機，再将代碼目錄挂載至Docker
Q：雲函數是通用的 還是隻能在雲平台運作?
- A：雲提供了雲函數服務，自己也可搭建，目前github上有不少開源雲函數平台，比如openlambda，iron.io等，建議直接使用雲的服務，因為可以和多個雲産品打通，單靠雲函數自身難以建構完整服務。
Q：事件傳遞使用的是隊列嗎?
- A：異步事件用了CMQ消息隊列持久化存儲，同步事件未使用
Q：請問雲函數對開發語言有限制否？如果有，目前對Go語言的支援如何？
- A：目前支援python 2.7/3.6, node.js 4.3/6.10, Java8，如果有通用的使用者需求，可以支援其它語言，比如php,go等
Q：有系統函數調用嗎？自定義函數的顆粒度有何建議？
- A：絕大部分的系統調用都可調用，除了一些危險操作，比如關機，重新開機，網絡服務監聽等，函數顆粒度可參考微服務的設計原則，将功能盡量拆細
Q：可落地嗎？
- A：已有不少使用者案例，後續會做些分享，不妨親自試試，目前是免費的，會一直提供免費包，有需求直接給我們提
Q：雲函數支援kotlin語言嗎？
- A：之前沒使用者回報需要這種語言的支援，不過我個人挺看好，會持續保持關注
Q：請問将請求排程函數執行個體，這個排程算法的實作？
- A：其實這裡就是通用的負載均衡和擴縮容算法，這裡比較複雜的是提前預測需要擴容，後續會詳細分享。
Q：能介紹下 将請求排程到函數執行個體的實作嗎？
- A：這裡有個invoker子產品對每個函數維持有一個請求隊列，目前沒設定優先級，按照先來先到的順序依次排程，排程時會從函數所有可用的函數執行個體中，選擇一個下發。函數執行個體裡有個循環接受請求，收到時傳遞參數調用使用者函數。
Q：代碼可以下雲落地嗎？
- A：代碼裡一般會涉及其它雲産品的調用，是以一般對雲平台有一些依賴，可以關注下開源的serverless架構，在公有雲雲函數上封裝了一層，用來解除依賴，實作在各個雲平台的平滑遷移。
Q：雲函數的代碼有哪些限制？比如什麼樣的函數不可以調用，什麼樣的庫不能import？
- A：可以基本認為無限制，但會禁止惡意行為，比如關機，重新開機，端口掃描等；也會禁止端口監聽，因為常駐程序不符合雲函數按需啟用的原則。如果預裝庫不符合要求，可以自行将依賴庫打包至zip裡上傳。
Q：下層的容器編排是基于什麼做的？k8s麼？
- A：基于騰訊雲的容器平台，其底層是K8S
相關閱讀
Serverless 初探
我們能用雲函數做什麼？
蜜罐執行個體分析 : 一款針對樹莓派微型蠕蟲樣本捕獲分析記錄
此文已由作者授權騰訊雲技術社群釋出，轉載請注明文章出處
原文連結：https://cloud.tencent.com/community/article/455966
海量技術實踐經驗，盡在雲加社群！
https://cloud.tencent.com/developer