本文是阿里巴巴前端技术专家-张挺,在 JSConf China 「中国开发者大会」上分享的《面向传统,Serverless 进化之路》,主要讲述阿里集团内部逐步迁移到 Serverless 体系的过程以及思考。
01 背景
自 GMTC 以来,国内各个公司在 Serverless 投入都有所变化,腾讯和阿里云都铆足了劲在上面发力,提出了各自的解决方案,腾讯推出了 Serverless 2.0,以及几天前阿里云推出的预留模式,都是对 Serverless 越来越重视的表现。
本文主要介绍两部分,第一是阿里在近期做的前端研发升级,为拓展前端的边界和职能,尝试做了一次和 Serverless 结合,第二是在这其中,我们尝试对现有的体系做了思考,希望能将传统应用快速迁移到 Serverless 体系,享受到 Serverless 红利。
02 现状
阿里的 Node.js 应用非常多,1600+ 的数量让维护和治理都变的很麻烦,每一次升级都要推行很久,这不管对框架开发还是平台治理都是不利的。
很多 Node.js 应用都是 BFF 应用,内部平台等,这些应用常年大多都处在负载低(10%以下),没有流量的状态,而且维护者大多处在离职或者不积极的状态,一方面造成了资源浪费,另一方面也给治理造成了困难。
其次,在集团开发传统应用,需要申请,整个研发流程比较长,需要业务了解预算和资源,牵扯到很多细节。
为此,我们开始了 前端研发升级 这个大项目。
整个前端研发模式升级的目的有两个,一是为了“前端赋能”,二是为了“前端提效”。
所谓的“前端赋能”,是因为我们希望前端能够打破现有的技术壁垒,朝着更底层,面向数据的地方去深入探索,在这之中可以从面向 UI,视图本身变的更加了解业务,从更面全面的视角来理解现有的体系。
而“前端提效”,则是希望让 Serverless,用更轻量化的方式进行业务研发,降低整个前端参与业务交付的门槛,同时,在开发期间,也能减少人力总成本,让前端减负,业务小步快跑成为可能。
但是阿里的 Serverless 之路非常困难,不像外界已经有成熟的体系,目前一些原因无法使用公有云上开放的产品,阿里云也无法直接对内部提供服务,同时,内部的中间件在外部都没有,都需要跨团队来重新建设。
Node.js 基础团队的使命,就是为集团 Node.js 生态提供各种基础能力,包括但不限于框架,中间件包等,而在 Serverless 体系中,我们要负责框架、工具链、运行时、发布系统,同时也需要和周边的网关,监控系统等对接。
03 收益
去年 10 月开始,我们开始进行调研 Serverless 以及了解相关知识,到现在为止,也已经取得了一定的阶段性成果,将淘宝和飞猪两道 BU 的导购链路整个迁移到了 Serverless 体系,并且承载了导购链路的千万级流量。
同时,内部系统也进行了一定程度的 Serverless 升级尝试,不管是重写还是传统应用迁移,我们都有了一定的沉淀。
我们最初的目的是希望能降低成本,按照网上 Serverless 的降低成本率能达到 90% 以上,不过导购业务比较特殊,流量比较大,不像那些需要弹性的应用,根据我们的测算,单进程下函数的性能非常不错,但是由于大促要提前预留一些资源,整体机器成本只降低到了平时的 70%,而在非大促期间,不需要预留这些资源,就能更低,降到 40% 以下。
现在都说 DevOPS,而 Serverless 最大的好处是减少运维,减少固定服务器资源,不需要用户关心调度等,同时也简化了开发的代码,专注了逻辑,晚上睡觉会更加的放心,不再担心机器容量不足而报警。
另一边,对于我们应用治理的人来说,之前会考虑各种版本碎片化的问题,node 的多版本,框架的多版本,以及启动脚本、依赖等等问题,而使用 Serverless
之后,我们将这些都固化了,用户也不关心这些,一切都变的简单了,我们也只需要治理运行时一个版本即可。
在业务前端方面,带来的是挑战和机遇,一方面,前端的工作量增大了,能干的事情也变多了,成了一职多能的多面手,也更了解业务了,另一方面,传统的后端可以从和前端沟通中解放出来,更专注于提供服务。前端从传统的面向接口编程变成了面向服务编程,由于集团内都是 RPC 服务,在 RPC 发布时会有固定的定义和文档,在调用时有工具辅助生产代码,大大简化了调用链路。
在流程方面,原来需要在各个环境准备和调研,从一开始申请应用,申请预算,申请环境开始,需要了解各个方面的知识,和不同部门的人打交道,流程审批也很长,而现在只需要在我们的统一研发平台上直接申请函数组,替代了原本的复杂流程,也提升了整个开发体验。
同时在编码中也不再考虑路由,MVC 的事情,这些在网关层配置就好,编写代码时会更关注逻辑,和之前的构建发布不同的是,现在增加了云端集成测试的步骤,由于函数和前端代码一样,是分版本的,也不担心修改到线上的正常服务,在测试完毕后,只需要将旧函数的 tag 指向新函数即可,这就完成了整个切流的过程,而一旦碰到问题,把 tag 切回去就行。
这就是我们前端研发模式升级的思考和收益,带给我们的不仅仅是变化,更多的是流程、思维的革新。
本文转载自淘系技术公众号。
原文链接:https://mp.weixin.qq.com/s/L7z0S5Oeg9Wtxqhh0c5AAw
评论