作者 | 張挺
點選檢視視訊
Hi，大家好，在 2020.12 月的 D2，我為大家做了一場緊湊的微分享，話題為《打造更穩定的 Serverless 業務》。時間關系，大約隻有 20 分鐘，為在 Serverless 世界中踟躇的同學們抛磚引玉，讓大家了解下我們在做什麼。
從大促說起
除了開發和維護 MidwayJS 這一架構體系，提供應用、函數、一體化解決方案外，我們也在 Serverless 的 Runtime 層面有所涉獵。
在 2020 年，我們開放了 Midway Serverless 架構和一體化方案，彌補了 Midway 在 Serverless 方面的缺失，也朝着多場景架構又邁出了一步。
除了社群，阿裡内部的 Serverless 業務也蓬勃發展，淘系，飛豬，考拉，高德等 BU 的業務都已經揚帆起航，整體達到規模比去年增長了 10 倍，承接的流量也比同期翻了 6 倍，可以說，Node.js Serverless 已經真正的站穩了腳跟，和原有的 Node.js 應用體系共同支撐起了阿裡的前端業務。
高德也在”十一出行節“再創新記錄，提前達到了目标。
穩定性保障
去年這個時期，我們 Node.js Serverless 還處在一個起步的階段，還在做研發保障，平台基建的事情。經曆了去年的 ”研發模式更新“ 戰役之後，整個釋出平台，建構體系，以及開發、調試的能力都經過了重塑，已經達到了可以研發業務上線的要求。
随着使用 BU 的不斷增多，業務對穩定性也提出了更高的要求，這迫使我們對此需要提供更多的能力。”穩定性“就是随之而來的最大的考驗。
對此，我們在 2020 年大促做好了大考準備。針對雙促，除了傳統的壓測，盤點之外，今年由于加入了 Serverles 場景，額外增加了針對 Node.js Serverless 的穩定性保障。
整個額外保障分為如下三塊，我們将一一闡述。
強弱依賴分析
第一塊是強弱依賴分析。利用 技術手段 将業務調用的下遊依賴分析出來，明明白白的展示給業務開發，讓其清楚的知道，哪些是 ”強依賴“，哪些是 ”弱依賴“。
所謂的強依賴，是業務直接依賴的下遊，如果該下遊出現問題，會直接反應到業務本身，造成不可預估的影響，而弱依賴，則是下遊出現問題，業務本身不影響或者隻影響少許。
如圖上的業務依賴，當業務 B 出現問題，依賴 C 包含了一部分業務 B 的資料，業務 A 的系統可以繼續穩定的運作，這樣子業務 B 對于業務 A 來說就是一個 ”弱依賴”，而業務 C 則是一個強依賴（單條鍊路）。
當然這是一個理想情況，業務本身會相對複雜，資料接口可能業務非常繁雜，随着時間的推移，還會經常更新疊代，無法人肉沉澱。
這個時候，我們使用了一種依賴分析手段，這套技術，是監控的副産物，由 Alinode 提供的底層帶來的能力，詳細不久大家就會看到一個全新的 Alinode。
Ainode 是阿裡 Node.js 架構組維護的 Node.js 運作時，在社群的 Node.js 運作時之上提供了一系列監控、診斷優化能力。
在拿到強弱依賴之後，我們會推進業務的改進，當然，這個改進本質上是一個自我梳理的過程，并不一定需要把強依賴都變成弱依賴，是一個降低業務依賴風險的過程。
改進的方法也有不少，比如把資料降級，加緩存，或者增加新的資料源，做好不同的資料隔離和錯誤處理等等。
流量模型預估
第二塊是流量模型的預估。
傳統的流量模型是“流量（QPS + 機器數）的評估，在 Serverless 場景下，情況以然不同，這裡主要有兩點情況：
1、容器的數量對業務來說可能已經不太關心，業務希望隻需要提供總流量就可以上線
2、平台的單容器承載機關為并發數，這不符合平常業務的換算機關
這導緻了開發很難一次性将業務上線，需要額外關心單個容器，能夠承載多少流量，然後再将流量和并發度進行轉換，這個過程很容易出錯且不高效。
這一層的含義是，對已知的流量做預估，而不是未知的流量。比如搶紅包，是每個整點，那麼每個整點的流量可能會有新高，真個流量就是已知的流量。未知的突然流量，是不應該被允許到達業務代碼，盡可能在網關層之前就被攔截掉。
針對已經的流量，如何反向預估需要多少資源消耗，雖然使用者不關心，但是我們的平台側上線時還是需要計算，并給出推薦的值，這其中有兩個方式。
一是計算出單個容器在單一接口符合業務要求的情況下，比如滿足 RT 要求，計算出單容器合理的 QPS 和并發度，這個時候，我們已經可以拿這個值去設定函數的單容器并發以及容器數。
二是通過網關，在業務上線引入流量的時候進行流量測算，是否真的滿足上述的場景，根據實際的流量，我們可以動态的調整預留的執行個體數和彈性的執行個體比率，以達到最佳的資源配比。
并發度測算是基于”擁塞控制算法”來得出的，整套産品需要配套平台基建來做，後續我們會針對這個方案進行更細緻的分享，歡迎關注 MidwayJS。
多層流量管控
前兩項其實都是在業務上線前做的，而流量管控，則是運作時層面實時的處理。
在一般的場景下，我們有多個網關來管理所有的流量。以阿裡内部為例，我們有兩層網關，分别為通用網關和函數特有的網關，其之下，則是函數容器本身。
當流量來臨時，先經過通用網關，路由到函數網關，再根據域名和路徑，從函數網關查詢特定的函數資訊，将流量打入函數。
每一層都需要一定的流量管控。在特定的場景下，經過通用網關的流量是相對較大的（由于函數的數量不定，且為彈性），通用網關的流量限制一般為函數網關所能經過的最大流量。
當流量到達函數網關時，網關才會相應的去計算到達函數的流量，進行更細粒度的流量控制。而函數網關層面的流量管控，指的則是面向單一函數容器（或是單一函數業務）的限制。
在函數網關的流量管控中，着重是希望将特定的流量打入到特定的函數中，防止不同的函數，使用不同的功能。
而在函數容器本身，我們還做了第三道防護，除了第二點的流量測算外，額外還有防雪崩的作用。
所謂的防雪崩，是防止當一個（或者多個）容器無法工作，所有流量打到其他容器，導緻其他容器批量無法工作的情況。
在每個容器都做了這樣的防護，才算是真正的将風險降到最低。
這是一個微分享，也是我們這一年來的一些在 Serverless 穩定性方面的總結。其實整個都是出現問題，到解決問題的思考過程，希望大家能夠有所收獲。
最後：
🔥第十五屆 D2 前端技術論壇 PPT 集合已放出，馬上擷取
關注「Alibaba F2E」
回複 「PPT」一鍵擷取大會完整PPT