簡介： 複雜交互小程序如何應對訪問量激增？
深圳魚傳科技有限公司是專注以精準營銷和互聯網生態產品運營爲核心的綜合互聯網營銷推廣服務商。通過整合全網優質媒體資源，並結合智能數據模型和 AI 標籤算法，向企業提供包括流量矩陣搭建運營、媒介流量採買、投放模型設計、產品營銷策劃、數據監控分析、效果運營等多層次服務。作爲函數計算的資深用戶，魚傳科技的 CTO 和技術負責人跟我們聊了魚傳科技的 Serverless 旅程。
目前魚傳科技的業務主要基於支付寶小程序進行承載，小程序具有輕量、打開方便、內容可以快速更新等特點，爲了適應市場的快速變化和多變的客戶訴求，對敏捷開發提出了更高的要求。魚傳科技的業務特點，還具有訪問量波動大、流量突發預測難等特點，尤其是活動期間訪問突增對小程序後端服務的穩定和彈性也是一個很大的考驗。而阿里雲函數計算是典型的 Serverless 計算平臺，具備極強的彈性能力，可以做到百毫秒彈性擴縮，可以很好的支撐業務彈性擴展。同時對函數計算，用戶上傳代碼即可運行，無需關注和維護服務器，也極大地提高了後端開發效率。
這些特點使得函數計算成爲很多企業支撐小程序/移動 APP 的優先選擇，尤其是有突發流量或者流量波動較大的業務場景。如下是基於魚傳科技的第一視角呈現的 Serverless 落地實踐。
複雜交互小程序如何應對訪問量激增？
2018 年底，我們開始嘗試使用函數計算。當時，公司的核心業務是在支付寶上製作一些小程序。“多多有禮”小程序就是在那個時候上線的，“多多有禮”是一款主打互動領獎的小程序，當前已經積累了百萬日活的規模，是一款非常受用戶歡迎的產品。然而在 2018 年，“多多有禮”最初上線時，我們遇到了已有業務系統難以承載突增流量的難題。那時我們的業務都跑在服務器上面，爲了能抗住高併發流量，我們準備了大概三、四臺高配服務器做負載均衡，然而在業務併發高峯期，服務崩掉的情況還是經常發生。因爲這個小程序涉及到的業務邏輯，和應用後端交互比較多，有很多複雜流程，比如打卡、簽到、莊園運營等，所以遇到突增流量，單純增加服務器數量很難扛住。
另外我們還遇到了資源利用率低的問題。“多多有禮”在初期上線的時候，業務高峯期併發大概在 1000-2000，但業務低峯期可能也就幾十，這是因爲小程序設計的用戶打卡、簽到等動作，使得用戶量非常容易在早上、晚上，或者某一個特定時間暴增。在這種情況下我們再用 ECS 的話，不僅需要按照峯值流量預留足夠的 ECS 資源，維護起來也會變的非常複雜，資源利用率很難做上去，費用也會成倍的增加。所以我們當時非常迫切地想把這個事情從我們系統裏解耦，如果能簡化我們的運維複雜度，還能引入彈性能力就好了。
經過調研我們發現當時阿里雲，只有函數計算 FC 這款產品具備相應的特點，所以我們就開始嘗試把整個業務都遷到阿里雲函數計算上來。經過這 3 年多的使用，我們把新的應用、可以遷移的舊應用、內部應用/外部應用等都陸續遷移上函數計算了。可以這麼說，如果函數計算崩了，我們公司的業務基本也就癱了。但是經過這 3 年來的使用，發現函數計算的穩定性還是超預期的，比我們維護使用服務器的時候，業務穩定性和性能都有大幅提升，現在峯值可以達到數萬 QPS、數千函數併發同時穩定運行。而且我們和函數計算也建立了專門的技術支持羣，有任何技術問題，都能很快得到響應，這也是爲啥我們敢把公司所有的業務都基於函數計算來部署的原因。使用函數計算，真正幫助我們解決了很多穩定性和性能問題。
“多多有禮”小程序頁面
最佳實踐
再來分享下我們使用函數計算的一些最佳實踐，希望也能幫助到其他用戶使用函數計算。
1. 開發流程
我們公司的主要技術棧是基於 PHP 語言，也會使用一些 Web 框架，像 Lavaral，針對 Web 框架，爲了能在函數計算上運行起來，我們也對框架做了些適配，一個項目拆成一個或多個文件，對應多個函數，單個文件有的1萬行代碼，基礎文件一百行左右。但是現在函數計算配合 Serverless Devs 工具支持了多語言 Web 框架的“0”改造遷移，我們也在嘗試使用。
目前我們每個開發會獨立負責一個函數服務，服務下面每個函數會作爲一個小的應用，部分項目會跨服務依賴一些功能函數，但是我們都會盡可能都獨立開。函數計算也支持了層功能，後面會用層來部署公共函數、依賴，比如給用戶發紅包，代碼只用寫一份。另外對新招進來的開發來講，函數計算上手門檻還是很低的，不用管理服務器搭環境，可以直接在線編輯代碼、部署、測試。
2. 流水線和灰度發佈
我們本地一直採用的 SVN 存儲代碼，SVN 提交代碼支持觸發 Action，我們封裝了函數計算的 API 接口，可以通過關鍵字觸發函數和服務的發佈。爲了避免發佈影響線上服務，我們還使用了函數計算的版本和別名的功能。正常線上業務會發布成新的版本，同時把 HTTP 流量入口綁定的 release 別名指向新的版本，這樣就完成了發佈過程，如果最新的代碼出現問題，可以更改別名的指向，就能達到一鍵回滾到上個版本。同時我們也會創建一個測試別名，會先完成版本的測試後，纔會把承載現網流量的 release 別名指向到新版本。這樣通過別名的能力就區分出了線上環境和測試環境，非常方便。
3. 運維管理
對函數計算來講，基本是不需要關心資源維護的，像我們最依賴的彈性能力。但是對於業務運維來講，監控日誌就成了非常關鍵的手段。函數計算集成了 SLS，每次請求都會生成一條日誌，可以比較方便的過濾出錯誤日誌，對線上問題排查還是比較方便的。另外函數計算也提供了比較全的監控視圖，我們最常用的就是請求量、錯誤次數、併發、執行耗時等指標，針對錯誤次數也加了告警，這樣開發就可以直接兼業務運維，效率成倍增加。
效果對比
對比之前使用服務器，函數計算確實給我們帶來了很大的便利性，我們也是最早喫螃蟹的人，基本伴隨着函數計算一路成長，我們也非常高興的看到，函數計算的功能越來越豐富，體驗也越來越好。總結下來：
1. 穩定性增強開發不需要去關心後端服務的搭建運維，只需要編寫函數就能夠爲小程序提供穩定可靠並且彈性伸縮的服務。並且隨着小程序訪問量增加，函數計算能夠支持更大的併發配額，即使應對大促活動流量高峯也能夠如絲般順滑。對於穩定性的提升，這個是對我們最大的幫助。
2. 開發上手快，不用維護服務器使用函數計算“上手快，不用維護服務器”也是很吸引我們的一個點。很多人對於 “Serverless”技術有一些誤解，認爲這個火熱的技術可能會難以學習、理解，其實不然。在實際使用過程中，我們曾經嘗試讓一些開發新人在生產過程中直接使用函數計算，在實操的過程中，這些開發上手非常快，他們只需要關心自己的代碼就可以了，也非常樂於使用。3. 價格低服務好，想買技術支持之前我們對於函數計算的使用費用沒有做過細緻的統計，剛發現支撐一個日活超過 50 萬人的小程序，使用函數計算費用大約在 200 元/日左右，對我們的業務來講，這個費用還是很便宜的。我們日常使用也會遇到一些問題，函數計算團隊能及時、耐心的給予技術支持，我曾與團隊的同學開玩笑說，特別想在函數計算上多花點錢，想買技術支持。
雲計算時代真正的彈性計算
Serverless 技術最大的優勢就是免運維，同時提供彈性能力和按需付費。我們選擇使用 Serverless 就是覺得它是真正的彈性計算，是未來的趨勢。如果我使用比如像彈性 ECS 這樣的產品，如果我的業務發展需要上量，就需要人工去“起”機器，或者執行一些彈性策略。但 Serverless 卻能夠讓我不用考慮後端的所有的運維工作，實現自動的彈性伸縮，所以我們認爲 Serverless 是雲計算時代真正的彈性計算。
最後，我們也想對函數計算提一些建議：
1. 期望函數計算的調用入口能夠支持訪問 IP 固定，因爲一些政府監管的要求，需要加 IP 黑白名單。
2. 函數的版本發佈，能夠支持針對單個函數精準發佈，更加精準的實現灰度。
原文鏈接：https://click.aliyun.com/m/1000360454/
本文爲阿里雲原創內容，未經允許不得轉載。