你们都关注的Serverless，阿里怎么作的？

本文是阿里巴巴前端技术专家-张挺，在 JSConf China 「中国开发者大会」上分享的《面向传统，Serverless 进化之路》，主要讲述阿里集团内部逐步迁移到 Serverless 体系的过程以及思考。

背景

自 GMTC 以来，国内各个公司在 Serverless 投入都有所变化，腾讯和阿里云都铆足了劲在上面发力，提出了各自的解决方案，腾讯推出了 Serverless 2.0，以及几天前阿里云推出的预留模式，都是对 Serverless 愈来愈重视的表现。

本文主要介绍两部分，第一是阿里在近期作的前端研发升级，为拓展前端的边界和职能，尝试作了一次和 Serverless 结合，第二是在这其中，咱们尝试对现有的体系作了思考，但愿能将传统应用快速迁移到 Serverless 体系，享受到 Serverless 红利。

现状

阿里的 Node.js 应用很是多，1600+ 的数量让维护和治理都变的很麻烦，每一次升级都要推行好久，这无论对框架开发仍是平台治理都是不利的。

不少 Node.js 应用都是 BFF 应用，内部平台等，这些应用常年大多都处在负载低（10%如下），没有流量的状态，并且维护者大多处在离职或者不积极的状态，一方面形成了资源浪费，另外一方面也给治理形成了困难。

其次，在集团开发传统应用，须要申请，整个研发流程比较长，须要业务了解预算和资源，牵扯到不少细节。

为此，咱们开始了 前端研发升级 这个大项目。

整个前端研发模式升级的目的有两个，一是为了“前端赋能”，二是为了“前端提效”。

所谓的“前端赋能”，是由于咱们但愿前端可以打破现有的技术壁垒，朝着更底层，面向数据的地方去深刻探索，在这之中能够从面向 UI，视图自己变的更加了解业务，从更面全面的视角来理解现有的体系。

而“前端提效”，则是但愿让 Serverless，用更轻量化的方式进行业务研发，下降整个前端参与业务交付的门槛，同时，在开发期间，也能减小人力总成本，让前端减负，业务小步快跑成为可能。

可是阿里的 Serverless 之路很是困难，不像外界已经有成熟的体系，目前一些缘由没法使用公有云上开放的产品，阿里云也没法直接对内部提供服务，同时，内部的中间件在外部都没有，都须要跨团队来从新建设。

Node.js 基础团队的使命，就是为集团 Node.js 生态提供各类基础能力，包括但不限于框架，中间件包等，而在 Serverless 体系中，咱们要负责框架、工具链、运行时、发布系统，同时也须要和周边的网关，监控系统等对接。

收益

去年 10 月开始，咱们开始进行调研 Serverless 以及了解相关知识，到如今为止，也已经取得了必定的阶段性成果，将淘宝和飞猪两道 BU 的导购链路整个迁移到了 Serverless 体系，而且承载了导购链路的千万级流量。

同时，内部系统也进行了必定程度的 Serverless 升级尝试，无论是重写仍是传统应用迁移，咱们都有了必定的沉淀。

咱们最初的目的是但愿能下降成本，按照网上 Serverless 的下降成本率能达到 90% 以上，不过导购业务比较特殊，流量比较大，不像那些须要弹性的应用，根据咱们的测算，单进程下函数的性能很是不错，可是因为大促要提早预留一些资源，总体机器成本只下降到了平时的 70%，而在非大促期间，不须要预留这些资源，就能更低，降到 40% 如下。

如今都说 DevOPS，而 Serverless 最大的好处是减小运维，减小固定服务器资源，不须要用户关心调度等，同时也简化了开发的代码，专一了逻辑，晚上睡觉会更加的放心，再也不担忧机器容量不足而报警。

另外一边，对于咱们应用治理的人来讲，以前会考虑各类版本碎片化的问题，node 的多版本，框架的多版本，以及启动脚本、依赖等等问题，而使用 Serverless
以后，咱们将这些都固化了，用户也不关心这些，一切都变的简单了，咱们也只须要治理运行时一个版本便可。

