大象转身：支付宝资金技术 Serverless 提效总结

1. 前言

本文是支付宝资金技术团队在《大象转身-支付宝资金技术交付提效之路》系列总结之一。如果你正在负责一个所支撑的业务面临从平台到场景化创新的发展阶段，希望通过提升交付效率来提升技术团队的竞争力和团队研发幸福感，那么这篇文章也许会让你有收获：

1、Serverless 的技术理念是什么？对业务研发有什么借鉴意义？

2、如何基于 Serverless 驱动研发模式的升级，设计一个能让场景化创新快起来的技术架构，提升全局研发效率？

本篇作者：呆莫（代巍）、歆明（何鑫铭）

文章较长，建议收藏和保存

为什么写这篇文章

我们做了近两年的 Serverless 研发模式的探索和落地，目前该模式已经承接了大部分资金业务的场景，平台也已经进入推广期，有 20+ 团队经过 SOFAServerless 技术团队的介绍找到我们。未接入 SOFAServerless 的想从业务视角寻求架构选型依据和应用架构设计，已接入 SOFAServerless 的同学来寻找基座治理经验。因此决定写一篇文章，将我们的架构选型、设计和落地经验做一次完整的总结。

2. 我们遇到的问题

我们的问题：随着场景创新增多，SOFA 应用变臃肿、团队研发人数变多导致研发和运维难度升高，阻碍了业务创新的交付效率，系统需要做重构。

简单说说背景

资金在这两年时间，肩负了很多业务创新、寻找业务增量的目标。增量时代的创新是残酷的，成功的明星产品背后，是无数次的失败（这三年间，技术支撑了 15+ 个创新产品的建设，包括小程序、行业解决方案）。而支付团队转型做创新也面临着巨大的挑战：动辄 1-2 个月起的研发交付周期，在当时使得技术团队被按在地上摩擦，各种问题接踵而来。

蚂蚁集团 CTO 苗人凤曾经说过，创新是九死一生，技术就是要帮助业务降低机会成本。

我们逐渐意识到业务创新的快速发展，一定离不开业务快速交付的新型技术研发模式。如果我们还是沿用平台化的架构思路，在一个庞大的资金平台上写一堆创新场景的代码，在完成业务需求的同时还要思考如何抽象、如何保障增量的代码不影响平台稳定性，那一定快不了。

2021 年，我们成立“资金场景创新提效项目”，试图通过平台架构升级、研发模式升级解决场景创新效率问题。

问题定义：资金场景应用变成巨石应用带来一系列问题

试着代入一下案例：
如果有那么 5 个创新业务迭代在同一个应用发布窗口进行推进，会存在各种各样导致延期的原因:
A 业务验证延后 2 天，那么 5 个迭代都要延后 2 天；
B 业务升级了中间件版本，那整个应用的业务都面临回归成本一样要延后整个发布期；
C 业务想要在预发搭个车微调一些代码，但是由于动作慢没能成功验证，导致污染了主干，进而耽误了整体；
……

在应用架构层面，资金部门早期孵化出了一个“大资金场景层应用”——Fundapplication。Fundapplication 在研发协作方面，从一开始的几个同学，到后来几个业务团队、几十个研发同学，都在一个应用系统上研发，通过多个 bundle 区分不同业务，公共的 bundle 沉淀通用能力和研发工具（类似于之前的 mng 系统），如下图：

这种架构设计在遇到大量的彼此没有复用的业务创新需求时，就逐步沦为了巨石应用，如下图：

研发运维效率低：作为入口系统，mgw 接口无法在本地开发自测，改动任何代码必须发布到联调环境。发布一次需要 10 分钟以上，还要忍受环境不稳定因素带来的额外时间花费。
业务迭代抢占，协同成本高：系统作为创新应用系统，有 10+ 个创新产品，30+ 个正式员工和外包员工也在这个系统上做研发迭代，火车式发布迭代痛点明显——一人晚点，全体延期。
研发时隔离效率低：30+ 研发同学（含外包）在一个系统内研发，经过不到一年的时间，我们的系统就变成 10+ 个 bundle、2w+ 个 Java 文件（全站均值 4000）的体量了，因为各种业务的各种依赖的增加，系统启动一次需要 15 分钟。随着创新场景增多会变得更加糟糕，而且很多代码没有办法随着业务的下线而删除。
运行时不隔离：目前我们没有对不同的业务区分不同的机房，业务吃大锅饭，难以做到按产品的资源和稳定性保障。

