作者：計(jì)緣，阿里云云原生架構(gòu)師

暢捷通介紹

Cloud Native

暢捷通是中國領(lǐng)先的小微企業(yè)財(cái)稅及業(yè)務(wù)云服務(wù)提供商，成立于 2010 年。暢捷通在 2021 年中國小微企業(yè)云財(cái)稅市場份額排名第一，在產(chǎn)品前瞻性及行業(yè)全覆蓋方面領(lǐng)跑市場，位居中國小微企業(yè)云財(cái)稅廠商矩陣領(lǐng)軍象限前列。作為專注小微企業(yè)云服務(wù)、軟件提供商，暢捷通于 2017 年在業(yè)內(nèi)創(chuàng)新提出“智公司”的概念，于 2018 年進(jìn)一步豐富提出了“智能商業(yè)范式六步法”，旨在幫助小微企業(yè)明確、精準(zhǔn)的走向智能化。暢捷通針對小微企業(yè)財(cái)務(wù)及管理轉(zhuǎn)型問題，通過技術(shù)賦能，幫助小微企業(yè)實(shí)現(xiàn)人員在線、業(yè)務(wù)在線、客戶在線、管理在線，改變傳統(tǒng)的經(jīng)營業(yè)態(tài)，推動數(shù)智化升級轉(zhuǎn)型。

市場數(shù)據(jù)來源于艾瑞咨詢發(fā)布的《2022 年中國小微企業(yè)云財(cái)稅行業(yè)研究報(bào)告》

在數(shù)字經(jīng)濟(jì)快速發(fā)展的戰(zhàn)略機(jī)遇下，小微企業(yè)積極謀求業(yè)務(wù)轉(zhuǎn)型，利用數(shù)智化手段增收、降本、提效的需求將進(jìn)一步增強(qiáng)。暢捷通以數(shù)智財(cái)稅，數(shù)智商業(yè)為核心，以生態(tài)服務(wù)為延展，提供小微企業(yè)云服務(wù)，推出了一系列 SaaS 產(chǎn)品，包括好會計(jì)（智能云財(cái)稅）、好生意（營銷型云進(jìn)銷存）、T Cloud（全場景數(shù)智商業(yè)云應(yīng)用）、好業(yè)財(cái)（創(chuàng)新企業(yè)數(shù)智經(jīng)營平臺）、易代賬（數(shù)智財(cái)稅平臺）等，暢捷通云平臺累計(jì)注冊用戶數(shù)超過 800 萬。

業(yè)務(wù)及技術(shù)背景

Cloud Native

暢捷通有 5 個(gè)核心 SaaS 產(chǎn)品，均以數(shù)智財(cái)稅、數(shù)智商業(yè)為核心，以數(shù)據(jù)服務(wù)與生態(tài)服務(wù)為延展，提供小微企業(yè)云服務(wù)。

• 好會計(jì)：票財(cái)稅一體化的智能云財(cái)稅系統(tǒng)，幫助財(cái)務(wù)人員通過 PC 端、手機(jī)端、微信端隨時(shí)隨地管理現(xiàn)金銀行、發(fā)票、往來、報(bào)稅、經(jīng)營分析等。
• 好生意：營銷型云進(jìn)銷存系統(tǒng)，以幫助企業(yè)管店拓客為核心，實(shí)現(xiàn)智能獲客找生意，智能決策做生意，智能高效管生意。
• T Cloud：數(shù)智商業(yè)云服務(wù)，幫助創(chuàng)新型企業(yè)通過數(shù)智化手段快速獲取廣泛的商業(yè)資源（客源、貨源、資金及專業(yè)服務(wù)），對經(jīng)營管理要素（人/財(cái)/貨/客/數(shù)）實(shí)現(xiàn)有效的精細(xì)化、數(shù)字化、智能化管理。
• 易代賬：面向代賬會計(jì)和代賬公司設(shè)計(jì)的云應(yīng)用，集管理、記賬、報(bào)稅于一體的智能財(cái)稅系統(tǒng)。
• 好業(yè)財(cái)：面向小型商貿(mào)、工貿(mào)一體、零售企業(yè)的云服務(wù)產(chǎn)品，以數(shù)智化經(jīng)營管理為核心，幫助企業(yè)實(shí)現(xiàn)業(yè)財(cái)稅票一體化，全渠道全場景移動管理，實(shí)現(xiàn)線上線下數(shù)據(jù)協(xié)同，全面提升企業(yè)競爭力。

