作者 | 夙言
今年阿裡雲函數計算服務 FC 開始進入阿裡集團内部支撐業務，并且和我們的函數研發平台完成了對接，今年大促 Serverless 雲研發平台 中多BU 租戶進行了函數應用落地，包含淘系、飛豬、高德等業務，并且在部分場景下也通過彈性模式抗住了大規模的流量洪峰。應該有很多同學比較好奇在這背後都發生了什麼，今天我們來通過一次函數業務需求初探阿裡集團 Severless 體系。
業務需求
雙十二有這麼一個典型的業務需求，天貓V榜 雙十二需要上一個猜你喜歡子產品，服務用函數進行開發。
業務需求：展示給使用者個性化的商品 feeds 流。
穩定性要求：無運維的承接雙促當天的流量洪峰。
安全運維要求：函數上線前需要預發測試、需要有灰階流程、需要有完整的函數權限管控、上線後函數可觀測。
接下來我們分析一下業務需求，個性化商品資料我們可以通過集團内部個性化服務擷取，商品資訊我們可以調用内部補全服務進行補全，招商商品字段可以在提前跑好資料的 Redis 中拉取。ok 感覺需求很簡單。但接下來我們進一步思考就會發現這其中還是有不少問題的。
實作需求遇到的問題
第一個問題：我們的函數跑在彈外阿裡雲 FC 上，需要調用彈内個性化服務拉取個性化資料和調用内部補全服務進行通用補全。衆所周知集團網絡彈内彈外網絡是隔離的，函數運作在彈外雲機房内的是通路不到彈内服務的，那麼流量數如何在雲上雲下流轉的呢？
第二個問題：函數體系數如何在無運維的情況下順利承接雙促當天的流量洪峰，我們需要做些什麼？
第三個問題：函數如何滿足上述提到的安全運維要求呢？
問題解答
第一個問題：資料互通
要解釋這個問題就不得不介紹一下集團的雲部署模式，目前集團 IDC 跟 阿裡雲 通過 混合雲專線方案 組成了上述混合雲的部署模式，實作彈内彈外的互通，内部業務可以使用公有雲上的彈性資源服務。為了我們更好的介紹混合雲專線方案 ，在這之前我們先介紹幾個概念。
混合雲
混合雲：簡單來說是結合公有雲和私有雲的優勢，通過專線或 VPN網關 等方式連接配接公有雲和企業私有雲，允許在不同的雲環境之間共享資料和應用程式。擁有以下幾個特點。
- 高控制力：企業可以根據業務需求在不通雲環境中配置設定工作負載，可以把企業核心服務和資料，比如交易、營運服務運作在私有雲和存儲本地 IDC 當中，其他低安全性要求的服務運作在公有雲上。
- 高靈活性：面對私有雲中比較棘手的超出預期的大流量場景時，可以将部分工作自動傳輸到公有雲，按需付費的使用公有雲近乎無限的資源。
- 高可靠性：雲服務商也會承諾一系列 SLA 來保障服務的穩定性
- 無廠商鎖定問題：一個私有雲可以連接配接多個公有雲服務變成多雲混合部署，比如企業 A 通過專線将本地 IDC 同時連接配接了阿裡雲和騰訊雲，服務可靈活的在兩個雲廠商之間移動，通過這種方式解決廠商鎖定問題。
VPC
- 專有網絡 VPC：（Virtual Private Cloud）自定義私有網絡，不同的專有網絡之前二層邏輯隔離，由路由器、交換機、私有網段組。使用者可以配置 IP 位址範圍、配置路由表和網關。可以在專有網絡内使用雲上産品（ECS、RDS、LB）
混合雲專線
了解了混合雲、VPC 之後我們再來介紹一下 混合雲專線方案 是什麼：雲上各 Region（地域） 資源通過一個或多個集團 VPC 進行私有網絡隔離。集團使用的雲上資源都必須部署在集團 VPC 内。但是集團 IDC 和集團 VPC 無法直接通信，雲上的資源都通路不到，這時就需要通過雲專線（租用一條營運商的專線，可以繞過公網，快速安全連接配接阿裡雲與本地資料中心）來連結雲上集團 VPC 和雲下集團 IDC ，達到流量互通。
弄清楚集團 VPC 和集團 IDC 是如何流量互通之後，我們再來延展一下，VPC 是 Region 級别隔離的，也就是意味着中心的 VPC 是沒法直接通路上海的 VPC 那麼如果我們自身部署了雙單元，但是我們依賴的一個下遊服務隻部署了中心單元，那麼我們部署在上海 VPC 的服務如何通路部署在中心 VPC 的下遊服務呢，這時候就要引出另一個概念了雲骨幹網（建構多地域全球網絡，并和混合雲連成一體，打造具有企業級規模和通信能力的智能雲上骨幹網絡）。各 Region 集團 VPC 之間的流量，先要通過雲專線回到雲下集團資料中心，再通過骨幹網實作跨 Region 互通。
小結
通過 混合雲專線方案，讓我們跑在彈外雲機房上的 天貓V榜 函數可以請求到集團内部的 TPP 服務 ，我們看下上述的業務流程圖具體在網絡中是如何流轉的。
第二個問題：如何無運維的承接雙促當天的流量洪峰
本次大促 天貓V榜 流量來源包括兩部分：主互動、榜單會場，其中主互動流量較大且有明顯峰值，流量的波峰和波谷 QPS 相差10倍。那面對這種情況我們應該如何應對洪峰流量，已經我們如何對自身和下遊服務進行保護？以往傳統應用模式有兩種處理方式，第一種是按照峰頂流量評估機器數，提前擴好，缺點是在日常狀态下機器使用率力較低比較廢機器。第二種方式是到了流量高峰的時候手動擴容機器，需要人工操作，有一定的風險。并且傳統應用啟動一般不是那麼快，是以可能會在一開始流量上漲的時候出現大量失敗。接下來讓我們看下在 Serverless 體系下我們是如何解決這個問題。
FC 的容器類型
首先我們先來了解一下阿裡雲函數計算 FC 的容器類型，大緻分為兩種，預留容器和彈性容器。
- 預留容器：預留容器比較好了解可以類比于傳統應用，啟動一定數量的機器一直放在那裡處理請求，函數預留容器與之類似，就是啟動多個一定規則的容器（單容器規格一般是 1C2G ）不管有沒有流量一直放在那裡處理請求，不同的是函數容器每 5 小時會強制輪轉一次，是以做不到固定 IP 。
- 彈性容器：預留容器可以應對日常流量需求，但是假設業務忽然導了一波流量進來，目前的容器數量已經無法處理這批額外的請求，那服務豈不是會出現大量的請求失敗呢，這時候就要使用我們的彈性容器了，彈性容器顧名思義，會根據一定規則彈起或縮容，目前 FC 支援的規則就是并發，當請求某一時間内出現增加，勢必會導緻函數各容器的并發增加（tips: 并發 = qps rt，例如 qps = 100，rt = 500ms，并發 = 1000.5 ），FC 檢測到并發達到了使用者設定的單容器最大并發值，就會彈起彈性容器來進行分流，一直到單容器并發降低到預設最大并發值，才會停止新的彈性容器彈起。當這波流量高峰過去并發下降到預設最大并發值後，這部分彈性容器就會自動縮容。
淘系大促業務使用的就是上述預留容器加彈性容器組合部署模式，日常流量通過預留容器承接，突發流量通過彈性容器承接。除此以外我們進行了限流，防止自身流量過高導緻下遊服務壓力過大。接下來我們介紹一下我們的限流政策。
函數限流
起初我們認為針對函數級别限流配置限制住函數的最大 QPS 就可以了，比如淘系大促 極有家 業務的函數，整體流量屬于中等，于是我們直接讓 FC 的同學針對函數在 sentinel （流量控制元件）上配置了對應流量的限流，但是經過單鍊路壓測，我們發現流量還不到指定限流值就會出現一些不正常的限流，通過和 FC 同學一起問題定位，發現了問題所在，因為承接 HSF Trigger 的 HSF Gateway 是一個叢集，sentinel 上的限流是根據單機配置的，是以具體配置到某一台 HSF Trigger 機器上的限流其實隻有幾 QPS，這時隻要流量負載出現一點傾斜，那麼單機很容器就會觸發限流，是以這裡的限流是不準确的。既然函數級别限流不準确，那麼我們就瞄上了單機限流，我們根據日常整體流量配置好單機并發限流，通過研發平台配套的單容器限流元件進行單機限流。并且在函數級别（HSF Gateway 單機限流）的配置進行一定系數的放大，使之不會輕易觸發限流，并且多級限流也一定程度上減少了因為某一級限流失效對業務的影響。通過這種組合拳的方式實作了我們雙促業務限流保障。
天貓V榜單 函數大促期間通過在研發平台上進行了如下容器和限流配置，日常流量通過預留容器承接，突發流量通過彈性容器承接。并通過函數和單容器級别的限流防止自身流量過高導緻自身和下遊服務壓力過大出現問題。讓業務函數在無運維的情況下順利承接雙促當天的流量洪峰。
第三個問題：權限管控、灰階等安全保障
說到第三個問題，就不得不提起這次雙促支撐淘系、飛豬、高德等多個BU函數業務研發、釋出、運維的 Serverless 雲研發平台 了 ，下面我們來介紹一下它的幾個特點看看它是如何解答第三個問題的。
面向業務應用
不同于傳統函數計算平台，開發維護單個函數，研發平台提供給開發者面向業務應用開發模式，每個應用權限互相隔離，一個業務應用中的所有函數維護在一個 git repo 中，達到同一業務代碼統一開發維護和最大程度的業務邏輯代碼複用。使用者開發時就像開發傳統應用一樣，平台會在釋出的時候根據 fyml 中的資訊，自動拆分建構成一個一個獨立的函數zip包進行獨立灰階部署。
面向解決方案
平台對解決方案的定義：解決某一橫向或縱向領域的，貫穿建立、研發、傳遞、運維階段的一系列能力的集合。
到目前為止，平台提供了3種通用解決方案，分别是面向接口服務開發的純函數解決方案、面向中背景開發的 ICE 全棧解決方案、面向C端 RAX 全棧 SSR 解決方案，以及近20種各租戶定制的各自業務領域的租戶定制解決方案。
例如平台提供的面向中背景開發的 ICE 全棧解決方案，本地提供前後端代碼同一 git repo 開發的開發體驗并通過 hooks 方式讓使用者便捷的請求函數接口，釋出建構時自動拆分出前端 assets 資源和函數服務部署 zip 包，并且通過定制釋出流程做到 assets 和函數有序部署。部署時配置設定應用泛域名，自動綁定函數，省去使用者域名申請和統一接入複雜的流程，做到1分鐘建立項目5分鐘釋出線上，釋出即可通路。釋出後提供新舊版本灰階機制，并且可以在灰階界面實時看到新舊版本的 QPS、RT、錯誤率等名額。
平台梳理的使用者平台側的使用路徑，将平台建立、研發、傳遞、運維階段具體功能子產品化。并且提供解決方案定制能力，通過解決方案元資訊将解決方案中的各部分能力配置化，以供其他租戶同學可以友善的在平台上定制自己租戶所需要的函數解決方案，并且沉澱可複用的通用解決方案供所有同學選擇使用。有興趣的話可以聯系本人了解一下~
灰階流程
我們通過函數别名機制（Alias）實作新老版本的灰階能力，目前彈内每個函數研發平台都預設按照統一的規則建立了一個通路别名，成為函數所有 Trigger 的預設綁定别名，所有流量都指定這個别名。并且别名可以配置各版本流量配比，我們的灰階就是以這種機制為基礎實作的。
{
"metadata": {
"name": "fc-interaction-index2__stable", // 平台生成的預設 Alias Name
"description": ""
},
"apiVersion": "core/v1",
"kind": "FuncAliasMeta",
"spec": {
"routing": {
"2": 50
},
"functionVersion": "1",
"functionName": "fc-interaction-index2",
"functionGroupName": "fc-rank-v-ald"
},
"status": {
"phase": "active"
}
} 除了别名機制我們還要了解 FC 的灰階部署方式，函數灰階采用的是滾動部署方式，相比較于藍綠釋出這種方式更加省機器，但是也會有一些其他問題，沒有辦法保證灰階比例的實時性，因為新版本是逐漸滾動部署出來的，灰階比例調整後，需要等待新版本滾動部署出來。（例如版本2從開始灰階到轉正會經曆下圖過程）
自動配置設定域名
對于在平台上使用 HTTP Trigger 的函數部署後，會發現平台已經幫你建立出了一個域名，你不需要在自己去申請域名，慢慢的等生效了。接下來介紹一下研發平台是如何做到上述便捷申請的呢。
其實研發平台并沒有新增域名，而是平台統一申請了 日常、預發、線上的泛域名。使用者在釋出建構過程中，會生成應用下函數的router資訊（即應用中每個函數對應的 path 、method 等資訊），并且研發平台會在部署的時候根據函數應用名配置設定給函數應用一個唯一的三級域名。
研發平台提供了完整的函數權限管控，灰階流程等能力支援了 天貓V榜 等業務的開發、部署、灰階、容器限流配置相關工作，也通過 Alinode 的監控報警功能提供函數運維能力。由于篇幅限制更多平台能力我們下篇再述。
總結
Serverless 在集團前端範圍還是屬于新生事物，肯定有一些同學想嘗試但是在流量稍大一點的業務落地的時候有一些顧慮。本文通過一次簡單的業務需求，從網絡、開發、灰階、容器、限流等幾方面介紹了這個體系。想讓大家能進一步了解這個體系，可以更便捷、安全的使用這個體系。
電子書免費下載下傳
《2021前端熱門技術解讀》
阿裡巴巴前端委員會重磅推薦！阿裡巴巴前端技術專家為你解讀前端技術新趨勢以及2021你需要關注的技術熱點，覆寫前端安全生産、跨端技術、Node.js(Serverless)以及多樣化的前端技術四大方向，是2021不容錯過的前端學習手冊。
關注 Alibaba F2E 公衆号
回複 電子書 馬上下載下傳