1688 简单业务场景下的 Serverless 提效实际

作者 | 远岩（阿里巴巴 CBU 技术部 Serverless & 工程效力负责人）

前言

首先为大家简略介绍一下咱们的业务场景，1688 隶属于阿里团体的国内贸易事业部（CBU），是阿里最早起家的业务，已有十几年的历史。咱们次要负责 PC 端 1688.com 以及手机端阿里巴巴 APP，是目前国内最大的 B 类电商交易平台，次要面向 B2B 电商业务的场景，为中小企业提供批发、零售、分销以及加工定制等电商交易渠道。

我自己是在 1688 团队的无线服务端技术团队，团队次要是给 App 端提供业务反对，负责 1688 手机端 App 外部的各种场景构建，比方首页举荐、商品详情等等，也是典型的电商业务场景。

FaaS 在 1688 的演进之路

1688 对 FaaS (Function as a Serverles) 技术的摸索要追溯到 2015 年左右。过后整个阿里团体最大的业务指标就是“ALL IN 无线”，挪动互联网刚刚衰亡，须要疾速地把存在 PC 端的业务，无论是淘宝也好，还是 1688，须要能迅速地把它移植到挪动端下面去，生成 App 来抢占挪动端流量。

在这样一个大的业务背景下，1688 的解决办法是设立无线服务端。通过微服务体系调用 PC 端存量的业务接口，而后面向前台的挪动端业务去进行一些轻量的业务逻辑编排和 UI 层的映射，最初通过挪动网关，就能够疾速为 APP 端提供领有同样业务能力的服务接口。

挪动互联网端的性能迭代十分之快，在这种模式下，咱们很快遇到了问题：传统的微服务体系构建、施展、部署和调试工夫都十分漫长，而面向前台的业务改变又十分频繁，速度要求很快。技术能力和业务诉求之间产生的错位，push 着咱们去寻找和摸索更好的解决方案。

FaaS 能力落地的两个阶段

FaaS 在 CBU 外部的落地经验了两个大阶段。第一个阶段是 2015 年，部门外部自研了一套基于 JVM 的动静加载零碎，来实现疾速公布、疾速上线、热部署等等，根本实现了 FaaS 的成果。第二阶段则是从去年开始，咱们与阿里云 FC 团队进行共建，将整个 FaaS 能力的底座更换为阿里云的函数计算，以取得更好的弹性伸缩、容器隔离等能力。

MBOX：基于 JVM 动静加载能力的 FaaS 零碎

前文说到，在整个无线端业务疾速迭代的背景下，咱们须要一种可能实现疾速公布变更服务端接口的能力。在 2015 年左右，Java 工程界支流的思路是充分利用 JVM 的动静加载个性：即在不重启 JVM 的前提下，通过肯定的机制将内部的代码实时编译成 class 字节码，而后动静地载入正在运行的 JVM 实例中，从而实现热加载的成果。

于是，基于上述的思路，咱们打造了一套基于 JVM 的动静服务加载零碎 —— MBOX。在 MBOX 中，咱们构建了一个通用的轻量服务容器，该容器能够接管来自内部的一段代码（可能是一个 Java 类 或者是一个简略的 groovy 脚本），并对代码进行实时的编译，生成 class 字节码。之后容器自身还会对生成的字节码进行肯定的平安加固操作（如打消死循环等），最初通过一个自定义 class loader 把它加载成线上正在运行的 JVM 中的一个 class，生成对象实例、注入中间件代理，便能够对外提供服务。

基于 MBOX，咱们实现了在线编码、在线预览和秒级公布的能力，以当初的视角来看，它就是一个十分典型的 FaaS 服务平台，并具备以下特点：

一、相比于传统微服务，它是 在线开发的模式，随写随用，所见及所得，研发效率十分高。

二、热加载更新机制。它能够做到秒级的公布，整个业务上线的迭代效率非常高。

三、对于应用平台的开发者来讲，它带来了 Serverless 的体验，因为所有的运维、机器部署等等，全副是由 MBOX 平台来承当，开发只须要关怀其业务逻辑的实现即可。（在这里，咱们表演了相似当初云服务厂商的角色）

