2024CTIS-文章详情页顶部

畅捷通Serverless改造:极简运维提升资源利用率、扩展性以及生态集成能力 | 创新场景

深度
无论是研发效率还是运营效率,所有的技术架构最根本的特点,就是降本和提效,Serverless的弹性和无需运维,两者结合能够给客户带来朴素的技术和业务价值。

本文摘自《云栖战略参考》,这本刊物由阿里云与钛媒体联合策划。目的是为了把各个行业先行者的技术探索、业务实践呈现出来,与思考同样问题的“数字先行者”共同探讨、碰撞,希望这些内容能让你有所启发。

芳林新叶催陈叶,流水前波让后波。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 数字价值年会上隆重颁奖、深度交流。

目前场景正在征集中,更精准的解读、更广泛的曝光、更强大的品牌势能,欢迎你提出问题,更欢迎你留下解决的方法和工具。点击这里投递更多场景信息

转载请注明出处、作者和本文链接
声明:文章内容仅供参考、交流、学习、不构成投资建议。
想和千万钛媒体用户分享你的新奇观点和发现,点击这里投稿 。创业或融资寻求报道,点击这里

敬原创,有钛度,得赞赏

赞赏支持
发表评论
0 / 300

根据《网络安全法》实名制要求,请绑定手机号后发表评论

登录后输入评论内容
  • 如ECS、SAE(Serverless应用引擎)、ACK(容器服务)、OSS 【朴素的技术逻辑】 开发人员希望使用新技术。产品人员更希望使用成熟技术,稳定性至关重要。S已经为畅带来了显著提升,更进一步,S函数变成可以帮畅实现可组装的SAAS 【继续思考】这样读资讯,太耗费时间了,怎么解?

    回复 4月30日 · via pc
  • 保证敏捷迭代、业务层面快速响应市场,同时在迭代中加强稳定性,畅开始了全面容器化改造:部署架构由ECS改为K8s,选用了十几个阿里云ACK(容器化服务)集群来支撑畅的核心业务稳定运行。同时,使用函数计算FC作为试点,开始探索Serverless. 【从边缘运维业务,到核心关键场景】 从运维业务场景开始,享受到了FC按需所取、大并发执行、后处理容错机制等红利外,FC也可快速修复脚本异常场景。 核心业务场景,S的弹性计算和工作流的编排能力,精准命中了畅捷通的需求。S工作流(即CloudFlow),不仅持续对函数计算的编排,也支持其他数学逻辑运算和核心产品,如ECS、SAE(Serverless应用

    回复 4月30日 · via pc
  • 【从传统IT到Serverless】 2012年之前,畅捷通做了技术选型,希望探索云技术架构。 2013-17年,基于开源云平台建设了自己的CP(云平台),吃到了技术红利,但也欠下了因技术(自行提供技术)导致的债:单租户SAAS架构,各实例需独立资源,但资源利用不可能经常满负荷,所以导致资源浪费。 2017年,畅部署微服务架构,全面上云,且朝着全面云原生化的方向走。基于阿里云IAAS资源和PAAS服务,将自己的产品重新做了一遍。为了不影响业务稳定性,没有直接上Serverless,而是采用了ECS服务。 2020年之后,畅多年积累的用户规模逐渐增大、业务复杂度也逐步提升。为了保证敏捷迭代

    回复 4月30日 · via pc
3

扫描下载App