大家知道 SaaS 軟件基本都是面向 To B 的業(yè)務(wù)，雖然在請求量和流量方面遠(yuǎn)不如 To C 業(yè)務(wù)的系統(tǒng)，但是對于穩(wěn)定性和安全性的要求遠(yuǎn)遠(yuǎn)高于面向 To C 的業(yè)務(wù)，并且因?yàn)樯婕暗臉I(yè)務(wù)領(lǐng)域更深，產(chǎn)品的功能會異常復(fù)雜，且模塊和模塊之間都有著緊密的聯(lián)系，像多租戶管理、租戶數(shù)據(jù)隔離、網(wǎng)絡(luò)隔離、系統(tǒng)擴(kuò)展性（aPaaS 能力）、BI（數(shù)據(jù)展示分析）等都是暢捷通要解決的難題。

所以這 5 個(gè)核心系統(tǒng)基本是生在云上，長在云上的，在暢捷通發(fā)展的這 13 年里，IT 技術(shù)架構(gòu)也在不斷的做改進(jìn)優(yōu)化，目的就是能更好的解決上述的那些難點(diǎn)問題。

• 部署架構(gòu)演進(jìn)路線：

• 主部署架構(gòu)：傳統(tǒng) ECS 部署架構(gòu) -> K8s 部署架構(gòu)
• 探索型部署架構(gòu)：Serverless 部署架構(gòu)

• 技術(shù)架構(gòu)演進(jìn)路線：Java 單體服務(wù) -> 基于 HSF 的分布式架構(gòu) -> 基于 Java SpringCloud 的微服務(wù)架構(gòu) -> Serverless 函數(shù)架構(gòu)

從部署架構(gòu)的演進(jìn)來看，暢捷通很早就看到了 K8s 能給產(chǎn)品和產(chǎn)研團(tuán)隊(duì)帶來的價(jià)值，在 CTO 的果斷決策下，重投入進(jìn)行容器化改造，將之前的 ECS 部署架構(gòu)改為 K8s 部署架構(gòu)，并且選擇了阿里云 ACK，到目前，有十幾個(gè) ACK 集群在穩(wěn)定支撐暢捷通的核心業(yè)務(wù)。

技術(shù)架構(gòu)的演進(jìn)其實(shí)是和部署架構(gòu)的演進(jìn)相輔相成的，Java 單體服務(wù)和 HSF 存在于 ECS 部署架構(gòu)，在做容器化轉(zhuǎn)型的階段，同時(shí)對服務(wù)進(jìn)行了微服務(wù)的轉(zhuǎn)型，并且也引入了消息中間件（RocketMQ，RabbitMQ）來輔助微服務(wù)的轉(zhuǎn)型。

在大環(huán)境的驅(qū)使下，降本增效基本已經(jīng)成為了每家企業(yè)的核心 KPI，暢捷通也不例外，但暢捷通似乎更能居安思危，因?yàn)樵缭?2020 年，就因?yàn)楦倪M(jìn)效率的問題，開始調(diào)研 Serverless 技術(shù)，這也是暢捷通現(xiàn)在部署架構(gòu)和技術(shù)架構(gòu)在持續(xù)向 Serverless 演進(jìn)埋下的最早的伏筆。

為什么選擇 Serverless

Cloud Native

Serverless 技術(shù)概念出現(xiàn)于 2012 年，興起于 2014 年（AWS Lambda），國內(nèi)云廠商在 2017 年開始有相關(guān)的產(chǎn)品推出，經(jīng)過多年的發(fā)展，Serverless 技術(shù)在落地場景、產(chǎn)品體驗(yàn)、穩(wěn)定性等方面逐步趨于成熟。Serverless 其實(shí)是 Server less 的組合，并不是真的沒有服務(wù)器，而是幫助使用者屏蔽底層繁瑣的服務(wù)器維護(hù)，讓企業(yè)更加專注于業(yè)務(wù)。業(yè)界普遍認(rèn)為 Serverless = FaaS（即 Function as a Service） BaaS（即 Backend as a Service），支持自動彈性伸縮和按量付費(fèi)。