在长达五年的工夫里，MBOX 零碎承载了整个 1688 超过 10 万 QPS 的业务调用，巅峰期间有超过 1500 个线上函数，节俭了大量人力资源，在整个无线业务扩张阶段立下了汗马功劳，也为咱们的 Serverless 技术摸索之路关上了一扇大门。

说完了长处，咱们再谈一谈这套零碎的毛病和危险：

首先，第一点是 隔离性问题，因为是 MBOX 基于 JVM 的，JVM 自身没有方法提供无效的资源隔离机制（如 CPU、内存等），所以存在比拟大的平安危险：即同一个业务容器中加载的多个服务之间会彼此产生影响。比方明天这个业务集群 A 下面有一个人写的代码产生了内存泄露，后果可能是整个集群的性能都被拖慢，下面所有的服务都会受到影响，这是一个十分重大的安全隐患。

第二点是 代码的开发模式太轻，纯脚本式开发，只能写个代码片段，尽管开发起来很快很爽，然而没有工程构造，不能应用框架、不能应用任何的设计模式，这样导致可利用场景十分受限，代码自身的品质也很差。

第三点对于 MBOX 的保护方来说，资源的治理是一个十分头疼的问题，常常遇到整个集群水位飙升，然而又没有方法判断进去到底是哪一个服务在外面占用了资源的状况。而零碎自身又无奈很好的进行弹性伸缩，只能依赖人肉手动扩容，到了平台保护的前期，运维老本是十分高的。

到了 2019 年左右，MBOX 的一些问题曾经比拟凸显了，而这时业界在 K8S 的影响之下，掀起了 Serverless 和云原生的技术浪潮，咱们立即开始了对应的技术调研，最终在 2020 年底与阿里云函数计算团队开展共建，心愿可能打造一套真正面向云原生的 FaaS 平台。

阿里云 FC：基于 Serverless + Sidecar 的 FaaS 零碎

阿里云函数计算（FC）在 K8S 容器主动运维能力的根底上，打造出了一套高弹性、强隔离，且易于凋谢定制的 FaaS 基建，目前曾经根本成为整个阿里团体外部 FaaS 能力的对立解决方案。

除了底层高度成熟和弱小的弹性主动运维能力之外，FC 还提供了开放度十分高的 Runtime 设计，任何语言甚至是任何团队都能够定制本人的运行时框架，从而最大限度满足业务一线开发人员的诉求。

对于跨语言的老大难问题 —— 中间件调用上，FC 团队和中间件团队，联合微软最新开源的 DAPR 技术，实现了一套标准化的 Sidecar 能力，涵盖了 RPC、缓存、音讯队列、配置核心等常见中间件，抹平多语言差别的同时进一步精简了用户的运行时容器，让函数的冷启动和弹性速度得以进一步晋升。

最终在 FC 底层弱小技术的撑持下，咱们一起共建了面向团体内 Java 研发者通用的 Runtime 框架及研发运维配套设施，替换了原有的 JVM MBOX 零碎，实现了 FaaS 能力的技术换代。

回顾 CBU 的 Serverless 演进之路，从最早的微服务架构，到自主研发的 JVM FaaS 零碎，再到当初的 FC 函数计算，逐渐摸索出了最适宜业务场景的技术计划，同时也算是在业界率先迈出了大规模落地 FaaS 的一步：作为团体第一批大规模落地 Serverless 理念的部门，咱们的 FaaS 零碎在部门内领有超过 80% 的业务渗透率，应用工夫更是达到了 5 年以上。

FaaS 落地的灵魂三问

在理解了 FaaS 的能力和实现之后，咱们接下来探讨大家最关怀的问题：如何在业务零碎中落地 FaaS 能力？

以咱们过往的实践经验，在理论业务中落地 FaaS 并非大部分人设想中那么“丝滑”，势必会遇到一些问题，这里提炼了三个咱们认为最外围的“灵魂拷问”：