在业务前端方面，带来的是挑战和机遇，一方面，前端的工做量增大了，能干的事情也变多了，成了一职多能的多面手，也更了解业务了，另外一方面，传统的后端能够从和前端沟通中解放出来，更专一于提供服务。前端从传统的面向接口编程变成了面向服务编程，因为集团内都是 RPC 服务，在 RPC 发布时会有固定的定义和文档，在调用时有工具辅助生产代码，大大简化了调用链路。

在流程方面，原来须要在各个环境准备和调研，从一开始申请应用，申请预算，申请环境开始，须要了解各个方面的知识，和不一样部门的人打交道，流程审批也很长，而如今只须要在咱们的统一研发平台上直接申请函数组，替代了本来的复杂流程，也提高了整个开发体验。

同时在编码中也再也不考虑路由，MVC 的事情，这些在网关层配置就好，编写代码时会更关注逻辑，和以前的构建发布不一样的是，如今增长了云端集成测试的步骤，因为函数和前端代码同样，是分版本的，也不担忧修改到线上的正常服务，在测试完毕后，只须要将旧函数的 tag 指向新函数便可，这就完成了整个切流的过程，而一旦碰到问题，把 tag 切回去就行。

这就是咱们前端研发模式升级的思考和收益，带给咱们的不只仅是变化，更多的是流程、思惟的革新。

思考

在研发模式升级过程当中，咱们针对现有的导购业务进行了重构，能够说是使用了 Serverless 的方式进行了重写，而有一些老的应用，若是总体进行改造，这个成本会很是之大。

这个时候开发者就会有很常见的一个疑问：我原来的应用，怎么迁移到 Serverless 体系？

而咱们的回答是两种：

• 使用 FaaS + Baas 的方式进行重构，代码更精简，就是须要改形成本
• 把整个传统应用做为一个函数，虽然不够优雅，可是能解决迁移的问题

把整个应用迁移到函数会有一些限制，会对代码结构和模型作一些微调，以符合整个 Serverless 的结构，毕竟新的体系和传统的代码模型是有所区别的。

阿里集团采用的是 FaaS + BaaS 的实现方式，而 FaaS 的总体概念和传统的应用不太同样。

在概念上，Serverless 比 FaaS 的外延要广，FaaS 属于 Serverless 的其中一种实现方式，主要解决的是用户自定义的代码逻辑如何作到 Serverless，也能够叫作 Serverless Compute，同时它也是事件驱动架构的一种。

而 CNCF Serverless 白皮书中也说到，Serverless Compute 是一种粒度更细的部署模型，经过一个或者多个 function，用于响应用户的需求。能够说，粒度小，灵活性高是它的最大特性。

在代码层面，为了让用户更好的理解，咱们把传统代码的结构进行了分解，传统的 MVC 类型的代码，会分为几层。

• HTTP 服务，原框架（koa/midway/egg…)，Node.js 运行时，启动脚本等，将会变为函数运行时，固化下来
• 原有的 HTTP Router，Web 中间件等，将会由 HTTP 网关承接
• 原有的 Controller，业务逻辑（调用远程服务），继续保留，变为函数代码
• 原有的数据库，消息队列，RPC 调用等，都做为 BaaS 服务，用户只关心对应的服务，使用同一的 BaaS Client 进行调用

这样分解事后，咱们对新旧两个体系的代码结构有了进一步认识，能够开始尝试修改部分代码，变成真正的 Serverless。

迁移

传统的应用，会暴露出一些对外的服务供外部调用，好比 HTTP,定时任务,RPC 服务等等，这些服务通常咱们会单独抽离目录，而且和其余暴露的服务共享逻辑层代码，咱们也常常称这些服务为“入口”。

在 Serverless(FaaS) 化的过程当中，咱们会根据当前部署平台的能力（好比阿里云 FC，腾讯 SCF 都会提供 HTTP 服务，定时任务，消息队列等等），将这些入口代码变为基于事件驱动的函数。

