关于serverless:大象转身支付宝资金技术-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 零碎），如下图：

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

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

如果你的利用也存在上述问题，对业务翻新的交付效率产生了肯定的影响，那能够持续参考第 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

举荐浏览

超过边界：FaaS 的利用实际和将来瞻望

蚂蚁 SOFAServerless 微服务新架构的摸索与实际

SOFABoot 4.0 正式公布，多项新个性等你来体验！

MoE 系列（五）|Envoy Go 扩大之内存平安