一是 存量业务的革新。对于存量的业务（尤其是咱们这种曾经继续运行了很多年的业务），有大量的历史包袱不能抛掉。这就面临一个问题，线上大量的传统 Serverful App，怎么去转换成 Serverless Function？间接进行革新危险是十分大的，是否有方法在保障现有业务稳固运行的前提下，以最小的老本取得 FaaS 带来的劣势？

二是 FaaS 的碎片化问题。传统 Serverful 利用的构建思路是十分高内聚的，某个业务的外围能力根本都聚合在几个微服务利用中，数量绝对较少。然而函数不同，它轻量化的特点会导致数量收缩十分快，如果不加以设计和管制，那么很容易呈现一个业务背地对应着几十个函数的碎片化情景呈现。

三是 研发提效的问题。业界目前普遍认为 Serverless 可能大幅晋升研发效率，然而真正落地之后会发现研发提效这件事件，并没有那么简略，只是将传统的 Serverful 利用换成 Serverless 函数可能带来的研发提效幅度是十分无限的。

一、存量的简单业务如何与 FaaS 联合？

首先答复第一个问题，在存量简单业务和 FaaS 能力联合这件事上，通过实际摸索，咱们总结出了两种比拟落地的模式，别离是 BFF 模式和扩大点模式。

BFF 模式

BFF 模式是当初 FaaS 落地比拟常见的一种支流做法。咱们能够把传统 Serverful App 外面的逻辑进行一些形象，一般来说在咱们能够依据变更的频繁度，将业务场景中的逻辑分为两层：一部分的代码逻辑比拟轻，同时没有一些简单的依赖，然而产品的需要可能大部分集中在这部分，称其为 变动层 。另一部分的代码可能是业务的利用框架，中间件二方依赖，以及一些外围的重业务逻辑，相对来说改变不会太多，然而革新危险十分大，革新收益也可能不尽现实，称其为 稳固层。

如果你的业务利用能够依照上述的思路拆分，那就非常适合 采纳 BFF 模式，把变动层形象进去，放到 Serverless 函数中去，这样就实现了一个相似 BFF 层的成果，前台的生产方其实是间接通过函数再去生产 Serverful App 外面稳固层的 API。这样就能够结构一个业务的缓冲区，可能实现更快地公布 & 交付以及更少的运维。尽管有相当一部分的老代码包袱还是丢不掉的，然而能够集中 80% 的精力提效。

这种模式比拟实用于前台类的业务场景，比如说传统利用 M-V-C 架构当中的 controller 层，就非常适合应用 FaaS 来替换。

扩大点模式

第二种模式是 扩大点模式 ，扩大点模式比拟适宜于偏中后盾的场景，或者说业务外面的一些中台零碎，例如咱们的商品核心，就用到了这个模式。

对于中后盾类的利用，个别自身就十分复杂，且业务逻辑十分多，加上历史比拟悠久，不适宜进行大刀阔斧地革新。然而咱们能够把简单的业务逻辑层进行肯定的形象，面向未来设计一些要害的扩大点，同时提供扩大点的 FaaS 适配计划。这样对于一些后续增量的业务逻辑，就能够应用 FaaS 的能力来提供，而对于存量的业务逻辑，则能够根本放弃不变，只须要在代码构造上稍作适配，也能够成为规范的扩大点实现。

扩大点模式的另一个益处是能够让原来封闭式的架构变得更加凋谢化，采纳这种模式后，即使是中台性质的利用，只有制订好扩大点的对接标准，任何的业务方都能够通过提供自定义的 FaaS 函数来实现本人想要的扩大能力。在 1688 的商品中台零碎中，就通过这种扩大点模式实现了商品价格计算逻辑的业务凋谢化定制能力。

二、防止 FaaS 的碎片化问题

编程界面的衡量

晚期咱们在 MBOX 零碎中定义函数的编程界面时，采纳的是脚本式编程，用户的编程粒度就是一段代码，一个 Java 类。这种形式尽管写起来十分轻量，然而会导致函数数量十分多（为了实现一个稍简单的业务，可能须要写很多个脚本），同时因为没有工程构造，代码品质十分低下，也无奈应用一些设计模式）。因而在基于 FC 制订函数的编程界面时，咱们基于上述教训设定了一个规定，那就是用户函数的运行粒度应该是一个“Micro App”，而不是“Single Function”；编程界面的粒度应该是一个“Code Project”，而不是“Single Script”。