其實(shí) Serverless 技術(shù)剛興起的時(shí)候特指 FaaS，也就是函數(shù)計(jì)算的產(chǎn)品形態(tài)，經(jīng)過這么多年的演進(jìn)，已經(jīng)擴(kuò)展到 Serverless 技術(shù)理念和 Serverless 應(yīng)用架構(gòu)，云廠商也圍繞 Serverless 推出了非常多相關(guān)的產(chǎn)品和服務(wù)，涵蓋計(jì)算、存儲、數(shù)據(jù)庫和大數(shù)據(jù)等，幫助企業(yè)用戶構(gòu)建 Serverless 應(yīng)用。

暢捷通非 Serverless 架構(gòu)如何向 Serverless 架構(gòu)轉(zhuǎn)型，實(shí)現(xiàn)降本增效，提高資源利用率。Serverless 技術(shù)理念是指 Zero Server Ops No Compute Cost When Idle，核心思想是讓企業(yè)聚焦業(yè)務(wù)，降低 Ops。因此按照 Serverless 的理念，運(yùn)維工作會被極大簡化，研發(fā)人員一定程度上可以操控資源的使用，進(jìn)而提升業(yè)務(wù)迭代效率。所以這個(gè)理念非常契合暢捷通研發(fā)、運(yùn)維團(tuán)隊(duì)的發(fā)展思路。

Serverless 技術(shù)調(diào)研

Cloud Native

暢捷通是一家積極擁抱云的企業(yè)，對一切新的技術(shù)領(lǐng)域都有著求知欲，暢捷通總架構(gòu)師鄭蕓女士多次組織核心研發(fā)運(yùn)維同學(xué)和我們深入了解 Serverless 技術(shù)領(lǐng)域，從底層架構(gòu)實(shí)現(xiàn)、適用的業(yè)務(wù)場景、對現(xiàn)有業(yè)務(wù)的改造成本等幾個(gè)方面來綜合分析，最終確定使用函數(shù)計(jì)算 FC 作為試點(diǎn)，開始 Serverless 的探索之路。

函數(shù)計(jì)算業(yè)務(wù)場景

針對 SaaS 系統(tǒng)，函數(shù)計(jì)算最適合的場景應(yīng)該是 HTTP、Web 應(yīng)用場景，大數(shù)據(jù) ETL 場景和周期性任務(wù)場景，而暢捷通之后落地的項(xiàng)目基本都屬于這三類場景。

非 Serverless 架構(gòu)如何向 Serverless 架構(gòu)轉(zhuǎn)型

選定好場景后，就需要解決如何轉(zhuǎn)型的問題，這里的轉(zhuǎn)型有個(gè)維度的概念：

• 現(xiàn)存非 Serverless 架構(gòu)業(yè)務(wù)向 Serverless 架構(gòu)轉(zhuǎn)型：會涉及到較大成本的改造問題
• 新業(yè)務(wù)直接采用 Serverless 架構(gòu)：遵循 Serverless 架構(gòu)最佳實(shí)踐范式即可

暢捷通這兩部分都有涉及到，根據(jù)函數(shù)計(jì)算的概念，我們也總結(jié)了轉(zhuǎn)型最佳實(shí)踐，包括編程語言的選擇、運(yùn)行環(huán)境的選擇、DevOps 改造流程、代碼改造流程等，一起和暢捷通逐一進(jìn)行驗(yàn)證。

Serverless 實(shí)踐

試金石-SQL 腳本執(zhí)行任務(wù)

Cloud Native

