魚傳科技:函式計算,只要用上就會覺得香

語言: CN / TW / HK

深圳魚傳科技有限公司是專注以精準營銷和網際網路生態產品運營為核心的綜合網際網路營銷推廣服務商。通過整合全網優質媒體資源,並結合智慧資料模型和 AI 標籤演算法,向企業提供包括流量矩陣搭建運營、媒介流量採買、投放模型設計、產品營銷策劃、資料監控分析、效果運營等多層次服務。作為函式計算的資深使用者,魚傳科技的 CTO 和技術負責人跟我們聊了魚傳科技的 Serverless 旅程。

目前魚傳科技的業務主要基於支付寶小程式進行承載,小程式具有輕量、開啟方便、內容可以快速更新等特點,為了適應市場的快速變化和多變的客戶訴求,對敏捷開發提出了更高的要求。魚傳科技的業務特點,還具有訪問量波動大、流量突發預測難等特點,尤其是活動期間訪問突增對小程式後端服務的穩定和彈性也是一個很大的考驗。

而阿里雲函式計算是典型的 Serverless 計算平臺,具備極強的彈效能力,可以做到百毫秒彈性擴縮,可以很好的支撐業務彈性擴充套件。同時對函式計算,使用者上傳程式碼即可執行,無需關注和維護伺服器,也極大地提高了後端開發效率。這些特點使得函式計算成為很多企業支撐小程式/移動 APP 的優先選擇,尤其是有突發流量或者流量波動較大的業務場景。

如下是基於魚傳科技的第一視角呈現的 Serverless 落地實踐。

複雜互動小程式如何應對訪問量激增?

Cloud Native

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 元/日左右,對我們的業務來講,這個費用還是很便宜的。我們日常使用也會遇到一些問題,函式計算團隊能及時、耐心的給予技術支援, 我曾與團隊的同學開玩笑說,特別想在函式計算上多花點錢,想買技術支援。

雲端計算時代真正的彈性計算

Cloud Native

Serverless 技術最大的優勢就是免運維 ,同時提供彈效能力和按需付費。 我們選擇使用 Serverless 就是覺得它是真正的彈性計算,是未來的趨勢。 如果我使用比如像彈性 ECS  這樣的產品,如果我的業務發展需要上量,就需要人工去“起”機器,或者執行一些彈性策略。 但 Serverless 卻能夠讓我不用考慮後端的所有的運維工作,實現自動的彈性伸縮,所以我們認為 Serverless 是雲端計算時代真正的彈性計算。

最後,我們也想對函式計算提一些建議:

1. 期望函式計算的呼叫入口能夠支援訪問 IP 固定,因為一些政府監管的要求,需要加 IP 黑白名單。

2. 函式的版本釋出,能夠支援針對單個函式精準釋出,更加精準的實現灰度。

作者介紹: 魚傳科技 CTO 黃備、阿里雲架構師洛浩