如果你的应用也存在上述问题，对业务创新的交付效率产生了一定的影响，那可以继续参考第 3、4 章我们的架构选型和关键设计。

3. 应用架构的选型

当前蚂蚁基于 SOFABoot 的应用架构，在规模化创新场景研发的交付效率、分工协作模式上存在局限性。从行业的发展趋势分析，云原生等新技术引领的“集装箱”架构模式，有利于促进规模化的生产效率和分工协作方式。借助蚂蚁 SOFAServerless 的孵化，我们决定作为种子用户，使用 Serverless 中 BaaS+FaaS 的理念，重塑创新场景研发的研发模式。

微服务应用架构的局限性

大应用创新的模式，是在一个应用系统中按照不同 bundle 来隔离创新应用，可复用的代码可能是放到一个公共的 bundle 中。优点当然是复用效率高，运维统一，缺点主要是协作效率、隔离成本和研发效率。大应用变成巨石应用如何解决？这个我们很容易就想到使用分治的思路，将一个大应用拆成多个应用，通过 RPC 来互相调用。

在蚂蚁当前体系下，微服务系统的 0-1 成本、后续运维成本、硬件机器成本仍然会是一个不小的开销，创新试错还是快不起来。且后端业务创新具有巨大的不确定性，如果因为业务没量了变成长尾系统下线的成本也很高；在性能方面，多个系统间通用能力的调用，会使全链路的调用耗时增加，在业务上不可接受。所以有没有一种技术，可以让业务既能够隔离，又能够降低隔离带来的负向影响：运维成本、能力复用效率、性能？

行业技术架构的发展趋势

一部分做架构的同学喜欢用“架构隐喻”来介绍架构的理念。近几年容器化、云原生、Serverless 等新技术层出不穷，作为架构师需要在对新技术保持敏感的同时，能够有一双洞察架构本质的眼睛。

这些底层新技术的出现，本质上是通过抽象定义“集装箱”的方式，规范了构建、部署、运行、运维标准，提升了软件的生产效率。大家可以感受一下这些技术底层理念的相通之处：

Docker 通过定义容器“集装箱”提升传统虚拟机、基础设施软件构建、运维效率；
K8s 进一步抽象万物皆可定义为 CRD（自定义资源）提升“集装箱”的部署、运维效率；
中间件 Mesh 化将“集装箱”理念应用到中间件近端，将中间件近端与业务代码剥离解耦；
BaaS、FaaS 等 Serverless 技术，将“集装箱”理念范围进一步扩大到可复用的“业务领域插件”。

可以这么说，集装箱改变世界航运效率，计算机软件行业的 Docker、K8s 们通过“集装箱”的架构理念改变了基础软件生产效率。而随着 Serverless 的兴起，“集装箱”的架构理念将会自底向上地，重塑对软件交付效率重度依赖的互联网、金融等行业。

我们来看下，集装箱的理念对我们业务研发的启示：

过去，业务研发需要关注独立的业务应用，既需要关注业务代码、中间件代码等代码信息，又需要关注 Java 进程、CPU、内存等运维信息，随着这两年蚂蚁 MOSN 等 Service Mesh 基础设施的出现，将中间件代码做了拆分和代托管运维，解放了业务研发的部分精力，使其不需要再经常性地忍受中间件近端升级带来的迭代变更。

再进一步的，我们开一个脑洞，能否将 SOFA 运行容器的 JVM 托管出去？甚至更进一步的，将一些通用的业务流程能力、日志和框架等能力托管出去呢？这样创新业务研发的关注点，可以从一个独立的 Java 应用，进一步聚焦到 Java 业务功能性代码，而将非功能性的 Java 容器、日志、框架的构建、部署、运行、运维等工作交给非业务研发同学来负责。带着这样的脑洞，我们来了解下 Serverless 的行业概念并分析架构的可能性。

理解 Serverless 的设计理念

Serverless 的行业概念解释

先带大家看一下行业中对于 Serverless 的解释。

第一个层面是站在运维和云计算厂商的视角： 将 Serverless 拆开看，Serverless = Server（服务端）+ less（较少关心），组合起来便是“较少关心服务端”。这里的“服务端”是指对服务运行资源的运维。因此，Serverless 还有另一种解释是服务端免运维，即 NoOps。概念方面 Serverless 是对运维体系的一个极端抽象。 在这种架构中，我们并不看重运行一个函数需要多少 CPU 或 RAM 或任何其他资源，而是更看重运行函数所需的时间，我们也只为这些函数的运行时间付费。