基于这样的准则，对于开发者来说，一个函数实例更靠近于一个微利用，整体保留了最精简的工程构造，即能够以较低的老本进行繁多性能点的实现，同时也能够进行简单逻辑的开发，引入各种二、三方库，不至于产生十分重大的函数数量收缩和碎片化问题。

建设外部服务市场

只管采纳了 Micro App 式的函数粒度定义，在业务中应用到的函数数量依然会比传统微服务利用多出好几个量级，为了解决这个问题，咱们设计了【业务域】-【函数组】-【函数】-【接口】四层纬度的函数分类定义，并在函数的工程模板里埋入了插件，在函数实现构建公布的时候主动采集上报这些分组分类信息，最终建设出面向外部研发人员的函数服务市场，让大家可能直观的看到以后所存在的函数分类，以及各个接口 API 的归属信息。

三、研发效率的瓶颈在哪里？

让开发者可能“Only focus on business”，这是 Serverless 从诞生之初就标榜的核心理念，然而如果只是简略将运维等底层根底设置切换到 Serverless 的基建之上，引入 FaaS 等相干技术能力，其实对研发人员而言离真正意义上的“Only focus on business”还差很远。

在咱们初期落地 Serverless 时，的确发现研发同学编写代码的效率如同高了很多，然而从整体的业务团队的业务需要交付角度来讲，研发效力没有产生量变的晋升：大部分的需要研发流程依然比拟简短，需要推动过程中的沟通老本、合作老本仍然巨高不下。认真扫视咱们会发现，研发效力的要害瓶颈很多时候可能并不在于“研发”自身，而在于代码之外。

那么 Serverless 可能为研发提效是否是一个伪命题呢？当然也不是，首先，Serverless 和 FaaS 的确能够大幅度降低运维和编码的老本，晋升效率；其次，Serverless 技术的呈现让服务端的技术门槛升高，使得一些非服务端业余的研发人员也可能有能力开发一些简略的业务逻辑，这使得需要的 全栈式开发 成为可能。从整体需要交付的效率来考量，假如研发人员可能独立实现整个需要的所有开发工作，无需和别人进行联调沟通，那么效率势必是最大化的 —— Serverless 为这种全新研发模式的落地和遍及带来了可能性，或者才是“Only Focus on Business”真正的意义所在。

总之，Serverless 也并不是提效的银弹，事实上，没有任何一门技术是银弹，当咱们冀望研发效力晋升的时候，更多的还要从全局的视角来进行扫视，而不是将思路仅仅聚焦在“研发”阶段。

简单业务场景的提效实际

最初咱们以一个理论的业务场景为例子，给大家介绍一下 1688 在存量简单业务场景下，是如何联合 FaaS 能力进行研发提效的。

这里先简略介绍一下 1688 的商品详情业务场景：商品详情就是商品面向买家的最终展现页面，承载了大量的商品信息。1688 的商品详情页和其余一般 C 类电商不一样的中央在于：面向 B 类的交易会存在多种交易渠道，例如现货零售、分销铺货、加工定制等等，其中每个渠道的交易方式、价格、库存逻辑都不一样；首次之外 B 类电商对于消费品、工业品等不同行业的商品，在表白上也会存在微小差别；不同渠道和行业定制，再叠加各类电商营销流动玩法，使得 1688 的商品详情页面业务复杂度十分之高。

本来的技术架构中波及到了多个团队，其中包含底层的商品根底团队（对接团体中台商品的能力，积淀畛域模型的服务和一些外围的商品逻辑）、无线服务端团队（将底层商品根底服务面向客户端和前端封装成专用的商品详情接口）、搭建投放团队（负责为页面提供肯定的搭建、投放横向能力反对）以及最终展示侧的 ios、安卓、前端三端。

