芳林新叶催陈叶，流水前波让后波。IT行业从来不缺少新故事，每一次新技术的诞生总是让人振奋，它象征着更高的生产力、更大的想象空间，将旧技术和旧故事冲刷在历史的转角。
但，有一种故事独让人分外关注——新与旧的碰撞与融合。比起单纯的新技术革命，那些在上个技术周期已经获得成功的企业，如何接纳和善用新技术，是更为有趣的研究范本。
成立于2010年的畅捷通，是中国领先的小微企业财税及业务云服务提供商，并且于2014年在香港联合交易所有限公司主板挂牌上市(1588.HK)。
与大多数公司不同的是，畅捷通此前是用友集团的一个业务板块，其产品和技术架构延续了用友于1998年推出的产品——用友U8，而畅捷通之后的发展定位于服务小微企业的SaaS，从而走上了一条生长在云上的技术进化之路。
从传统IT到Serverless
每个时代都有每个时代的主流技术，2012年之前，早期的用友U8基于Windows，打造了单体架构的软件包，当虚拟化出现并开始发展，一些开源的虚拟化技术平台也随之诞生，畅捷通做了技术选型，希望探索云技术架构。2013年-2017年，畅捷通基于开源云平台建设了自己的云服务平台，再面向客户提供服务，此时基础设施部分还是由畅捷通自行提供。本次技术升级带来了一些技术红利，但也为畅捷通埋下了技术债，典型如单租户的SaaS架构，每个实例都需要独立的资源，导致资源浪费。
“畅捷通是一家专业的软件公司，不是专业做资源的公司，在基础设施和资源利用率等方面，旧的平台给我们带来一些比较大的困扰，这也启示我们，专业的事情还是要让专业的人做。”畅捷通总架构师郑芸回忆道。
2017年之后，畅捷通着手进行系统级重构，部署微服务架构，首要前提就是将所有业务搬迁到云上，彼时的畅捷通内部还存在一部分软件包产品，但是畅捷通决定朝着全面云原生化的方向进发。
这也是畅捷通和阿里云深度合作的开端，基于阿里云IaaS资源、中间件等PaaS服务，畅捷通将自己的产品重做了一遍。
“一开始考虑的是微服务架构，因为To B业务比较复杂，我们先按照各个业务模块的耦合关系拆分微服务，同时数据库采用了多租户模式，充分共享了一些资源，但这个时期为了业务的稳定性，畅捷通还是采用了阿里云ECS云服务器，并没有更激进地直接上Serverless。”郑芸表示。
2020年之后，畅捷通多年来积累的用户规模，以及愈发复杂的业务，已经让畅捷通的技术架构变成一只“缓行的大象”，郑芸想让这只“大象”再次轻盈地跳舞，即使业务再复杂，也能够敏捷迭代，业务层面快速响应市场，同时在迭代过程中，进一步加强稳定性。
在统一规划指引下，畅捷通进行了全面容器化的改造，将之前的ECS部署架构改为K8s部署架构，并且选择了阿里云ACK。到目前，有十几个ACK集群在稳定支撑畅捷通的核心业务。
与此同时，畅捷通也有一些业务开始慢慢Serverless化，从底层架构实现、适用的业务场景、对现有业务的改造成本等几个方面来综合分析，最终确定使用函数计算FC作为试点，开始Serverless的探索之路。
从边缘运维业务，到核心关键场景
To B类型的业务虽然在请求量和流量方面远不如To C业务的系统，但是对于稳定性和安全性的要求远远高于面向To C的业务。
此外，因为涉及的业务领域更深，产品考虑的业务场景更为复杂多样，且模块和模块之间存在高度协同的业务流转，像多租户管理、租户数据隔离、网络隔离、系统扩展性(aPaaS能力)、BI(数据展示分析)等都是畅捷通要解决的难题。
和大多数企业相似，畅捷通在Serverless方面的实践也是从非核心业务走向核心业务，从轻量改造到产品重构。
畅捷通第一个选择Serverless的场景是运维，畅捷通有多个产品线，且技术架构不尽相同，有一部分老业务直接迁移上云，并没有彻头彻尾的改造，在该产品发布新版本时，必要的一个环节是批量跑SQL脚本，要么更新元数据，要么更新表结构。
该产品采用了多租户架构，数据库中包含数百个实例，每个实例又包含上百个租户，相当于上万个租户，每次批量跑SQL脚本的效率与用户规模和迭代脚本等有关，大概需要1-2个小时，也就意味着必须等脚本跑完之后才能验证上线的成功性，畅捷通一直想把这部分时间尽可能缩短。
如果不考虑成本的情况下，可以通过增加计算资源并行的方式来提高效率，但是发版是低频操作，不可能长期持有计算资源，用完之后还得及时释放，按目前云资源的使用情况，基本上需要按天计费，费时费力，性价比并不划算。
畅捷通和阿里云合作，对这个试点项目进行改造，改造过程相对比较简单，风险也比较可控，基于Serverless按需所取、按量计费的特点，将执行SQL脚本的任务放在了函数计算中，做到了在发版要执行SQL脚本的时候，按需通过运维管理平台请求函数计算，通过自动拉起所需计算资源来处理SQL脚本，脚本执行完后自动释放，相当于有一个随用随取的资源池供客户使用。
畅捷通由此尝到了Serverless的第一口甜头，也增强了业务对新技术的信心，后续在考虑低频、高并发业务的时候，畅捷通优先选择Serverless。例如将整个运维管理平台中合适的场景都替换为函数计算。
因为运维管理平台相比业务系统，对资源的需求也是较为低频，其中的一些任务执行可能一天就几次，甚至一个月几次，所以本质上都是将各种运维任务脚本放在函数计算中运行。
除了享受到了函数计算资源按需所取、大并发执行、后处理容错机制等红利外，在快速修复脚本异常的场景下，函数计算也具有先天优势。
此外，畅捷通将API开放平台中接收/处理三方消息的架构转型为Serverless架构，通过函数计算触发器解决了多种接收协议下维护多套代码的问题，极大的提升了资源利用率，有效优化了资源成本。
在这个场景下，处理消息的函数使用Go语言，使用0.1c和0.05c规格的函数实例，并且采用单实例多并发。在有几万消息的峰值情况下，只需要十几个函数实例就可以稳定支撑，相比原有的K8s架构，成本从几千元每月节省到了几百元每月。
当越来越多的业务实现了Serverless化，畅捷通也将目光转向核心业务场景。智能补货是根据企业的业务数据，按商品的库存、采购、销售或材料消耗规律，帮助采购员创立补货模型，从而快捷地帮助采购员计算、生成补货参考结果的智能化助手。
该业务由于业务数据量大，采用了离线+实时数据同步计算，需要参与补货计算的档案、业务数据同步到数据仓库中，是个密集型计算业务，同时和已有业务耦合，可能存在资源抢占问题，进而影响到核心业务的稳定性。
畅捷通的智能补货也支持用户自定义补货规则，某种程度上，每个用户的补货规则就像个性化业务流程，整个系统需要具备调度和编排业务流程的能力。
Serverless的弹性计算和工作流的编排能力，精准命中了畅捷通的需求。阿里云将补货算法逻辑层全部放在了函数计算中，与部署在阿里云容器服务ACK中的上下游业务互通，通过函数计算FC快速弹性能力解决流量潮汐下资源利用和成本问题，同时将这部分耗资源的逻辑剥离出来，也解决了资源抢占的问题。
对于补货规则灵活制定这部分，结合了云工作流CloudFlow，每一个规则就是一个流程，流程中的每一个函数就是规则中的一个个算子，Serverless工作流不止支持对函数计算的编排，也支持其他数学逻辑运算和其他阿里云的核心产品，比如ECS、SAE、ACK、OSS等，同时在版本管理和发布管理方面也是比较成熟。所以通过这一套架构增强业务功能的可扩展性。
在此过程中，由于Java函数本身的局限性，会造成冷启动问题，阿里云通过使用镜像加速能力，JDK使用阿里云优化过的Dragonwell，开启预留实例+闲置计费等，从而达到该业务对时延的要求。
朴素的技术逻辑
“做技术的人都知道，开发人员肯定希望更多使用新技术。但是产品人员更多希望使用成熟技术，稳定性至关重要。”郑芸说，“我们不是为了新而新，业务确实需要用Serverless，那就坚定不移地做，更多还是从业务诉求考虑。”
阿里云云原生架构师付宇轩也谈到，无论是研发效率还是运维效率，所有技术架构最根本的特点，就是降本和提效。Serverless的弹性和无需运维的两者特性结合，能够给客户带来朴素的技术和业务价值。
畅捷通一直遵循着这一逻辑，早在2018年，内部研发人员就在一些小工具上使用了Serverless，随着Serverless技术逐渐成熟，行业认知也趋于一致，畅捷通顺理成章地全面拥抱了Serverless。
而对于畅捷通的客户来说，Serverless技术的价值也通过畅捷通传递到客户侧。以财务软件每个季度的大税期和小税期为例，报税期间的并发量远远高于平时的业务量，传统的解决方案是，客户点击一键报税提交任务，就可以到服务端排队等待，等到后端资源按顺序处理。当采用了Serverless技术架构之后，尽管在大税期业务吞吐量环比增幅50%以上，但只要客户准确提交，仍能保持平时效率在分钟内完成报税。
谈及未来对于Serverless的构想，郑芸表示，Serverless已经为畅捷通业务带来了显著提升，更进一步，Serverless的函数编程可以帮助畅捷通实现可组装的SaaS应用，以满足标准SaaS产品不能满足的个性化需求，如此，Serverless将大幅提高畅捷通产品的可扩展性以及生态集成能力，未来畅捷通将把更多业务场景向Serverless迁移。
本文摘自《云栖战略参考》总第16期扫码限时申领纸质版↓↓
「关于创新场景50」 场景不是案例，它更加精准、也更加抽象。数字化就是创新场景的不断叠加和迭代。 在此背景下，钛媒体重磅推出「创新场景50」评选，每年遴选并解读50个全行业与业务深度融合的创新性场景及其解决方案，并在钛媒体年度ITValue Summit 数字价值年会上隆重颁奖、深度交流。 目前场景正在征集中，更精准的解读、更广泛的曝光、更强大的品牌势能，欢迎你提出问题，更欢迎你留下解决的方法和工具。点击这里投递更多场景信息