第二个层面是站在应用开发的视角： 在 Serverless 中，“计算资源”这个概念，除了是作为服务器出现之外也作为服务出现。与传统架构的不同之处在于，它可以完全由第三方管理、由事件触发、无状态地（Stateless）暂存（可能只存在于一次调用的过程中）在计算容器内。我们基于这些“服务计算资源”，就可以更容易地搭建出一个应用，比如你可以把账户管理、交易管理、营销管理等服务完全托管给这些第三方“服务计算资源”。

一个 Serverless 化的应用，就是指大量依赖第三方服务（也叫做后端即服务，即“BaaS” ）或暂存容器中运行的自定义代码（函数即服务，即“FaaS” ）的应用程序。这是一种架构思想，类似微服务一样，不过微服务这种思想架构，目前已经有成熟的框架来支撑，比如 Dubbo、Spring Cloud 等。但是 Serverless 架构目前还没有一个框架来支撑，也因此说 Serverless 技术实际上是一组技术的集合和一种站在服务视角上的应用设计理念。

按照 CNCF（Cloud Native Computing Foundation 云原生技术基金会）对 Serverless 的定义，Serverless 架构应该是采用 FaaS（函数即服务）和 BaaS（后端即服务）服务来解决问题的一种设计。

它的整体架构如上图所示，包含两种模式和形态：

BaaS（Backend as a Service）：后端即服务。 具备高可用&弹性，且免运维的后端服务。可以是符合以上特点的对象存储服务、数据库服务、身份验证服务等等。狭义上讲，BaaS 是为 FaaS 提供服务支撑。
FaaS（Function as a Service）：函数即服务。 提供流程化的服务，将客户对流程的扩展采用一定范式的抽象发布成函数实例，外部可通过触发器使用该服务。FaaS 支持动态扩缩容。以 HTTP 请求为例，当请求量很大时，FaaS 函数会自动扩容多实例同时运行；在 HTTP 请求降低时自动缩容；无流量时还可以缩容到 0 实例。

Serverless 的设计理念抽象成应用架构

理解了 Serverless 的行业概念解释，我们带着这个理念再回顾上面出现过的这张图。

借助集装箱的架构思想，Serverless 理念无非是站在云服务视角，将一个应用程序按照集装箱的方式、拆分成不同的“image”，并进行可标准化的 BUILD 构建、SHIP 部署、RUN 运行，以提升规模化生产效率。

如下图所示，可拆分成使用方、服务方，服务方以 BaaS 独立服务、FaaS 独立流程模版的形式将业务代码抽象成“image”（镜像），使用方将简单的业务代码或者基于 FaaS 扩展的函数也打包成“image”，大家将 image 作为基本单元。我们知道 Docker 是有一套容器运行环境来支持 image 镜像的构建、部署和运行的；类似的，Serverless 也需要有这样一套基本容器环境。这套容器环境，需要对镜像的构建、部署和运行做实现。

Java 应用的 Serverless 运行环境实现