除此之外，在面对一些业务定制类的需要（如分销等）时，还须要对应的业务团队参加，这种模式下，一个需要最多会有 5、6 个团队在同时合作，沟通老本十分高；再加上服务端侧采纳了比拟重的微服务利用模式，研发和运维效率都比拟低下。

前台业务逻辑收拢：BFF 模式

咱们首先是在业务外围变动最多最快的前台业务逻辑层，以 BFF 模式引入了 FaaS 能力，并且将所有的 UI 相干逻辑都上行收拢到了 FaaS 函数中。这样做一方面晋升了服务端对应逻辑的研发和部署效率，另一方面使得前端和客户端的组件只需解决最简略的展现逻辑，从而尽可能抹平多端技术差别，让一些跨端能力得以实现。

商品后端：扩大点模式反对定义

商品后端侧面对的次要问题是各种定制业务逻辑的接入老本过高，因而咱们采纳了 FaaS 扩大点模式来进行优化：将商品信息的外围逻辑（如价格、库存）形象成一个个规范的扩大点，并对接函数网关，容许任意的业务方依照模板编写一个函数来定制其业务逻辑，从而实现关闭架构的凋谢化。

通过上述的技术架构革新后，咱们能够看到整个需要研发的模式和链路产生了十分大的扭转。在之前老的模式下，如果要定制一个业务的商品详情，须要从业务后端到客户端多个团队全副参加，十分多的链路都须要进行改变，老本是十分高的。而在新的模式下，从外围业务逻辑的定制，到前台展示侧的业务逻辑实现，都能够通过编写简略的 FaaS 函数来实现，甚至齐全能够仅由一位同学实现所有后盾业务逻辑的变更。（如果前端和客户端的组件可能实现低代码 + 跨端开发，那么齐全能够实现业务需要的全栈开发！）

最初咱们来看一下整体业务场景实现革新后所带来的功效，在联合了 FaaS 的研发模式下，商品详情相干的需要发待时长升高了 80%、公布频次晋升 300% +，需要的吞吐量也有晋升；最要害的是，研发人员的投入缩小了 50%，整个后端侧由原来的 2 个正式员工人力投入升高为仅需半个正式员工 + 1 个外包员工反对，参加需要开发的相干团队和人员缩小了许多，整个研发交付链路变得非常简洁明了。

总结与瞻望

最初还是站在当下的工夫节点，以业务团队的视角，简略的对 Serverless 技术做一个总结和瞻望。

以咱们过往业务场景落地的经验总结几个要害论断：

1. Serverless 无疑是一轮新的技术反动，FaaS 等核心技术所带来的生产力晋升曾经在很多场景失去无力的证实。
2. Serverless 的落地要结合实际的业务场景对症下药，而不是说一杆捅到底。
3. 任何技术都不是提效“银弹”，研发效力的晋升更多还要是站在团队的组织架构和人的角度去思考来做业务和技术的联合。

而对于 Serverless 和 FaaS 后续的倒退，我也在此作出一些比拟集体的认识，欢送大家感性探讨：

1. FaaS 将会继续进化：尽管目前 Serverless 的 FaaS 能力曾经比拟成熟，然而仍有很大提高空间。能够领有更好的弹性能力以及冷启动速度。咱们能够看到业界正在 WASM、eBPF 等新的方向上一直的摸索，有理由置信接下来咱们将在这个畛域看到继续的冲破。
2. FaaS 不会齐全代替传统微服务：传统微服务（包含运行在 K8S 上的）与 FaaS 这两种状态，至多在将来很长一段时间里依然会共存，业务团队应该做好这种筹备，就地取材地在业务场景中联合两种技术，施展它们的劣势。
3. 全栈和低代码（或者说，低门槛）研发将会成为一种趋势：咱们看到，Serverless 的衰亡给研发提效带来了一种全新的思路，全栈式的业务需要开发可能大幅升高我的项目中的沟通和合作老本、晋升需要的吞吐量。随着 Serverless 技术的进一步成熟和推广，这将可能改写当初研发团队的状态。