暢捷通的 Serverless 實(shí)踐是漸進(jìn)迭代的路線，在技術(shù)調(diào)研后，第一個(gè)試點(diǎn)項(xiàng)目是運(yùn)維中的 SQL 腳本執(zhí)行任務(wù)，因?yàn)槊嫦?To B 客戶的 SaaS 系統(tǒng)，出于穩(wěn)定性的考慮，發(fā)版的節(jié)奏一般都不會特別的頻繁，但每次發(fā)版的工作量是非常大的，尤其在發(fā)布大版本時(shí)，其中有一項(xiàng)重中之重的任務(wù)就是批量跑 SQL 腳本，要么更新元數(shù)據(jù)，要么更新表結(jié)構(gòu)。主要在 T Cloud 這個(gè)系統(tǒng)中試點(diǎn)，這個(gè)試點(diǎn)項(xiàng)目改造起來相對比較簡單，風(fēng)險(xiǎn)也比較可控，屬于客戶小試牛刀。

原有方式的痛點(diǎn)

批量跑 SQL 腳本任務(wù)是需要計(jì)算資源的，但這些計(jì)算資源的使用率極低，所以不可能長期儲備著計(jì)算資源，但如果要從支撐業(yè)務(wù)的資源中分配的話，那可能又會對業(yè)務(wù)產(chǎn)生影響。另外每次跑批時(shí)需要在計(jì)算量也不算小，所以每次就得靠運(yùn)維人員手動加減服務(wù)器，費(fèi)時(shí)費(fèi)力，有時(shí)候因?yàn)橘Y源不能及時(shí)準(zhǔn)備好，從而影響發(fā)版進(jìn)度，有時(shí)候忘記釋放資源，又會產(chǎn)生額外的費(fèi)用。所以核心的痛點(diǎn)就是提高效率、提升運(yùn)維幸福度。

Serverless 架構(gòu)

基于 Serverless 按需所取，按量計(jì)費(fèi)的特點(diǎn)，將執(zhí)行 SQL 腳本的任務(wù)放在了函數(shù)計(jì)算中，做到了在發(fā)版要執(zhí)行 SQL 腳本的時(shí)候，按需通過運(yùn)維管理平臺請求函數(shù)計(jì)算，通過自動拉起所需計(jì)算資源來處理 SQL 腳本，腳本執(zhí)行完后自動釋放，相當(dāng)于有一個(gè)隨用隨取的資源池供客戶使用。改造為 Serverless 架構(gòu)后，主要帶來了以下優(yōu)勢：

• 徹底解決了按需所取的計(jì)算資源問題，運(yùn)維人員不需要再花額外時(shí)間考慮準(zhǔn)備資源的問題。
• 得益于函數(shù)計(jì)算的彈性速度和并發(fā)擴(kuò)展能力，Serverless 架構(gòu)下，在保證 SQL 腳本之間順序性的前提下，并行執(zhí)行 SQL 腳本的能力大幅提升，有效縮短了發(fā)版持續(xù)時(shí)間。
• 函數(shù)計(jì)算異步請求有后處理機(jī)制，即當(dāng)函數(shù)執(zhí)行成功或者執(zhí)行失敗后，可以設(shè)置目標(biāo)服務(wù)及時(shí)做后處理，在這個(gè)場景下，可以有效自動化處理執(zhí)行失敗的 SQL 腳本任務(wù)，比如執(zhí)行失敗后發(fā)送消息，或者執(zhí)行失敗后重試執(zhí)行，或者再拉起另一個(gè)函數(shù)做補(bǔ)償邏輯等等。極大的提升了 SQL 腳本批量執(zhí)行的穩(wěn)定性。

Serverless 實(shí)踐全面開花

Cloud Native

在 SQL 腳本執(zhí)行任務(wù)這個(gè)試點(diǎn)項(xiàng)目中，Serverless 架構(gòu)切實(shí)的給客戶帶來的價(jià)值，所以暢捷通逐漸尋找其他適合函數(shù)計(jì)算的場景。

運(yùn)維工具集