2021 年，我们看到蚂蚁内部有 SOFAArk 这样的模块化框架，提供同 JVM 内多个模块分离研发、部署、运行的研发框架。我们经过 POC 技术验证认为，基于 SOFAArk 定义的 Ark 模块、基座概念和 SOFAArk 提供的模块构建、部署和运行机制(模块粒度代码拆分、模块热部署、同一 JVM 运行），是初步符合 Serverless 的设计理念的。

同时我们看到，围绕这套框架的配套运维系统、产品系统也开始初见雏形，经过架构决策后，非常笃定这个架构演进方向，决定作为种子用户加入初创团队，作为 SOFAServerless 的业务样板间进行孵化。

4. 关键架构设计

如何重构我们的巨石应用？我们借助 SOFAServerless 对模块、基座的理念，对巨石应用 Fundapplication 进行了拆分、托管，将业务的关注点从应用聚焦为“轻应用”，将公共模块、基座采用了类 BaaS 和 FaaS 的全托管模式。

新模式的探索

基于 SOFAServerless，我们探索了“轻应用架构范式”，通过 SOFAArk 框架将应用程序拆分为基座、业务模块、公共模块这三种不同的“image”。

这种做法的好处，一方面可复用的业务能力、日志等技术服务能力抽象为公共模块，由能力的供给方托管，可快速实现规模化复用；另一方面模块和基座的边界比较清楚，基座不承载业务逻辑，只承载 Java 运行时容器、二方 Jar 包管理、蚂蚁全套中间件集成等基础运行能力，可完全由非业务研发同学托管，真正实现业务模块研发同学的关注点聚焦。业务研发同学只需要关注业务模块，把所有业务高频变更的代码都放在业务模块，减少迭代竞争。

Serverless 无服务器化带来的轻运维方式

因 Serverless 无服务器化技术的的核心原理，能够带来一些显著的变化。比如热部署的技术、场景化服务动态发布的技术、无服务器技术（共享基座运行时），可以让模块快起来、并能够做到隔离、“免”运维。

形成了一种新的研发模式，基座这种低频变更可以对标传统的经典 SOFA 体系；模块高频变更可以走到轻研发模式，同时有了容器弹性腾挪的能力加持，也一定程度上做到了流量隔离和弹性伸缩，见下图：

研发过程独立，互不影响，4 个业务方，20+ 模块独立迭代敏捷变更；
快速划分并创建集群，隔离部署业务，业务集群间模块支持弹性伸缩，方便快速弹出解决运维的问题；
基座统一托管代运维，贴合人性，削减为轻运维成本极低。

试想一下这个案例，大家研发中可能经常在提交部署后才发现一个 if else 判断逻辑写反，需要 commit 修复代码+重新部署。
SOFA 应用：10min 的成本。 研发同学的直觉肯定是先去干别的，过一会儿再回过头来再去做验证工作，我相信同学很难有这个时间节点把握，不太可能定一个 10min 的闹钟提醒自己回来，所以整体花费可能远大于 10min。
SOFAServerless 模块：30s 的成本。 研发同学一般会认为可能可以等一等，马上就能投入验证和自测工作，所以整体是一个“延续性”的过程，可以一鼓作气把整个研发自测做完。

Serverless 应用架构带来的复用提效

SOFAServerless 代表了一种应用设计范式，有基座抽象、模块内聚的特性，通过基座这种复用模式可以提供开箱即用的方便模块快速集成的技术能力，让我们可以在基座上有所发挥。

基座可以成为一个“BaaS 化的应用服务市场”，我们可以把一些例如工具、脚手架等能力内置到模块上；提供一些技术产品让模块可以选装快速集成；引入一些通用业务能力委托给基座加载，减少模块的集成和运维层面的负担。我们之所以把他比作应用服务市场，是因为我们仍然认为模块应该被松绑，基座提供的能力是可以按需选购，且轻量使用的。

从单应用研发，到随意从市场选购，复用可以很敏捷。通过 BaaS 化的市场，已内置、选用、托管等方式把复用成本打到很低。

直击心灵：研发时我们是不是有一些事项是重复性工作、甚至非常想偷懒？

比如研发过程中做一个模块级应用，势必需要一些通用的切面、工具集、方法执行模板、基础模型类……有些甚至还需要自己设计一把，还可能需要集成参数中心等较重的配置平台，如果已经内置好了研发体验会非常舒适。

得益于模块和基座在运行时共享一个 Java 进程，所以我们可以非常方便地为模块提供无感的集成体验。

5. 基座 Owner 的自我修养

如果你已经决定选型或者已经使用 SOFAServerless 了，可以继续查看本章。本章将资金近两年 Serverless 的落地经验浓缩成 基座 Owner 的自我修养。

在新的应用架构下，将原先的系统 Owner 拆分成基座 Owner 和业务模块 Owner 两类角色。业务的 Owner、基座的 Owner 存在上下游服务和供需关系，基座 Owner 要服务好模块客户、解决模块客户问题，让业务模块开发者能够享受到基座建设的红利，进而更快速支撑业务增长。

以前的系统 Owner，只需要关心单应用的稳定性、容量评估、演练、应用的中间件升级等。但是当我们做了基座和模块的拆分之后，也带来了一些新的问题。因为新的研发模式，引入了热部署框架、场景服务托管框架、跨模块通讯等新的研发框架需要去理解，相比原先的系统 Owner，对基座 Owner 也有了一些新的角色要求。我们将资金这两年基座 Owner 走过的路和经验总结为 4 个代名词——效能官、技术布道师、应用架构师、治理同行者。

业务模块研发提效的效能官

面向场景交付提效，实际上对基座管理员有更高的要求，这个变化的来源于模块研发者需要一整套敏捷研发、轻运维、高质量保证的交付模式，这就需要让基座提供更多的能力、更便捷的运维能力、更好的统一防控。新的应用架构下，我们愿景是场景的研发者可以只关心场景服务，一切与场景模块研发提效相关的命题都可以由基座管理员的去承担托管。

基于交付提效的目标，我们需要下探一下，需要一个可刻画、可跟踪、可优化的全链路研发和协作机制。

研发洞察体系

说“提效”并不是盲目拍一个目标，而是一个有数据指标刻画以及有追踪低效的手段，所以首先就需要定义研发效能的度量。因此，我们解剖了交付过程，然后通过“湖水岩石效应”的方法论，来圈定我们改进的方向。因此在 2022 年，我们和研发效能一起探索了资金业务全链路研发洞察体系，发现了很多的效能短板，我们也基于指标的牵引，完成了很多针对性成片的建设。

我们把软件开发整个交付周期比作湖的水位，那所有问题都掩藏于水面下方；可能全量问题都看不到，或者只是感觉可能有问题但没那么严重。如果我们想要削减交付周期（降低水位），那水面下的“岩石”就逐渐暴露出来，如需求复杂度的问题、多人协作成本的问题、环境稳定性的问题、研发的理解成本的问题、研发复用的问题、质量回归的问题、跨团队组织沟通的问题……

研发提效

基于 SOFAServerless 这样一种新的应用架构，首先，对于一个小白用户来说，一定是有一些理解成本的，例如对中间件的理解、对框架的理解。其次，在新研发模式的研发过程中，也有一些“过程成本”，例如代码库从 0-1 的成本、代码调试的成本、非功能性考量的成本……

由于引入了热部署框架，就需要研发同学理解运维单元、服务发现的生命周期；
由于框架层面深度使用了 Spring 上下文、跨 ClassLoader 等机制，需要对研发同学的基本功有一定要求；
由于中间件、框架演进（中间件演进、Serverless 框架演进、基座能力封装演进）带来的编程界面差异，需要研发同学掌握一些编程技巧和问题规避。

我们也一直在尝试削减 Serverless 引入的新要素带来的负向效能影响：

在系分阶段： 我们就非常注重提高同学们对所需技术能力和服务可复用性的认识，提供了成熟度对照表、复用对照分母等，告别“手口相传”这样的低效方式。

在研发阶段： 研发的“过程成本”层面，我们一开始面临环境可用率很差、常调飞的问题，通过环境中心上云、迁移九州等一些代际升级解决。后来我们发现了模块初始化建设提效、服务抽象复用的诉求，也做了通用脚手架内置，框架集成等针对性的建设；研发的“理解成本”层面，起初模块研发者使用中间件的编程方式跟之前有一定差异，我们作为客户推动 SOFAServerless 研发框架的研发体验升级，“将复杂留给自己，将简单留给模块研发者”，做了多个版本的框架升级，最终达到常用中间件的原生编程界面的体验。

质量风险提效

目前处于在 SOFAServerless 质量工具配套适配过程态，我们也在抓紧基座防控体系的建设，确保风险可控，不出大问题。在我们面临一些大版本升级、大项目上线的过程中，很依赖一线质量同学的人肉回归。需要把这部分成本削减下来。所以需要各个阶段的质量工具配套的适配，第一阶段是预期拉平 SOFA 应用，即能够支持 SOFABoot 的质量工具也要能适配 SOFAServerless，主要包括线下研发阶段的的 FlyTest 测试框架集成、预发阶段的仿真回放比、灰度阶段的灰度引流。第二阶段是探索出和 Serverless 要素适配的质量能力，比如智能化回放、动态弹性伸缩、智能变更防御等。

团队 Serverless 研发模式的技术布道师

Serverless 研发模式对一线研发者的编程方式、服务路由方式、基础运维方式都有一定的变化，这些变化会让一线同学经历“不适应”阶段，基座 Owner 需要具备能力和心理素质，来做技术布道的第一责任人，帮助大家熟悉这些变化。

编程界面差异

SOFA 应用： 都是基于 SOFA 中间件体系进行研发，包括半模块化、Spring 上下文、中间件 starter 等能力都是蚂蚁 SOFAStack 原生的编程界面。

SOFAServerless 应用： 场景化服务的动态发布、中间件的使用、通讯路由等。我们经历过 Linglong SDK 或者基座封装的方式，这个阶段很多服务发布、服务通讯的编程界面都是非标的，对研发者来说还是有一些理解成本的。后续演进为 SOFA-Trigger 框架统一做封装和管理，各类中间件如果按照 SOFA-Trigger 的标准来适配，就能够正常在 SOFAArk 框架下运转。所以在升级了 SOFA-Trigger 的基座上，模块可以原生使用 SOFAStack 编程界面。

举例说明一下，假如我们研发过程中需要使用事务型消息：
在 SOFA 应用下：我们肯定是使用 MsgBroker 的原生编程界面去实现消息的发送和监听、以及事务的回查；
在 LinglongSDK 环境下：SOFAServerless 的 LinglongSDK 并不能提供事务消息的能力，我们可能需要通过基座做一层代理和消息中心交互。通过基座和模块的通讯去间接实现模块的事务消息监听、发送、回查；
在 SOFA-Trigger 环境下：SOFA-Trigger 框架已经能够完全代理消息中间件，做到协助消息中间件在 Serverless 运行时和注册中心进行服务发布、注销的交互。让用户可以使用消息中心 SOFA 的编程注解、配置。

场景化路由和通讯隔离

SOFAServerless 具有多 AIG、多场景隔离的特性。AIG 是一个网络层面的切分概念，AIG 之间的机器、域名、服务都是隔离的；场景是一个服务发布管理层面的概念，场景具有动态发布服务的能力，一个模块可以在多个场景内发布出不同服务实现业务隔离。

我们也做了多业务 AIG 的隔离、多业务场景的拆分，拆出一个通用 AIG 用作多场景混布，主要承载一些低流量、新孵化的业务。一些比较高保、量级大的场景则独占 AIG。例如 C 业务场景几乎是独享 AIG，C 场景和 B 场景在公共集群上混布。所以整体上我们是一种多 AIG 非对等部署的部署形态。当然在这个形态下我们也需要应对服务治理相关的问题。

在各类型的中间件、流量入口、路由，都有了一些特殊的要点，比如 SOFA-Trigger 框架下，各个 RPC 服务、消息的场景 ID 隔离和路由。
涉及到跨场景、跨 AIG 的特殊通讯方式。比如一些公共服务，在同 AIG 内要做到 JVM 级别的服务通讯，也要考虑跨 AIG 通讯的情况。

更细运维粒度和生命周期

代码变更的过程、以及运维的过程，最小的研发、运维单元由原来的应用级别缩减到场景级别。这样研发和运维关注点就可以细到只关注自身的服务，尽可能的减少对部署单元、服务器的关注。

而在单机视角来看，每台服务器只有在基座启动时会受到耗时长的影响，模块的拆装生命周期都是在热部署的环境下运转的。会极大缩小部署和运维过程带来的耗时

模块发展规划的业务应用架构师

虽然 Serverless 模块是一个面向“轻运维”的一个粒度，但是轻不代表可以无序扩张，无序扩张也会带来一些治理成本，防止架构陷入低成本模块新建陷阱。

我们在前期解决了各个场景的隔离问题，按照垂直领域拆分出了模块。但是在模块发展到一定规模的时候（资金创新业务在 2022 年末已经有 20+ 模块），大家面临的问题就不仅仅是单一模块的研发过程提效了，而是有大量可复用的服务没有能够复用起来形成烟囱式建设了。公共服务的沉淀又成为了新的挑战，虽然重复建设的基础上做一些归并，选择部分模块增强“东西向”的接口调用承接一些公共服务，这样很可能会有边界分歧；如果把公共服务下沉到基座，就很有可能形成高频热点，让我们的又重回大量迭代竞争的巨石应用时代。

因此我们对模块的创建也是有一定原则的，当然，任何原则订立下来都是具有二义性的。我们只是在业务动态发展和增长的情况下，尽可能地适配我们的业务发展，对于怎么更好地削减理解成本和运维成本，寻找一个拆分和抽象的折中点。

举一个很直观的例子：一个创业公司初期会孵化出很多微服务，但是当微服务发展到一定规模的时候会面临额外的运维成本、研发理解成本、运行时通讯成本……此时就需要集中进行治理，尤其是对可复用的部分的沉淀和抽象。
这个时候一方面是需要一些原则来约束增量应用的扩张的，另外一方面也要依据这些原则去做存量的模块的架构治理，做好归并和场景化复用。

蚂蚁研发全链路治理同行者

在 SOFAServerless 的新应用架构下，我们也需要关注周边生态和配套，可能部分能力的适配具有一些滞后性的。但是整体上，终态肯定是要追平甚至超越经典 SOFA 体系。所以我们尽可能梳理清楚我们不同的阶段、不同的维度到底需要哪些能力，这些能力是否已经适配；已经适配我们就直接享受这个红利，适配有滞后我们就寻求一些短期方案去过渡。

基座管理员要对配套成熟度梳理清楚，在 SOFAServerless 发展的前期，有一些中间件、二方包、质量配套、技术风险配套对模块研发者来说是有适配滞后性的，所以短期必须需经过一些特殊的机制去封装。且作为基座 Owner，需要有研发体系全链路视角，洞察研发模式变化后对一线模块研发同学研发生命周期过程中的变化，并建立与研发效能团队的通道来消化、推进他们的诉求。

举个例子，现在质量仿真体系、智能化 CI 自动化用例体系，对于 SOFAServerless 的兼容具备一定滞后性，基座 Owner 需要与相关团队建立链接，并关注进展。

目前 SOFAServerless 已经解决了大多数的成熟度问题，已经度过了催熟期，对基座 Owner 已经减少了 80% 的工作要求，研发模式已经趋近于稳定成熟。

6. 回顾和展望

我们目前取得的成果

场景创新技术效率的极致提升——我们基于 SOFAServerless，构建了“资金场景应用中心”系统，颠覆了传统巨石 SOFA 应用做场景化创新的模式。

我们构建的“资金场景应用中心”平台，采用了上述思路，将业务关注点从 SOFA 应用粒度聚焦到了轻应用粒度，对 Java 运行容器、通用业务能力做了全托管，平台陪伴了业务 idea 不断落地试错、业务创新节奏小步快跑。两年时间，我们业务轻应用模块已经达到 20+，部署次数在月均 2000+ 次。但是我们的每次部署耗时维持在 20 秒左右，相比之前每月开发迭代部署整体耗时减少了 95% 以上；业务之间基于场景的互相隔离机制，也基本上摆脱了传统 SOFA 应用火车式发布频繁抢占。整体研发和发布效率的体感，毫无疑问提升了大家研发幸福度和“今晚早下班”的概率👏。

回顾落地方法和原则

回顾全篇文章，我们从分析问题、定义问题、技术选型、详细设计、落地执行去把我们资金技术 Serverless 提效的思路描绘了出来。需要明确的是，虽然对应用架构的创新和探索是非常激进的一件事，但是创新并不是拿锤找钉，带着“造好的轮子”摸着黑去探索，而是遵循了一些方法论和原则，把优秀的架构设计、优秀的提效特性吃透后做到在业务域平稳落地。

基座落地前的推演，我们会思考以下几个问题：

如何做到激进的架构升级同时也兼顾业务的稳定性？
Serverless 配套拼图如何落地？中间件的配套、质量风险配套、研发过程配套……等相关设施如何建设？
需要深度思考如何把增量价值放大？以及如何把基座的复利性发挥出来？

结合资金域的落地过程，我们是这样应对的：

落地过程面临很多未知问题，初期我们可能只是宏观上做了可行性考量，但是随着对 Serverless 架构的认知提升，我们做架构治理的问题分母也变大了，这些“不确定性问题”带来的边际成本是比较大的。所以我们也遵循了一些的成熟的方法论来牵引整个架构升级的事项推进，初期我们运用了假设验证的方法来削减“不确定性”，通过问题反馈做调整和持续迭代；中期通过战役、跨团队协作去联动各个问题域弥补 Serverless 发展中的过程态短板；后期我们也针对资金基座的下探，去锚定低效问题的治理方向的同时，做精准发力并沉淀一些效能领域的建设。

分时： 运用 MVP 最小价值交付的方法，先做 poc 假设验证，再进一步在可试错的业务上迭代，最终形成成熟稳定的态势后规模化推广。
分治： 分拆问题，各自突破。协同了 SOFAServerless 战役的 8+ 团队，把业务面临最紧迫的问题分析清楚并提供输入。
- 中间件适配滞后性的问题： 短期用自身的适配框架度过+长期推进 SOFA-Trigger 适配中间件；
- 研发效能工具的问题： 专题战役给 Linke、Linkw、九州提供了输入并推进解决；
- 技术风险配套的问题： 让仿真回放工具、灰度引流工具、采集框架工具等平台各自带回；
- 自身的架构治理： 包括迁移九州机房、升级 SOFA-Trigger 等代际升级，和 SOFAServerless 团队做了紧密联动。
分层： 按照自上而下不同的层次发掘提效点，从模块研发的层面、基座管理的层面、风险防控的层面各自去做一些下探，形成一些经验和过程的沉淀。

对“轻研发”模式的期待

作为轻应用这种研发模式的早期探索者，我们已经把心路历程分享出来，但是与此同时也有一些新的思路。

虽然蚂蚁的每个域的业务形态不一样，但是“资金场景应用中心”还是比较有代表性的，如果把所有技术产品都按照“类中间件”的方式提炼、抽象成 starter 插件放在插件市场里，顺便把一些问题规避、二方包基线、通用配置等运行时要素也提取出来，我们可以得到一个通用的基座模板。其他域可以基于这个模板，快速实例化构建出一个适合自己业务域的基座，让使用方可以大幅削减基座 0-1 成本，可以快速丝滑地接入 SOFAServerless。

我们在 2023 初开了一个脑洞，也和 SOFAServerless 产品团队贡献了这个想法，如下图所示：

这样还是不够，实际上还是存在多个业务基座各自运维，还可以更进一步。

比如目前的基座还是由业务团队的基座 Owner 来负责的，且模块研发者可能或多或少还需要接触基座的概念，实际上这部分与业务没太大关系，可以考虑由特定技术团队完全托管掉并持续做技术演进。如果未来有一个通用基座的设想，基座如果能全面 BaaS 化，基础能力的集成、弹性资源的管控、业务流量的管控都能够技术产品化，我们就能够让模块开发者真正专注于业务场景的研发不用关心底层运维事项，让 SRE 能够接管基座的“代运维”，统一运维的基线可以覆盖到 BaaS 化基座。

实际上 SOFAServerless 技术产品也在做一些相关通用基座的试点。如果真正具备通用基座的广泛运用，才可以真正称得上是“轻研发”模式。

对 SOFAServerless 架构的期待

SOFAServerless 是一种新兴的、高效的应用架构，具有敏捷开发、低复用成本、高灵活性、易隔离等优势，正在逐渐运用到蚂蚁的各个业务领域。但是 Serverless 架构也面临着治理上的挑战，需要建立相应的事件处理、安全性控制、性能测试、成本控制等机制来保证服务的稳定性、可用性和可靠性。

未来，随着 SOFAServerless 的不断发展，蚂蚁架构部也在做 Serverless 提效样板间推广，在蚂蚁各业务领域中的应用必将越来越广泛。当然，Serverless 架构仍有一些优化空间，需要不断建设以满足不断变化的业务需求，如更灵敏的弹性能力、轻运维托管能力、智能化质量工程能力等还需要持续进行技术创新和探索。我们相信，借助 Serverless 技术的进步和发展，将会为蚂蚁集团未来的业务创新带来更多的机会与可能！

SOFAServerless 开源助力企业低成本实现 Serverless

SOFAServerless 当前已平稳支撑了蚂蚁集团 42 万核数规模的生产业务，并成功支撑了近 3 年的大小促活动，随着这套技术在蚂蚁内部越来越成熟，凸显了它能够让普通应用以尽可能低的成本平滑演进到 Serverless 架构，并且还很好解决了微服务领域里 4 个痛点问题：

资源与维护成本之痛： 存量微服务如果拆分过多，能低成本改造成模块合并部署在一起，从而解决拆分过多带来的企业资源成本和维护成本痛点。
研发协作之痛： 一个应用可以低成本拆分出多个模块，模块间可以并行独立迭代，从而解决业务多人协作阻塞问题。
开发认知之痛： 通过拆分出基座屏蔽了业务以下的基础设施、中间件和业务通用逻辑等部分，从而极大降低了开发者的认知负荷，提升了开发效率。
微服务演进之痛： 模块可以灵活部署，解决了微服务拆分与组织发展灵敏度不一致导致的协作低效和分工不合理问题。应用能低成本拆分成多个模块，可以部署在一起，也可以演进成独立微服务，同样微服务拆分过多也可以低成本改为模块合并部署在一起。

因此，蚂蚁集团开始致力于 SOFAServerless 开源版建设（当前已有 8+ 企业在使用 SOFAServerless 开源版），旨在帮助整个行业去解决上述痛点问题，帮助企业早日实现降本增效！

欢迎大家关注 SOFAServerless 开源社区，加入我们的社区钉钉群：24970018417。更欢迎大家与我们来一起共建，一起创造价值解决行业痛点！

了解更多...

SOFAServerless Star 一下✨：

https://github.com/sofastack/sofa-serverless