暢捷通介紹
暢捷通是中國領先的小微企業財稅及業務雲服務提供商，成立於2010年。暢捷通在2021年中國小微企業雲財稅市場份額排名第一，在產品前瞻性及行業全覆蓋方面領跑市場，位居中國小微企業雲財稅廠商矩陣領軍象限前列。作爲專注小微企業雲服務、軟件提供商，暢捷通於2017年在業內創新提出“智公司”的概念，於2018年進一步豐富提出了“智能商業範式六步法”，旨在幫助小微企業明確、精準的走向智能化。暢捷通針對小微企業財務及管理轉型問題，通過技術賦能，幫助小微企業實現人員在線、業務在線、客戶在線、管理在線，改變傳統的經營業態，推動數智化升級轉型。
市場數據來源於艾瑞諮詢發佈的《2022年中國小微企業雲財稅行業研究報告》
在數字經濟快速發展的戰略機遇下，小微企業積極謀求業務轉型，利用數智化手段增收、降本、提效的需求將進一步增強。暢捷通以數智財稅，數智商業爲核心，以生態服務爲延展，提供小微企業雲服務，推出了一系列SaaS產品，包括好會計（智能雲財稅）、好生意（營銷型雲進銷存）、T+Cloud（全場景數智商業雲應用）、好業財（創新企業數智經營平臺）、易代賬（數智財稅平臺）等，暢捷通雲平臺累計註冊用戶數超過800萬。
業務及技術背景
暢捷通有5個核心SaaS產品，均以數智財稅、數智商業爲核心，以數據服務與生態服務爲延展，提供小微企業雲服務。
- 好會計：票財稅一體化的智能雲財稅系統，幫助財務人員通過 PC 端、手機端、微信端隨時隨地管理現金銀行、發票、往來、報稅、經營分析等。
- 好生意：營銷型雲進銷存系統，以幫助企業管店拓客爲核心，實現智能獲客找生意，智能決策做生意，智能高效管生意。
- T+Cloud：數智商業雲服務，幫助創新型企業通過數智化手段快速獲取廣泛的商業資源（客源、貨源、資金及專業服務），對經營管理要素（人/財/貨/客/數）實現有效的精細化、數字化、智能化管理。
- 易代賬：面向代賬會計和代賬公司設計的雲應用，集管理、記賬、報稅於一體的智能財稅系統。
- 好業財：面向小型商貿、工貿一體、零售企業的雲服務產品，以數智化經營管理爲核心，幫助企業實現業財稅票一體化，全渠道全場景移動管理，實現線上線下數據協同，全面提升企業競爭力。
大家知道SaaS軟件基本都是面向To B的業務，雖然在請求量和流量方面遠不如To C業務的系統，但是對於穩定性和安全性的要求遠遠高於面向To C的業務，並且因爲涉及的業務領域更深，產品的功能會異常複雜，且模塊和模塊之間都有着緊密的聯繫，像多租戶管理、租戶數據隔離、網絡隔離、系統擴展性（aPaaS能力）、BI（數據展示分析）等都是暢捷通要解決的難題。
所以這5個核心繫統基本是生在雲上，長在雲上的，在暢捷通發展的這13年裏，IT技術架構也在不斷的做改進優化，目的就是能更好的解決上述的那些難點問題。
- 部署架構演進路線：
- 主部署架構：傳統ECS部署架構 -> K8s部署架構
- 探索型部署架構：Serverless部署架構
- 技術架構演進路線：Java單體服務 -> 基於HSF的分佈式架構 -> 基於Java SpringCloud的微服務架構 -> Serverless 函數架構
從部署架構的演進來看，暢捷通很早就看到了K8s能給產品和產研團隊帶來的價值，在CTO的果斷決策下，重投入進行容器化改造，將之前的ECS部署架構改爲K8s部署架構，並且選擇了阿里雲ACK，到目前，有十幾個ACK集羣在穩定支撐暢捷通的核心業務。
技術架構的演進其實是和部署架構的演進相輔相成的，Java單體服務和HSF存在於ECS部署架構，在做容器化轉型的階段，同時對服務進行了微服務的轉型，並且也引入了消息中間件（RocketMQ，RabbitMQ）來輔助微服務的轉型。
在大環境的驅使下，降本增效基本已經成爲了每家企業的核心KPI，暢捷通也不例外，但暢捷通似乎更能居安思危，因爲早在2020年，就因爲改進效率的問題，開始調研Serverless技術，這也是暢捷通現在部署架構和技術架構在持續向Serverless演進埋下的最早的伏筆。
爲什麼選擇Serverless
Serverless 技術概念出現於2012年，興起於 2014 年（AWS Lambda），國內雲廠商在 2017 年開始有相關的產品推出，經過多年的發展，Serverless 技術在落地場景、產品體驗、穩定性等方面逐步趨於成熟。Serverless 其實是 Server + less 的組合，並不是真的沒有服務器，而是幫助使用者屏蔽底層繁瑣的服務器維護，讓企業更加專注於業務。業界普遍認爲 Serverless = FaaS（即 Function as a Service） + BaaS（即 Backend as a Service），支持自動彈性伸縮和按量付費。其實 Serverless 技術剛興起的時候特指 FaaS，也就是函數計算的產品形態，經過這麼多年的演進，已經擴展到 Serverless 技術理念和 Serverless 應用架構，雲廠商也圍繞 Serverless 推出了非常多相關的產品和服務，涵蓋計算、存儲、數據庫和大數據等，幫助企業用戶構建 Serverless 應用。
Serverless 技術理念是指 Zero Server Ops + No Compute Cost When Idle，核心思想是讓企業聚焦業務，降低 Ops。因此按照 Serverless 的理念，運維工作會被極大簡化，研發人員一定程度上可以操控資源的使用，進而提升業務迭代效率。所以這個理念非常契合暢捷通研發、運維團隊的發展思路。
Serverless技術調研
暢捷通是一家積極擁抱雲的企業，對一切新的技術領域都有着求知慾，暢捷通總架構師鄭芸女士多次組織核心研發運維同學和我們深入瞭解Serverless技術領域，從底層架構實現、適用的業務場景、對現有業務的改造成本等幾個方面來綜合分析，最終確定使用函數計算FC作爲試點，開始Serverless的探索之路。
函數計算業務場景
針對SaaS系統，函數計算最適合的場景應該是HTTP、Web應用場景，大數據ETL場景和週期性任務場景，而暢捷通之後落地的項目基本都屬於這三類場景。
非Serverless架構如何向非Serverless架構轉型
選定好場景後，就需要解決如何轉型的問題，這裏的轉型有個維度的概念：
- 現存非Serverless架構業務向Serverless架構轉型：會涉及到較大成本的改造問題
- 新業務直接採用Serverless架構：遵循Serverless架構最佳實踐範式即可
暢捷通這兩部分都有涉及到，根據函數計算的概念，我們也總結了轉型最佳實踐，包括編程語言的選擇、運行環境的選擇、DevOps改造流程、代碼改造流程等，一起和暢捷通逐一進行驗證。
Serverless實踐試金石 - SQL腳本執行任務
暢捷通的Serverless實踐是漸進迭代的路線，在技術調研後，第一個試點項目是運維中的SQL腳本執行任務，因爲面向To B客戶的SaaS系統，出於穩定性的考慮，發版的節奏一般都不會特別的頻繁，但每次發版的工作量是非常大的，尤其在發佈大版本時，其中有一項重中之重的任務就是批量跑SQL腳本，要麼更新元數據，要麼更新表結構。主要在T+Cloud這個系統中試點，這個試點項目改造起來相對比較簡單，風險也比較可控，屬於客戶小試牛刀。
原有方式的痛點
批量跑SQL腳本任務是需要計算資源的，但這些計算資源的使用率極低，所以不可能長期儲備着計算資源，但如果要從支撐業務的資源中分配的話，那可能又會對業務產生影響。另外每次跑批時需要在計算量也不算小，所以每次就得靠運維人員手動加減服務器，費時費力，有時候因爲資源不能及時準備好，從而影響發版進度，有時候忘記釋放資源，又會產生額外的費用。所以核心的痛點就是提高效率、提升運維幸福度。
Serverless架構
基於Serverless按需所取，按量計費的特點，將執行SQL腳本的任務放在了函數計算中，做到了在發版要執行SQL腳本的時候，按需通過運維管理平臺請求函數計算，通過自動拉起所需計算資源來處理SQL腳本，腳本執行完後自動釋放，相當於有一個隨用隨取的資源池供客戶使用。改造爲Serverless架構後，主要帶來了以下優勢：
- 徹底解決了按需所取的計算資源問題，運維人員不需要再花額外時間考慮準備資源的問題。
- 得益於函數計算的彈性速度和併發擴展能力，Serverless架構下，在保證SQL腳本之間順序性的前提下，並行執行SQL腳本的能力大幅提升，有效縮短了發版持續時間。
- 函數計算異步請求有後處理機制，即當函數執行成功或者執行失敗後，可以設置目標服務及時做後處理，在這個場景下，可以有效自動化處理執行失敗的SQL腳本任務，比如執行失敗後發送消息，或者執行失敗後重試執行，或者再拉起另一個函數做補償邏輯等等。極大的提升了SQL腳本批量執行的穩定性。
Serverless實踐全面開花
在SQL腳本執行任務這個試點項目中，Serverless架構切實的給客戶帶來的價值，所以暢捷通逐漸尋找其他適合函數計算的場景。
運維工具集
在實踐Serverless架構時，大多數客戶都有一個慣性思維，那就是先找邊緣非核心業務試點，達到預期效果後，開始從運維側入手展開，暢捷通也不例外。所以第二個開始實踐Serverless架構的項目其實是SQL腳本任務這個點的延展，就是將整個運維管理平臺中合適的場景都替換爲函數計算。因爲運維管理平臺相比業務系統，對資源的需求也是較爲低頻的，其中的一些任務執行可能一天就幾次，甚至一個月幾次，所以本質上都是將各種運維任務腳本放在函數計算中運行。除了享受到了函數計算資源按需所取，大併發執行，後處理容錯機制等紅利外，還有一點優勢就是在快速修復腳本異常的場景下，函數計算有先天優勢。
- 函數計算提供了WebIDE，對於需要快速修復腳本異常的情況下，可以快速打開控制檯，在WebIDE中修改腳本，一鍵部署發佈即可。在應急場景下非常有效。
- 函數計算提供了灰度版本的能力，所以在需要快速修復問題的場景下，也可以快速創建一個新版本，然後在運行態快速切換版本，保留下來歷史版本，用於後續分析。
開放平臺
我們通常評判SaaS產品的能力好壞時，對業務領域的理解深度固然重要，但也有另一個非常重點的衡量標準就是它是否具備aPaaS可擴展能力或者API開放平臺，因爲它關係到這個SaaS產品未來能走多遠，比如訂閱付費和定製化交付收入的佔比，上下游生態的建設等。暢捷通的SaaS產品就有很強的擴展能力和API開放平臺。
暢捷通的API開放平臺有一個使用很廣泛的場景就是他們的用戶去對接三方的系統，或者其他的SaaS系統，比如接美團的消息，接餓了麼的消息等，在這個場景下又有很明顯的To C特徵，即消息量的波動很大，高峯期消息TPS可以達到萬級別，但低峯期的消息TPS可能只有幾十。所以在這個場景下，有這麼幾個痛點問題：
- 對接的系統無法統一標準，需要支持多種協議，比如對接三方SaaS系統大多數是HTTP協議，對接一些用戶的自研系統可能希望走MQ協議，或者Kafka協議。爲了適配多種接收協議，後端就需要實現多套代碼。維護成本高。
- 消息流波動極大，波峯波谷相差幾萬TPS，導致儲備資源時只能按照峯值儲備，資源利用率極低，成本浪費嚴重。
這些痛點又完美命中了函數計算的核心特點，結合前兩個場景中函數計算的良好表現，所以暢捷通第三個試點項目就是API開放平臺，將接受三方消息，處理消息的架構換爲函數計算架構。
從架構圖上可以看出，處理消息或者請求的函數邏輯是一致的，只是接收協議不同，所以使用函數計算可以方便維護三個邏輯一樣的函數，但是分別具有不同的觸發器，這樣只需要維護一套代碼即可實現多種接收協議的場景。
說到函數計算的觸發器，就不得不說Serverless架構的另一個優勢，就是生態集成：
函數計算上游對接了近百種觸發器，所以如果採用了函數計算架構，那相當於已經具備了和阿里雲近百種產品的集成與被集成能力，極大的提升了效率和降低了集成成本。
所以暢捷通將API開放平臺轉型爲Serverless架構，也是收穫滿滿：
- 通過函數計算觸發器解決了多種接收協議下維護多套代碼的問題。
- 極大的提升了資源利用率，有效優化了資源成本。在這個場景下，處理消息的函數使用Go語言，使用0.1c和0.05c規格的函數實例，並且採用單實例多併發。在有幾萬消息的峯值情況下，只需要十幾個函數實例就可以穩定支撐，相比原有的K8s架構，成本從幾千元每月節省到了幾百元每月。
智能補貨業務
隨着試點Serverless架構的項目越來越多，同時也獲得了巨大的收益，暢捷通開始逐漸將Serverless架構實踐的眼光看向了核心業務。也許這就是命運的安排，正好暢捷通有一塊新業務開始規劃設計，函數計算被考慮了進去，這就是智能補貨業務。該業務是根據企業的業務數據，按商品的庫存、採購、銷售或材料消耗規律，幫助採購員創立補貨模型，從而快捷地幫助採購員計算、生成補貨參考結果的智能化助手。
該業務由於業務數據量大，採用了離線+實時數據同步計算，需要參與補貨計算的檔案、業務數據同步到數據倉庫中，並對數據根據業務需求定義進行預加工處理，整體有以下這些性質：
- 具有突發流量特性，由於計算的數據量比較大，用戶可以選擇近半年甚至一年的業務數據進行計算分析，是個密集型計算，所以對計算資源的要求較高，如果傳統部署架構頂着業務流量峯值儲備的話，勢必又有成本浪費的問題。
- 智能補貨業務它不是一個新的產品，而是已有產品中的一個新的業務模塊，受限於微服務的拆分粒度，這部分邏輯會和已有的業務邏輯耦合度很高，所以如果運算補貨算法邏輯時消耗大量資源，有可能存在搶佔資源問題，影響到已有業務的穩定性。
- 智能補貨，除了主打智能以外，也支持用戶自定義補貨規則，所以在一定程度上每個用戶的補貨規則就像一個一個業務流程，那整個系統需要具備調度和編排這種業務流程的能力。
所以總結下來，智能補貨業務有三個特點：
- 有流量潮汐特性，希望計算資源有較強的擴展能力。
- 希望計算資源獨立，不搶佔支持現有業務的資源。
- 希望有一套架構支撐規則的靈活調度和編排。
這裏又出現了函數計算的一個核心特點，那就是具備Serverless工作流的編排能力，我們先看架構圖：
可以看到，補貨算法邏輯層全部放在了函數計算中，和部署在ACK中的上下游業務互通，通過函數計算快速彈性能力解決流量潮汐下資源利用和成本問題，同時將這部分耗資源的邏輯剝離出來，也解決了資源搶佔的問題。
對於補貨規則靈活制定這部分，結合了Serverless工作流，每一個規則就是一個流程，流程中的每一個函數就是規則中的一個個算子，Serverless工作流不止支持對函數計算的編排，也支持其他數學邏輯運算和其他阿里雲的核心產品，比如ECS、SAE、ACK、OSS等，同時在版本管理和發佈管理方面也是比較成熟。所以通過這一套架構增強業務功能的可擴展性。
雖然該業務對時延不敏感，但我們也盡最大可能對Java函數的冷啓動問題進行了優化，比如使用鏡像加速能力，JDK使用阿里雲優化過的Dragonwell，開啓預留實例+閒置計費等，從而達到該業務對時延的要求。另外對於Snapshot這些更深一層的技術優化我們也已經開始了調研和排期，盡最大努力徹底解決Java函數的冷啓動問題。
更多業務場景
到目前爲止，除了上文中提到的四個場景外，暢捷通還有其他使用Serverless架構實踐的場景，都取得了預期的受益，比如RPA業務，零售數據全租戶離線下載，離線數據處理等。覆蓋了運維領域，核心業務領域，大數據領域，相信未來還會有更多的場景會轉型爲Serverless架構。
給同行者的建議
Serverless 從根本上降低了用雲的門檻和成本，Serverless 在業界的發展歷程也已經超過 8 年，從落地效果看，阿里雲函數計算是比較適合SaaS系統企業的。同時函數計算目前也在做 AIGC 場景，致力於幫用戶以更低的門檻接入大模型服務。去年開始，阿里雲在大力推廣 Serverless 產品服務，升級到了戰略地位，包括提出 All in Serverless，目前雲消息隊列 MQ 計劃在雲棲大會後推出 Serverless 版、數據庫 RDS 已經推出了 Serverless 版本、大數據團隊也在推進 Serverless 化，從用戶視角，我認爲這是非常利好的。通過全面的 Serverless 產品和服務，可以構建端到端的 Serverless 架構或者應用，這帶來的改變是顛覆性的。與其觀望，不如提前擁抱，期望暢捷通關於 Serverless 的實踐經驗能給更多企業帶來一些啓發。
作者｜計緣 阿里云云原生架構師
本文爲阿里雲原創內容，未經允許不得轉載。