在實(shí)踐 Serverless 架構(gòu)時(shí)，大多數(shù)客戶都有一個(gè)慣性思維，那就是先找邊緣非核心業(yè)務(wù)試點(diǎn)，達(dá)到預(yù)期效果后，開始從運(yùn)維側(cè)入手展開，暢捷通也不例外。所以第二個(gè)開始實(shí)踐 Serverless 架構(gòu)的項(xiàng)目其實(shí)是 SQL 腳本任務(wù)這個(gè)點(diǎn)的延展，就是將整個(gè)運(yùn)維管理平臺中合適的場景都替換為函數(shù)計(jì)算。因?yàn)檫\(yùn)維管理平臺相比業(yè)務(wù)系統(tǒng)，對資源的需求也是較為低頻的，其中的一些任務(wù)執(zhí)行可能一天就幾次，甚至一個(gè)月幾次，所以本質(zhì)上都是將各種運(yùn)維任務(wù)腳本放在函數(shù)計(jì)算中運(yùn)行。除了享受到了函數(shù)計(jì)算資源按需所取，大并發(fā)執(zhí)行，后處理容錯(cuò)機(jī)制等紅利外，還有一點(diǎn)優(yōu)勢就是在快速修復(fù)腳本異常的場景下，函數(shù)計(jì)算有先天優(yōu)勢。

• 函數(shù)計(jì)算提供了 WebIDE，對于需要快速修復(fù)腳本異常的情況下，可以快速打開控制臺，在 WebIDE 中修改腳本，一鍵部署發(fā)布即可。在應(yīng)急場景下非常有效。
• 函數(shù)計(jì)算提供了灰度版本的能力，所以在需要快速修復(fù)問題的場景下，也可以快速創(chuàng)建一個(gè)新版本，然后在運(yùn)行態(tài)快速切換版本，保留下來歷史版本，用于后續(xù)分析。

開放平臺

我們通常評判 SaaS 產(chǎn)品的能力好壞時(shí)，對業(yè)務(wù)領(lǐng)域的理解深度固然重要，但也有另一個(gè)非常重點(diǎn)的衡量標(biāo)準(zhǔn)就是它是否具備 aPaaS 可擴(kuò)展能力或者 API 開放平臺，因?yàn)樗P(guān)系到這個(gè) SaaS 產(chǎn)品未來能走多遠(yuǎn)，比如訂閱付費(fèi)和定制化交付收入的占比，上下游生態(tài)的建設(shè)等。暢捷通的SaaS產(chǎn)品就有很強(qiáng)的擴(kuò)展能力和 API 開放平臺。

暢捷通的 API 開放平臺有一個(gè)使用很廣泛的場景就是他們的用戶去對接三方的系統(tǒng)，或者其他的 SaaS 系統(tǒng)，比如接美團(tuán)的消息，接餓了么的消息等，在這個(gè)場景下又有很明顯的 To C 特征，即消息量的波動很大，高峰期消息 TPS 可以達(dá)到萬級別，但低峰期的消息 TPS 可能只有幾十。所以在這個(gè)場景下，有這么幾個(gè)痛點(diǎn)問題：

• 對接的系統(tǒng)無法統(tǒng)一標(biāo)準(zhǔn)，需要支持多種協(xié)議，比如對接三方 SaaS 系統(tǒng)大多數(shù)是 HTTP 協(xié)議，對接一些用戶的自研系統(tǒng)可能希望走 MQ 協(xié)議，或者 Kafka 協(xié)議。為了適配多種接收協(xié)議，后端就需要實(shí)現(xiàn)多套代碼。維護(hù)成本高。
• 消息流波動極大，波峰波谷相差幾萬 TPS，導(dǎo)致儲備資源時(shí)只能按照峰值儲備，資源利用率極低，成本浪費(fèi)嚴(yán)重。

這些痛點(diǎn)又完美命中了函數(shù)計(jì)算的核心特點(diǎn)，結(jié)合前兩個(gè)場景中函數(shù)計(jì)算的良好表現(xiàn)，所以暢捷通第三個(gè)試點(diǎn)項(xiàng)目就是 API 開放平臺，將接受三方消息，處理消息的架構(gòu)換為函數(shù)計(jì)算架構(gòu)。

從架構(gòu)圖上可以看出，處理消息或者請求的函數(shù)邏輯是一致的，只是接收協(xié)議不同，所以使用函數(shù)計(jì)算可以方便維護(hù)三個(gè)邏輯一樣的函數(shù)，但是分別具有不同的觸發(fā)器，這樣只需要維護(hù)一套代碼即可實(shí)現(xiàn)多種接收協(xié)議的場景。

說到函數(shù)計(jì)算的觸發(fā)器，就不得不說 Serverless 架構(gòu)的另一個(gè)優(yōu)勢，就是生態(tài)集成：

