畅捷通的 Serverless 探索实践之路（畅捷通技术）

作者：计缘，阿里云云原生架构师

畅捷通介绍

Cloud Native

畅捷通是中国领先的小微企业财税及业务云服务提供商，成立于 2010 年。畅捷通在 2021 年中国小微企业云财税市场份额排名第一，在产品前瞻性及行业全覆盖方面领跑市场，位居中国小微企业云财税厂商矩阵领军象限前列。作为专注小微企业云服务、软件提供商，畅捷通于 2017 年在业内创新提出“智公司”的概念，于 2018 年进一步丰富提出了“智能商业范式六步法”，旨在帮助小微企业明确、精准的走向智能化。畅捷通针对小微企业财务及管理转型问题，通过技术赋能，帮助小微企业实现人员在线、业务在线、客户在线、管理在线，改变传统的经营业态，推动数智化升级转型。

市场数据来源于艾瑞咨询发布的《2022 年中国小微企业云财税行业研究报告》

在数字经济快速发展的战略机遇下，小微企业积极谋求业务转型，利用数智化手段增收、降本、提效的需求将进一步增强。畅捷通以数智财税，数智商业为核心，以生态服务为延展，提供小微企业云服务，推出了一系列 SaaS 产品，包括好会计（智能云财税）、好生意（营销型云进销存）、T Cloud（全场景数智商业云应用）、好业财（创新企业数智经营平台）、易代账（数智财税平台）等，畅捷通云平台累计注册用户数超过 800 万。

业务及技术背景

Cloud Native

畅捷通有 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

Cloud Native

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 架构如何向 Serverless 架构转型，实现降本增效，提高资源利用率。Serverless 技术理念是指 Zero Server Ops No Compute Cost When Idle，核心思想是让企业聚焦业务，降低 Ops。因此按照 Serverless 的理念，运维工作会被极大简化，研发人员一定程度上可以操控资源的使用，进而提升业务迭代效率。所以这个理念非常契合畅捷通研发、运维团队的发展思路。

Serverless 技术调研

Cloud Native

畅捷通是一家积极拥抱云的企业，对一切新的技术领域都有着求知欲，畅捷通总架构师郑芸女士多次组织核心研发运维同学和我们深入了解 Serverless 技术领域，从底层架构实现、适用的业务场景、对现有业务的改造成本等几个方面来综合分析，最终确定使用函数计算 FC 作为试点，开始 Serverless 的探索之路。

函数计算业务场景

针对 SaaS 系统，函数计算最适合的场景应该是 HTTP、Web 应用场景，大数据 ETL 场景和周期性任务场景，而畅捷通之后落地的项目基本都属于这三类场景。

非 Serverless 架构如何向 Serverless 架构转型

选定好场景后，就需要解决如何转型的问题，这里的转型有个维度的概念：

• 现存非 Serverless 架构业务向 Serverless 架构转型：会涉及到较大成本的改造问题
• 新业务直接采用 Serverless 架构：遵循 Serverless 架构最佳实践范式即可

畅捷通这两部分都有涉及到，根据函数计算的概念，我们也总结了转型最佳实践，包括编程语言的选择、运行环境的选择、DevOps 改造流程、代码改造流程等，一起和畅捷通逐一进行验证。

Serverless 实践

试金石-SQL 脚本执行任务

Cloud Native

畅捷通的 Serverless 实践是渐进迭代的路线，在技术调研后，第一个试点项目是运维中的 SQL 脚本执行任务，因为面向 To B 客户的 SaaS 系统，出于稳定性的考虑，发版的节奏一般都不会特别的频繁，但每次发版的工作量是非常大的，尤其在发布大版本时，其中有一项重中之重的任务就是批量跑 SQL 脚本，要么更新元数据，要么更新表结构。主要在 T Cloud 这个系统中试点，这个试点项目改造起来相对比较简单，风险也比较可控，属于客户小试牛刀。

原有方式的痛点

批量跑 SQL 脚本任务是需要计算资源的，但这些计算资源的使用率极低，所以不可能长期储备着计算资源，但如果要从支撑业务的资源中分配的话，那可能又会对业务产生影响。另外每次跑批时需要在计算量也不算小，所以每次就得靠运维人员手动加减服务器，费时费力，有时候因为资源不能及时准备好，从而影响发版进度，有时候忘记释放资源，又会产生额外的费用。所以核心的痛点就是提高效率、提升运维幸福度。

Serverless 架构

基于 Serverless 按需所取，按量计费的特点，将执行 SQL 脚本的任务放在了函数计算中，做到了在发版要执行 SQL 脚本的时候，按需通过运维管理平台请求函数计算，通过自动拉起所需计算资源来处理 SQL 脚本，脚本执行完后自动释放，相当于有一个随用随取的资源池供客户使用。改造为 Serverless 架构后，主要带来了以下优势：

• 彻底解决了按需所取的计算资源问题，运维人员不需要再花额外时间考虑准备资源的问题。
• 得益于函数计算的弹性速度和并发扩展能力，Serverless 架构下，在保证 SQL 脚本之间顺序性的前提下，并行执行 SQL 脚本的能力大幅提升，有效缩短了发版持续时间。
• 函数计算异步请求有后处理机制，即当函数执行成功或者执行失败后，可以设置目标服务及时做后处理，在这个场景下，可以有效自动化处理执行失败的 SQL 脚本任务，比如执行失败后发送消息，或者执行失败后重试执行，或者再拉起另一个函数做补偿逻辑等等。极大的提升了 SQL 脚本批量执行的稳定性。

Serverless 实践全面开花

Cloud Native

在 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 架构。

同行者的建议

Cloud Native

Serverless 从根本上降低了用云的门槛和成本，Serverless 在业界的发展历程也已经超过 8 年，从落地效果看，阿里云函数计算是比较适合 SaaS 系统企业的。同时函数计算目前也在做 AIGC 场景，致力于帮用户以更低的门槛接入大模型服务。

去年开始，阿里云在大力推广 Serverless 产品服务，升级到了战略地位，包括提出 All in Serverless，目前云消息队列 MQ 计划在云栖大会后推出 Serverless 版、数据库 RDS 已经推出了 Serverless 版本、大数据团队也在推进 Serverless 化，从用户视角，我认为这是非常利好的。

通过全面的 Serverless 产品和服务，可以构建端到端的 Serverless 架构或者应用，这带来的改变是颠覆性的。与其观望，不如提前拥抱，期望畅捷通关于 Serverless 的实践经验能给更多企业带来一些启发。