咱们经过构建机制，在发布时生成不一样的包，在共享一份逻辑代码的同时，部署到不一样的环境，这个方案最大的优点是复用了原有的逻辑部分，能够和传统应用同步开发，而劣势也有，就是包依赖混在一块儿，因为函数对包大小有限制，可能会形成依赖过大等问题。

HTTP 相对于其余的来讲会复杂不少，会有不少限制，这个咱们在讲下游方案的时候再说。

针对上面的状况，对下游的数据调用咱们也有相应的方案。咱们将这些方案取了几个名字，好比代理模式和网关模式。

▐ 代理模式

首先来看看代理模式。一个传统的 Web 应用会分为 Router/Controller，以及逻辑层，在代理模式中，咱们会保留传统的应用，只将本来的逻辑层部分迁移到了云函数中，暴露出 HTTP 服务。

这样的好处是代码变的精简，改动适中，也易于服务复用，缺点就是依旧会占用一个应用资源做为代理层。

而代理应用通常是经过 HTTP 客户端代理来实现的只是用户体感上须要作一些额外的支持，让开发者在体验上感受到是调用了远端服务。

▐ 网关模式

第二种方式是网关模式，这个模式下，全部的代码都会迁移到新的体系，在 Web 层简单的时候比较适用。

该模式下，全部传统的 Web Router 会迁移到 HTTP Gateway 上，本来的路由，会话、鉴权等能力都将被网关所控制，而函数自己不须要关心这些，只须要关心数据便可。

业界现有的 FaaS 模型大可能是这种结构，集团内也采用了这类结构去实践。

在这种模式下，原有的能力会碰到一些问题，举一些例子：

• 原有的 Web 中间件（koa middlware），会不知道如何处理，中间件大可能是作请求流的拦截和消费，这个时候大多会拆成两部分，一部分被网关所处理，另外一部分，只能交给函数自己，若是有共享的需求，也能够依赖模块来完成
• 原有的会话维持，一部分平台会进行透传 cookie，这个时候你依旧能够维持一个 sessionId，同时使用第三方来存储数据，可是若是网关不作这块，那么就很麻烦了
• 请求对象和原有的不一样，因为函数获取的是 event，context 参数，或者原始的 request 对象，和现有的 koa 等框架不是很一致，上面的方法不必定有，会致使原有的代码作出修改和挑战

▐ 假装者模式

那么有没有不修改代码的方案呢？咱们尝试在函数外部进行代码包裹和数据模拟，让应用整个跑在函数之上，以一种 “微应用” 的方式继续存在。

咱们把原有的 Web Server（midway/egg)，启动起来，在运行时中经过一个固定的端口转发，把 FaaS 的请求参数包裹成 HTTP Request 对象，而在出口处，也将 HTTP Response 包裹为函数能读懂的形式，经过这样续命的方式来延续传统应用。而因为阿里云上的容器只读不能写，目前还没法直接用这种模式。

这种方式须要调整的是，框架须要使用单进程模型（机器配置，轻量化的要求），应用须要无状态（函数机制决定），以及没有长链接等高消耗的操做。

总结

关于 Serverless 的问题还有不少，本文也只是介绍了其中一部份内容，从阿里当前的情况讲起，分享了从去年到今年的研发模式升级实践，也介绍了在这其中咱们的一些思考，传统应用迁移到 FaaS 体系下的方式。后续的整套方案也会在通过双十一的洗礼，大流量的考验后，开放给你们。

One More Thing

淘系技术部依托淘系丰富的业务形态和海量的用户数据，咱们持续以技术驱动产品和商业创新，不断探索和衍生颠覆型互联网新技术，以更加智能、友好、普惠的科技深度重塑产业和用户体验，打造新商业。咱们不断吸引用户增加、机器学习、视觉算法、音视频通讯、数字媒体、移动技术、端侧智能等领域全球顶尖专业人才加入，让科技引领面向将来的商业创新和进步。

请投递简历至邮箱：ruoqi.zlj@taobao.com

---

本文做者：陈仲寅（张挺）

阅读原文

本文为云栖社区原创内容，未经容许不得转载。