函數(shù)計(jì)算上游對接了近百種觸發(fā)器，所以如果采用了函數(shù)計(jì)算架構(gòu)，那相當(dāng)于已經(jīng)具備了和阿里云近百種產(chǎn)品的集成與被集成能力，極大的提升了效率和降低了集成成本。

所以暢捷通將 API 開放平臺轉(zhuǎn)型為 Serverless 架構(gòu)，也是收獲滿滿：

• 通過函數(shù)計(jì)算觸發(fā)器解決了多種接收協(xié)議下維護(hù)多套代碼的問題。
• 極大的提升了資源利用率，有效優(yōu)化了資源成本。在這個(gè)場景下，處理消息的函數(shù)使用 Go 語言，使用 0.1c 和 0.05c 規(guī)格的函數(shù)實(shí)例，并且采用單實(shí)例多并發(fā)。在有幾萬消息的峰值情況下，只需要十幾個(gè)函數(shù)實(shí)例就可以穩(wěn)定支撐，相比原有的 K8s 架構(gòu)，成本從幾千元每月節(jié)省到了幾百元每月。

智能補(bǔ)貨業(yè)務(wù)

隨著試點(diǎn) Serverless 架構(gòu)的項(xiàng)目越來越多，同時(shí)也獲得了巨大的收益，暢捷通開始逐漸將 Serverless 架構(gòu)實(shí)踐的眼光看向了核心業(yè)務(wù)。也許這就是命運(yùn)的安排，正好暢捷通有一塊新業(yè)務(wù)開始規(guī)劃設(shè)計(jì)，函數(shù)計(jì)算被考慮了進(jìn)去，這就是智能補(bǔ)貨業(yè)務(wù)。該業(yè)務(wù)是根據(jù)企業(yè)的業(yè)務(wù)數(shù)據(jù)，按商品的庫存、采購、銷售或材料消耗規(guī)律，幫助采購員創(chuàng)立補(bǔ)貨模型，從而快捷地幫助采購員計(jì)算、生成補(bǔ)貨參考結(jié)果的智能化助手。

該業(yè)務(wù)由于業(yè)務(wù)數(shù)據(jù)量大，采用了離線 實(shí)時(shí)數(shù)據(jù)同步計(jì)算，需要參與補(bǔ)貨計(jì)算的檔案、業(yè)務(wù)數(shù)據(jù)同步到數(shù)據(jù)倉庫中，并對數(shù)據(jù)根據(jù)業(yè)務(wù)需求定義進(jìn)行預(yù)加工處理，整體有以下這些性質(zhì)：

• 具有突發(fā)流量特性，由于計(jì)算的數(shù)據(jù)量比較大，用戶可以選擇近半年甚至一年的業(yè)務(wù)數(shù)據(jù)進(jìn)行計(jì)算分析，是個(gè)密集型計(jì)算，所以對計(jì)算資源的要求較高，如果傳統(tǒng)部署架構(gòu)頂著業(yè)務(wù)流量峰值儲備的話，勢必又有成本浪費(fèi)的問題。
• 智能補(bǔ)貨業(yè)務(wù)它不是一個(gè)新的產(chǎn)品，而是已有產(chǎn)品中的一個(gè)新的業(yè)務(wù)模塊，受限于微服務(wù)的拆分粒度，這部分邏輯會和已有的業(yè)務(wù)邏輯耦合度很高，所以如果運(yùn)算補(bǔ)貨算法邏輯時(shí)消耗大量資源，有可能存在搶占資源問題，影響到已有業(yè)務(wù)的穩(wěn)定性。
• 智能補(bǔ)貨，除了主打智能以外，也支持用戶自定義補(bǔ)貨規(guī)則，所以在一定程度上每個(gè)用戶的補(bǔ)貨規(guī)則就像一個(gè)一個(gè)業(yè)務(wù)流程，那整個(gè)系統(tǒng)需要具備調(diào)度和編排這種業(yè)務(wù)流程的能力。

所以總結(jié)下來，智能補(bǔ)貨業(yè)務(wù)有三個(gè)特點(diǎn)：

