本文是阿里巴巴前端技术专家 - 张挺，在 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 切回去就行。
这就是我们前端研发模式升级的思考和收益，带给我们的不仅仅是变化，更多的是流程、思维的革新。
本文转载自淘系技术公众号。
评论