作者|陈仲寅（张挺）出品|阿里巴巴新零售淘系技能部
本文是阿里巴巴前端技能专家-张挺，在 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 体系下的办法。后续的整套方案也会在经由双十一的洗礼，大流量的磨练后，开放给大家。
作者：陈仲寅（张挺）
本文为云栖社区原创内容，未经许可不得转载。