• 有流量潮汐特性，希望計(jì)算資源有較強(qiáng)的擴(kuò)展能力。
• 希望計(jì)算資源獨(dú)立，不搶占支持現(xiàn)有業(yè)務(wù)的資源。
• 希望有一套架構(gòu)支撐規(guī)則的靈活調(diào)度和編排。

這里又出現(xiàn)了函數(shù)計(jì)算的一個(gè)核心特點(diǎn)，那就是具備 Serverless 工作流的編排能力，我們先看架構(gòu)圖：

可以看到，補(bǔ)貨算法邏輯層全部放在了函數(shù)計(jì)算中，和部署在 ACK 中的上下游業(yè)務(wù)互通，通過函數(shù)計(jì)算快速彈性能力解決流量潮汐下資源利用和成本問題，同時(shí)將這部分耗資源的邏輯剝離出來，也解決了資源搶占的問題。

對于補(bǔ)貨規(guī)則靈活制定這部分，結(jié)合了 Serverless 工作流，每一個(gè)規(guī)則就是一個(gè)流程，流程中的每一個(gè)函數(shù)就是規(guī)則中的一個(gè)個(gè)算子，Serverless 工作流不止支持對函數(shù)計(jì)算的編排，也支持其他數(shù)學(xué)邏輯運(yùn)算和其他阿里云的核心產(chǎn)品，比如 ECS、SAE、ACK、OSS 等，同時(shí)在版本管理和發(fā)布管理方面也是比較成熟。所以通過這一套架構(gòu)增強(qiáng)業(yè)務(wù)功能的可擴(kuò)展性。

雖然該業(yè)務(wù)對時(shí)延不敏感，但我們也盡最大可能對 Java 函數(shù)的冷啟動問題進(jìn)行了優(yōu)化，比如使用鏡像加速能力，JDK 使用阿里云優(yōu)化過的 Dragonwell，開啟預(yù)留實(shí)例 閑置計(jì)費(fèi)等，從而達(dá)到該業(yè)務(wù)對時(shí)延的要求。另外對于 Snapshot 這些更深一層的技術(shù)優(yōu)化我們也已經(jīng)開始了調(diào)研和排期，盡最大努力徹底解決 Java 函數(shù)的冷啟動問題。

更多業(yè)務(wù)場景

到目前為止，除了上文中提到的四個(gè)場景外，暢捷通還有其他使用 Serverless 架構(gòu)實(shí)踐的場景，都取得了預(yù)期的受益，比如 RPA 業(yè)務(wù)，零售數(shù)據(jù)全租戶離線下載，離線數(shù)據(jù)處理等。覆蓋了運(yùn)維領(lǐng)域，核心業(yè)務(wù)領(lǐng)域，大數(shù)據(jù)領(lǐng)域，相信未來還會有更多的場景會轉(zhuǎn)型為 Serverless 架構(gòu)。

同行者的建議

Cloud Native

Serverless 從根本上降低了用云的門檻和成本，Serverless 在業(yè)界的發(fā)展歷程也已經(jīng)超過 8 年，從落地效果看，阿里云函數(shù)計(jì)算是比較適合 SaaS 系統(tǒng)企業(yè)的。同時(shí)函數(shù)計(jì)算目前也在做 AIGC 場景，致力于幫用戶以更低的門檻接入大模型服務(wù)。

去年開始，阿里云在大力推廣 Serverless 產(chǎn)品服務(wù)，升級到了戰(zhàn)略地位，包括提出 All in Serverless，目前云消息隊(duì)列 MQ 計(jì)劃在云棲大會后推出 Serverless 版、數(shù)據(jù)庫 RDS 已經(jīng)推出了 Serverless 版本、大數(shù)據(jù)團(tuán)隊(duì)也在推進(jìn) Serverless 化，從用戶視角，我認(rèn)為這是非常利好的。

通過全面的 Serverless 產(chǎn)品和服務(wù)，可以構(gòu)建端到端的 Serverless 架構(gòu)或者應(yīng)用，這帶來的改變是顛覆性的。與其觀望，不如提前擁抱，期望暢捷通關(guān)于 Serverless 的實(shí)踐經(jīng)驗(yàn)?zāi)芙o更多企業(yè)帶來一些啟發(fā)。