作者 | 中国工商银行金融科技研究院云计算实验室
工商银行早在 2018 年便启动了 Serverless 技术的研究，通过将业界主流 Serverless 技术栈与行内“云计算 + 分布式”体系融合，建设了具备极致弹性伸缩能力的全托管 Serverless 平台，并在 AI 模型、批量任务、接口聚合等多个场景落地，有效提升了云上资源利用率和业务迭代效率。我们在这篇文章里分享了工商银行 Serverless 实践至今的经过、效果和经验，希望对大家有所帮助。
1 Serverless 的发展历程和业界现状
Serverless 作为虚拟机技术、容器技术之后的下一代云计算形态，被认为是云计算未来的发展方向。纵观云计算的发展历程，经历了从物理机到虚拟机，从 IaaS、PaaS 到 Serverless（如图 1 所示），每个阶段的跃迁都是一个去服务器的过程，同时带来了技术架构和应用架构的不断演进。在 Serverless 阶段，应用被拆分成多个独立功能点，每个功能点对应一个函数，每个函数实现各自的业务逻辑。同时 Serverless 将后端能力封装成服务，并以接口的形式提供给上层业务调用，确保用户最大程度聚焦业务逻辑开发，而无需关注高可用、服务器运维等其他要素，极大提升了业务的上线速度。
图 1 Serverless 发展历程
Serverless 经过这些年的快速发展，在技术架构、平台能力、平台特性、应用场景和业界产品等方面也逐渐趋向成熟。
- 技术架构方面：Serverless 依托于底层 IaaS、PaaS 平台，以事件驱动为核心，通过 HTTP、定时、消息等事件触发的方式，调度执行上层业务逻辑。
- 平台能力方面：Serverless 为开发、测试、发布、交付、灰度等应用生产环节提供了完备的支撑，实现了完整的 DevOps 能力，并通过完善的日志、监控体系，提升了运维工作的效率。
- 平台特性方面：Serverless 的弹性扩缩容能力，满足了后端服务急速扩缩容需求，解决了业务流量波谷时期带来的资源浪费问题。同时，Serverless 函数计算具备的函数编排能力，满足了多媒体计算领域在对音视频进行采样、降噪、平衡音量、转码等处理时的计算编排要求。
- 应用场景方面：Serverless 可应用后端业务处理、文件转换、音视频处理、AI 模型训练和运行等场景，并且通过按需使用，降低业务上云的成本，同步提升研发效能。例如，AI 计算是一种 CPU 密集型且有明显波峰和波谷的业务，同时 AI 开发过程中需要对参数频繁调整并验证调整结果，Serverless 的弹性伸缩和快速发布能力可以很好的应对此类具有峰谷特性的业务，同时满足了模型快速上线的需求。新浪微博、高德地图、闲鱼等互联网企业也通过 Serverless 的弹性伸缩能力，在音视频处理和后端服务上大幅降低了计算资源成本，同时得益于 Serverless 便捷的研发部署流程和强大的运维管理支撑，研发效能实现大幅提升。
- 业界产品方面：当前亚马逊、阿里、腾讯等头部厂商提供了完善的 Serverless 平台服务。国内外主要的公有云 Serverless 产品有 AWS Lambda（亚马逊）、Azure Functions（微软）、函数计算（阿里云）等。金融行业考虑到安全性和多样的金融业务需求，一般使用私有化的 Serverless 方案，搭建适用于银行业务特性的 Serverless 平台。
2 工商银行 Serverless 体系技术支撑
工商银行作为国内银行业首家落地 Serverless 平台的企业，早在 2018 年便启动了 Serverless 1.0 的设计。技术架构上，以“开源框架 + 自研事件驱动框架”为核心，提供了函数模式和 Serverless 容器模式（如图 2 所示）。
图 2 工商银行 Serverless1.0 技术架构
Serverless 1.0 平台实现了动态伸缩过程中应用实例数 0 到 N 的能力，在量化交易业务模型回测场景中，为了对历史市场数据、指标数据、交易明细等数据进行查询分析，通过将基金组合效果统计模型的逻辑封装成函数，运行在 Serverless 平台中，提升了分析模型的开发人效和计算资源的利用率。
随着一些对业务响应要求较高的应用开始接入，Serverless 1.0 平台逐渐出现一些问题，比如每次发布都需要制作新的镜像、运维流程繁琐等等，这对行内生态闭环程度、平台易用性上提出了更高的要求。
2020 年，工商银行在原有 Serverless 平台上增强了与存储、日志、监控等周边生态的融合，并进一步强化“函数即服务”的能力，设计和建设了 Serverless 2.0 平台。2.0 平台在技术选型上以工商银行 PaaS 平台为基础，并与工商银行云计算、分布式体系充分融合，为应用提供了完整的函数核心引擎、函数管理、开发交付等能力。
基于平台的使用场景和技术选型，Serverless 2.0 函数计算平台在架构上分为函数计算管理平台和函数计算系统服务两大部分（如图 3 所示）。
- 函数计算管理平台：主要向开发、运维人员提供完备的管理能力，包括函数管理、服务管理、事件管理、工作流管理、发布管理和日志监控等功能，覆盖函数的开发测试、运维监控全流程。
- 函数计算系统服务：主要提供了函数开发运行所需的各个底层支撑能力，包括事件触发器、Runtime 执行环境、平台底层支撑三个层面。在事件触发器层面，平台已支持 HTTP、定时任务、Kafka、对象存储等事件源；在执行环境层面，平台已支持最主流的 Java、Python、Nodejs 三大运行时，同时也支持自定义运行时配置，以覆盖更多应用场景；在平台底层支撑层面，平台提供了函数执行、监控运维、资源管控、稳定性保障等能力，有效降低接入应用的运维成本。
图 3 工商银行 Serverless2.0 平台架构
3 工商银行 Serverless 应用实践及成效
经过近几年的实践，工商银行 Serverless 平台目前已将应用场景总结为分布式批量、小程序应用、AI 模型、音视频处理、流式消息处理等近 10 类，并已在黄金账户、智能外呼、资产估值、持续交付系统等数十个应用全面开展落地工作，接入 Serverless 平台的应用总体资源利用率提升了 90% 以上，研发人力投入降至未接入前的 70%，应用降本增效成果显著。同时，借助平台提供的统一运维能力，应用极大地降低了运维工作量，从而进一步提升了我行云原生基础设施对上层业务的支撑水平。
（一）Serverless 在分布式批量场景的实践及成效
在传统的分布式批量架构中，批量作业整体调度能力由批量控制器、分布式协调中心（zookeeper/kafka）、批量作业执行器构成。其中批量控制器用于作业的调度和触发，作业触发消息通过分布式协调中心进行发布，批量执行器在监听到作业触发消息后，启动批量作业并同步更新批量作业状态（如图 4 所示）。传统分布式批量架构由于批量作业执行器需要实时监听分布式协调中心中的作业触发消息，因此在非批量作业执行期间，批量作业执行器也需处于运行状态，导致资源利用率较低。
图 4 传统分布式批量作业架构
为提升批量作业执行器的资源利用率，工商银行围绕高可用、灵活性、兼容性三方面，基于原有分布式批量平台，增加了 Serverless 批量任务管理能力，将分布式批量框架的调度能力和 Serverless 平台快速弹性伸缩能力相结合，通过整合批量框架和 Serverless 平台的技术优势，大幅提升了批量作业资源利用率和调度灵活性。
- 批量作业高可用方面：分布式协调中心和 Serverless 批量任务管理模块均采用多实例运行机制，当主节点发生故障时，从节点可以在第一时间接替主节点任务，防止单点故障引起的系统不可用。此外在作业运行期间，函数计算平台也能够根据函数运行的返回消息快速捕获异常作业，然后报告给 Serverless 批量任务管理模块，通知批量控制器对该作业进行重试。
- 批量作业灵活性方面：基于 Serverless 平台弹性伸缩能力和事件驱动特性，在高并发场景下，可动态创建和销毁函数容器，实现资源的灵活分配，进而提升分布式批量作业调度的灵活性。
- 批量作业开发兼容性保障方面：通过引入 Serverless 批量任务管理模块，将分布式批量框架和函数计算平台解耦，实现了平台兼容。同时，通过升级分布式批量开发框架 SDK 的方式，保证了基于传统分布式批量架构开发的存量应用可以平滑过渡到基于 Serverless 函数计算的批量架构，确保了 Serverless 平台和分布式批量框架的兼容性。
目前批量作业函数化已在贵金属积存金业务、小程序开放平台、资产管理估值核算、分布式事务等应用落地试点，峰值资源占用可减少 50%，总体资源利用率提升 90% 以上，达到了较好的试点效果。未来预计生产超过 90% 的分布式批量场景可适用该方案，将大幅提升工商银行分布式批量场景的资源利用率。
（二）Serverless 在持续交付流水线的实践及成效
持续交付系统在安装上云数据库时，一般选择在代理服务器上运行数据库安装程序，但代理服务器存在多应用、多节点共用时资源无法隔离、与数据库关系映射无序等问题。此外，代理服务器只在应用投产时运行，其余时间服务器资源处于闲置浪费状态。
通过 Serverless 平台的弹性扩缩容特性可做到按需加载，实现只在执行数据库安装程序时动态拉起对应的函数计算实例，任务运行结束后即可销毁的能力，从而避免了空耗计算资源的情况。同时 Serverless 平台支持自动弹性扩容，可为任务执行提供足够的计算资源，以应对投产时间窗口内大量的数据库安装部署任务。使用方只需利用函数计算事件触发机制，通过请求参数实现各数据库安装函数实例只作用于目标数据库，无需维护相关映射关系。
在运维方面，基于 Serverless 平台的持续交付作业无需进行日志和可用性监控的配置，可方便地使用 Serverless 平台提供的定时、kafka 等事件源触发机制进行作业调度，大幅提升了运行效率。目前，Serverless 平台已为持续交付系统的一千多个数据库实例提供了数据库安装服务，累计节省生产环境数据库服务器一千多台。
（三）Serverless 在智能外呼场景的实践及成效
智能交户应用服务提供了智能外呼、智能呼入、智能质检等多维度的智能交户能力。在外呼场景中，系统需要将收到的外发信息文件进行预处理，包含文件解析、数据校验、任务拆分、特殊场景处理等，并将处理后的数据进行标准化的存储，等待后续外呼处理。为了满足应用的外呼需求，外呼数据的预处理功能部署在同一个容器中，需要 7*24 小时在线，但每日实际运行时间只有数小时，甚至只有几十分钟，存在大量的服务器资源浪费问题。
为了应对上述痛点，通过函数计算平台开发部署，应用只需编写外呼数据的预处理功能，由 Serverless 平台承接预处理功能的发布、触发运行、监控告警等能力，在空闲期不再占用服务器资源。
相较于原开发运维方式，函数计算开发功能人力投入整体合计节约 25% 左右，生产环境服务实际占用的资源节约了 90% 以上。
（四）Serverless 在文本核对场景的实践及成效
工商银行对账中心在对文本数据进行核对时，底层数据库进行分库之后需要多个节点支撑，由于文本的核对任务不需要长期执行，因此导致了大量空闲时间段的资源冗余问题。
对账中心通过抽取文本核对过程中共性的数据获取、数据加工、数据持久化和数据回传等关键步骤为函数，利用函数工作流机制对函数进行编排。核对任务通过工作流进行编排，由函数平台触发，其运行所需的容器资源管理和运维监控保障均通过函数计算平台实现，达到了系统高性能、高扩展和资源高利用率的效果，也降低了运维复杂度。此外 Serverless 平台提供的灰度发布、日志管理和监控能力，也丰富了对账中心的运维能力（如图 5 所示）。
图 5 对账中心基于 Serverless 的文本核对系统架构
4 Serverless 在金融行业落地建议
目前银行线上业务正处于高速发展时期，同时又面临着服务器资源和研发效能两方面的压力，针对创新类业务还面临着较高的试错成本。工商银行认为银行业在引入 Serverless 技术需要重点关注以下内容。
一、深入研究业务特性，全面评估应用收益。通过分析应用的负载情况，对具有负载峰谷现象的应用或变更频繁、需快速试错的业务，进行函数化改造的可行性分析，适当规划函数服务粒度，并重点关注服务改造成本、投产风险和预期收益。
二、加强运维能力建设，着力保障研发体验。完善 Serverless 平台稳定性，通过与开源或现有的日志、监控、告警组件结合，融入现有运维生态体系，构建完善的研发体系，辅助开发人员高效完成函数的开发和测试，并结合完善的 DevOps 能力，提供 Serverless 项目一体化研发、发布流程。
三、充分利用平台优势，逐步丰富落地场景。建议金融同业充分利用 Serverless 的特性，结合应用的负载规律、业务的响应效率、运维的人力成本等多方面因素，充分挖掘潜在场景，使用 Serverless 技术实现降本增效。
当前工商银行已经建设了功能完备的企业级 Serverless 平台，未来也将持续打磨 Serverless 产品的核心能力，打造适配金融业务特性的 Serverless 平台，不断丰富落地场景，扩大函数计算的使用范围，将 Serverless 技术大规模运用到工商银行金融业务中，为金融同业的架构转型提供最佳实践和参考样板。
延伸阅读：
从公有云方案转向谷歌开源Knative，网易云音乐的Severless演进实践
备受云厂商们推崇的 Serverless，现在究竟发展到什么水平了？
今日好文推荐
杀死Python？ChatGPT插件系统正式开放，不用写代码，人人都是程序员
集成GPT-4的编程神器来了，GitHub发布Copilot X：编程30年，突然就不需要手敲代码了？！
八年“老网红”Flink：揭秘实时流计算引擎全球化落地的演进历程
我在GitHub 黑市买“水军”：一万颗star只要4000多元，人人都能“一夜爆火”
