本文由阿里巴巴前端技术专家张婷在JSConfChina“中国开发者大会”分享。主要讲阿里巴巴集团内部逐步向Serverless系统迁移的过程和思考。背景自GMTC以来，国内各公司对Serverless的投入发生了变化。腾讯和阿里云都下了很大功夫，提出了自己的解决方案。腾讯推出Serverless2.0，阿里云前几天推出Serverless，预留模式是对Serverless越来越重视的体现。本文主要介绍两个部分。首先是阿里最近的前端研发升级。为了扩展前端的边界和功能，我们尝试将其与Serverless结合起来。想着，希望能把传统应用快速迁移到Serverless系统上，享受Serverless带来的好处。目前阿里有大量的Node.js应用。1600+的数量让维护和治理非常麻烦。每次升级都需要很长时间才能实施，这对框架开发或平台治理都不利。很多Node.js应用都是BFF应用、内部平台等，这些应用大多处于低负载（低于10%）且常年无流量的状态，维护者也大多处于离职或闲置状态。这不仅浪费资源，也给治理带来困难。其次，集团内传统应用的开发，需要一个应用。整个研发流程比较长，业务需要了解预算和资源，涉及到很多细节。为此，我们启动了前端研发升级的大工程。整个前端研发模式的升级有两个目的，一是“前端赋能”，二是“前端效率提升”。所谓“前端赋能”，就是希望前端能够打破现有的技术壁垒，向更底层、面向数据的地方深入探索。其中，我们可以从面向UI的视图本身了解更多业务，从更全面的角度理解现有系统。“前端效率提升”是让Serverless以更轻量级的方式进行业务研发，降低整个前端参与业务交付的门槛。小步骤是可能的。然而，阿里巴巴的Serverless之路却十分艰难。与外界成熟的系统不同，公有云上开放的产品由于某些原因无法使用，阿里云也无法直接提供内部服务。同时，内部中间件对外不可用，都需要跨团队重建。Node.js基础团队的使命是为集团的Node.js生态提供各种基础能力，包括但不限于框架、中间件包等。在Serverless体系中，我们负责框架、工具链、runtime、release系统还需要与周边的网关、监控系统对接。收益从去年10月开始，我们开始对Serverless进行研究，了解相关知识。目前，我们已经取得了一定的阶段性成果。千万流量来自导购链接。同时，内部系统也进行了一定程度的serverless升级尝试，无论是改写还是传统的应用迁移，我们都有一定的沉淀。我们最初的目标是降低成本。按照在线Serverless的降本率来看，降本率可以达到90%以上。但是，导购业务比较特殊，流量比较大。与那些需要灵活性的应用不同，根据我们的计算，单进程机器的性能非常好，但由于在大促期间提前预留了一些资源，整体机器成本只降低到原来的70%。平时，非大促期间，不需要预留这些资源，可以下调到40%以下。现在都说DevOPS，而serverless最大的优势就是减少运维，减少固定服务器资源，不需要用户关心调度等等，还能简化开发代码，专注于逻辑，睡觉晚上会更安心，不再担心机器容量不足报警。另一方面，对于我们这些应用治理的人来说，之前考虑过各种版本碎片化问题，node多版本，framework多版本，启动脚本和依赖等问题。使用Serverless之后，我们就把这些都固化了，用户就不用关心了。一切都变得简单了，我们只需要管理一个版本的运行时。在前端业务方面，它带来了挑战和机遇。一方面，前端的工作量变大了，能做的事情也变多了。他已成为一名多功能通才，对业务有了更深入的了解。另一方面，传统的后端可以从与前端的通信中解放出来，更专注于提供服务。前端已经从传统的面向接口编程转变为面向服务编程。由于组内使用了RPC服务，所以RPC发布时会有固定的定义和文档，调用时有工具辅助制作代码，大大简化了调用环节。在流程方面，以前需要在各种环境下进行准备和研究。从一开始申请，申请预算，申请环境，需要了解各方面的知识，跟不同部门的人打交道，审批流程也很长。现在您只需要在我们统一的研发平台上直接申请功能组，就可以代替原来繁琐的流程，提升整个开发体验。同时编码时不再考虑路由和MVC。这些可以在网关层配置。写代码的时候，会更加注重逻辑。与之前的构建发布不同，现在增加了云集成测试的步骤。由于功能和前端代码一样，是分版本的，不用担心在线修改正常服务。测试完成后，只需要将旧函数的tag指向新函数，就完成了整个流切换过程，一旦遇到问题，将tag切换回来即可。这就是我们前端研发模式升级的思考和好处，给我们带来的不仅仅是变化，还有流程和思维上的创新。考虑到在升级研发模式的过程中，我们对现有的导购业务进行了重组。可以说以serverless的方式进行了重写。但是，如果对一些老应用进行整体改造，成本会非常高。大的。这时候开发者会有一个很普遍的问题：如何把我原来的应用迁移到serverless系统上？而我们的答案是二：用FaaS+Baas重构，代码更精简，但是需要改造成本，把整个传统应用当成一个函数，虽然不优雅，但是可以解决迁移问题。将整个应用迁移到函数中会有一些限制，会对代码结构和模型做一些微调，以符合整个Serverless结构。毕竟，新系统不同于传统的代码模型。阿里集团采用FaaS+BaaS的实现方式，FaaS的整体理念不同于传统应用。从概念上讲，Serverless比FaaS具有更广泛的扩展。FaaS是Serverless的一种实现方式。主要解决serverless自定义代码逻辑如何实现。也可以叫做ServerlessCompute，也是一种事件驱动的架构。某种。CNCFServerless白皮书也提到ServerlessCompute是一种更细粒度的部署模型，通过一个或多个功能响应用户需求。可以说，粒度小、灵活性高是它最大的特点。在代码层面，为了让用户更好的理解，我们对传统代码的结构进行了分解。传统的MVC类型的代码会被分成好几层。HTTP服务，原有的框架（koa/midway/egg...）、Node.js运行时、启动脚本等，将变成函数运行时，而原有的HTTPRouter、Web中间件等，将被HTTP固化gateway承接原来的Controller，业务逻辑（调用远程服务），继续保留，成为功能代码。原有的数据库、消息队列、RPC调用等，全部作为BaaS服务。用户只关心对应的服务，使用同一个BaaSClient调用这样分解后，我们对新旧系统的代码结构有了更深入的了解，可以开始尝试修改部分代码来成为真正的无服务器。传统应用迁移，会暴露一些外部服务供外部调用，比如HTTP、定时任务、RPC服务等，一般我们会将这些服务从目录中分离出来，与其他暴露的服务共享逻辑层代码。我们也常将这些服务称为“ingress”。在serverless（FaaS）的过程中，我们会将这些入口代码改成事件驱动的函数。我们使用构建机制在发布的时候生成不同的包，在共享一个逻辑代码的同时部署到不同的环境。该方案最大的优势在于复用了原有的逻辑部分，可以与传统应用同步开发。缺点也有，就是包依赖混在一起，而且由于函数对包大小有限制，可能会造成依赖过多等问题。HTTP相对于其他的要复杂很多，有很多局限性，这个我们在讲下游解决方案的时候会讲到。针对以上情况，我们对于下游的数据调用也有相应的解决方案。我们对这些解决方案有几个名称，例如代理模式和网关模式。?代理模式先来看看代理模式。传统的Web应用程序分为路由器/控制器和逻辑层。在代理模式下，我们会保留传统的应用，只将原有的逻辑层迁移到云函数上，暴露HTTP服务。这样做的好处是代码变得精简，改动适中，服务复用容易。缺点是作为代理层还是会占用一个应用资源。代理应用一般是通过HTTP客户端代理实现的，但是用户需要做一些额外的支持，让开发者在体验上感觉调用了远程服务。?网关模式第二种模式是网关模式。这种模式下，所有的代码都会迁移到新系统中，比较适合Web层比较简单的情况。在这种模式下，所有传统的WebRouter都会迁移到HTTPGateway，原有的路由、会话、认证等能力都由网关来控制，功能本身不需要关心这些，只需要关心数据。业界现有的FaaS模型大多都是这种结构，集团也采用这种结构进行实践。在这种模式下，原有的能力会遇到一些问题。我举几个例子：原来的Web中间件（koamiddlware）会不知道怎么处理。大多数中间件是拦截和消费请求流。这很多时候会被拆分成两部分，一部分由网关处理，另一部分只能交给函数自己处理。如果有分享的需求，也可以依赖模块完成原有的session维护。有些平台会透传cookies。这时候还是可以维护一个sessionId，同时使用第三方存储数据，但是如果网关不这样做，就会很麻烦。request对象和原来的不一样，因为函数获取的是event，context参数，或者原来的request对象和现有的koa等框架不太一致。以上方法可能都不行，会导致原代码被修改和挑战?Pretender模式那么有没有不修改代码的解决方案呢？我们尝试在函数外进行代码包装和数据模拟，让整个应用运行在函数之上，以“微应用”的方式持续存在。我们启动原始WebServer（midway/egg），在运行时通过固定端口转发，将FaaS请求参数包装成HTTPRequest对象，在出口处将HTTPResponse包装成functions可理解的形式延续传统应用通过这种延续方式。但是由于阿里云上的容器是只读不可写的，目前还不能直接使用这种模式。这种方式需要调整的是框架需要使用单进程模型（机器配置，轻量级要求），应用需要无状态（由功能机制决定），没有高耗操作比如长连接。综上所述，关于serverless的问题还是很多的，本文只介绍其中的一部分。从阿里的现状出发，分享了从去年到今年升级研发模式的做法，也介绍了我们的一些思考，传统的如何将应用迁移到FaaS系统。后续的整套方案也将在经历过双十一的洗礼和大流量的考验后，向大家开放。OneMoreThing淘喜科技部依托淘喜丰富的业务形态和海量用户数据，持续以科技驱动产品和业务创新，不断探索和衍生颠覆性的互联网新技术，以更智能、更友好、更普惠的技术深度重塑行业和用户体验，创造新业务。我们不断吸引用户增长、机器学习、视觉算法、音视频通信、数字媒体、移动技术、端到端智能等领域的全球顶尖专业人士加盟，让科技引领面向未来企业创新进步。请将简历发送至邮箱：ruoqi.zlj@taobao.com本文作者：陈中银（张婷）阅读原文本文为云栖社区原创内容，未经允许不得转载。
