芳林新叶催陈叶,流水前波让后波。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 数字价值年会上隆重颁奖、深度交流。 目前场景正在征集中,更精准的解读、更广泛的曝光、更强大的品牌势能,欢迎你提出问题,更欢迎你留下解决的方法和工具。点击这里投递更多场景信息