写点什么

阿里自研开源框架 Midway Serverless ,如何让前端提效 50%?

2020 年 7 月 09 日

阿里自研开源框架 Midway Serverless ,如何让前端提效 50%?

去年开始,阿里前端及阿里的多个团队联合开始了一项“秘密”任务,使用 Serverless 这一新一代研发架构,希望能大量减少研发人员使用基础设施和运维的成本。目前这一框架已经实现前端提效 50%,且已在 Github 开源,开源地址见链接


Midway Serverless


Midway 之前是传统的 Web 栈框架,和业界现有的 EggJS,NestJS 等解决的是类似的问题,从中后台到移动端应用,前端都广泛采用了这些框架来构建自己的业务系统。阿里也不例外,Node.js 应用非常多,但是这些系统有一个共性,大多数服务器的 CPU 使用率非常低,这无疑是一种资源的巨大浪费。


这种资源浪费的常态以及应用的规模化几何倍数的增产,让应用治理的人员头疼不已。于是,阿里把目光转向 Serverless 架构,他们开始去思考,如何有效去减少研发人员使用基础设施的效率和运维的成本。



Serverless 和 FaaS


FaaS 是 Serverless 架构的其中一种形态,也是这次 Midway 希望解决的场景。在 Midway Serverless 1.0 之前,我们在 FaaS 上投入了许多,但是事实上,Serverless 架构非常庞大,FaaS 只是其中的一小部分,基于事件驱动的模型,从微服务(MicroService)这种专注于单一职责与功能的小型功能块演进而来。如今这种更加“代码碎片化”的软件架构范式,相比微服务更加细小的程序单元,给业务代码提供了无与伦比的灵活性。


按照《福布斯》杂志的统计,在商业和企业数据中心的典型服务器仅提供 5%~15% 的平均最大处理能力的输出,这无疑是一种资源的巨大浪费。而随着 Serverless 架构的出现,让服务提供商提供我们的计算能力最大限度满足实时需求,这将使我们能更有效地利用计算资源。


阿里目前使用了 FaaS 来作为业务的落地容器,希望能进一步减少容器的规格,降低成本。集团机器的成本当前是按 CPU Core 算的,以 4C8G(4 核 8G)的机器为例,一个中后台应用最少需要 2 台机器,而上了 FaaS,能减少到 1C,乃至 0.5C,这个成本下降的非常可观。


落地前端


在阿里“大中台小前台”的趋势下,前端是最接近用户且活力迸发的团队。前端一直希望能够有机会摆脱“资源”的困境,对整体工种的职能、边界有更广泛而清晰的拓展需求,造就了如今前端的范围不断衍生,从端侧到智能化,无一不是职能扩大的体现。


对前端开发者而言,Node.js 赋予了开疆拓土的能力,自前后端分离开始,从端到全栈,Node.js 已经成为前端学习的标配,而 DevOPS 的提出,也让前端逐步走向开发自治,运维自驱的路子。而阿里在实际实践中发现,大部分前端的确在朝着那个方向走,但是更多的是在业务和自治之间产生了一些迷惘,这两者的关系其实很不容易平衡,时间一久也会对业务的规模化产生一些影响。



而 Serverless 的出现,正好让前端有机会减少整个 OPS 环节,更加聚焦于业务本身;同时,由于整体的代码量减少以及轻量化开发理念、部署平台能力的增强,让整个业务的规模化成本越来越低。


之前,有人把 Serverless 比作前端的 3.0,这不无道理。Node.js 的轻量、快速已经得到了业界技术人员的广泛认可,在 Serverless 时代,容器的快速调度、代码的快速启动,都是非常重要的指标,而 Node.js 在这方面的优势非常明显。


前端提效 50%


这个数值在我们看来,Serverless 带来的效能变化的数值可能更大。其中分为规模化成本交付速度两个方面。


降低规模化成本


首先是服务器成本


从容器本身的角度来看,上文已经简单演算过,从传统容器到函数,整个容器资源从固定规格到更加细粒度的规格去逐步演进,这将更加符合场景的诉求。经过我们一年的跟踪,中后台应用的机器成本能降低 70% 以上,而实际移动端业务,也达到了 30% 左右。


其次是治理成本


越是大的公司,历史包袱越是严重,今年的阿里集团内部,还存留着 Node.js V6 乃至 V4 的代码。每年的 Node.js 版本升级、框架升级、库升级都要至少长达几个月,甚至几年。


而如今,函数运行时(Runtime)是前端自己编写的,我们可以将需要治理的 Node.js 版本、框架,乃至中间件都埋入其中,这就需要定制整个运行时及其通用化的能力。


阿里的内的函数服务有多种,提供了不一样的基建和网关服务。今天淘系前端能够使用一套代码部署在不同的平台之上,就得益于 Midway Sererless 底层的多平台适配能力。同时,这套代码的防腐层能力也正好能抹平社区的平台差异性。


针对每个平台,Midway Serverless 提供了不同的运行时启动器,用于抹平各个平台的差异,并且通过这些启动器,将各个平台的出入参,以及各个 event 结构,网关的返回格式进行规则化,让用户尽可能不感知底层容器以及协议的差异。



阿里通过这套方案,将一套代码部署在不同的函数服务之上,提供出不同协议的服务。所以到社区,阿里开源的方案也同样适用于多个平台,比如阿里云、腾讯云或者是未来的 AWS Lambda、Azure 等。


经过这层防腐和定制,整个运行时的更新变的简单,将传统应用需要半年起的版本推平工作,在短短一周内就完成了。举个例子,底层有个和平台的连接协议库有安全性漏洞,从接到安全报告开始,我们就需要做以下两件事,一是从平台数据拉取受影响的函数范围,给所有业务方进行了安全性邮件推送,并告知在一定时间之内不做主动申报的,将默认统一自动更新。二是在流量低谷期进行滚动更新,并以告知业务及时关注和测试。经过这样的流程,整个安全性更新在极短的时间内就统一处理完毕,这在以往的应用场景下,几乎是不可能的。



最后是安全生产成本,这块在阿里内部的诉求较大,但是中小型公司应该不多,这里就不再详述了。


通过这三块的管控和治理,使得在 Serverless 架构下,集团业务规模化成本极速降低。


交付速度


除了规模化成本外,另外一块就是业务交付的情况。前端面向的移动端和中后台两大场景都需要快速的交付,以现在的情况来看,前端依旧是研发的瓶颈,在使用了 Serverless 之后,原有的复杂流程已经无法满足现有的诉求。


去年我们团队在 GMTC 及 D2 分享中说过,前端自建了一套研发流程和平台,用于满足在新的场景的测试、灰度和回滚。整个研发流程,节点比以往更少,更容易聚焦。



而另一边,整个研发的效率,也有了不小的提升。


前端开发的效率,得益于前后端的融合,一体化开发和交付的速度。传统的前端研发,需要在前端仓库和 Node.js 端仓库多处进行开发,发布流程也是分离的。而在 Serverless 场景下,Midway Serverless 设计了一体化开发和发布的方案,这让前端能将业务在同一个仓库开发,同一个流程发布。特别是那些维护多业务的同学,感触会更深。


除了一体化的开发、调试,部署之外,从代码角度看,原有的编码习惯被保留,无需再度学习新的编程 API 也是一个方面。Midway Serverless 除了提供基于 TypeScript 和装饰器的编码风格之外,也提供了一些传统应用 Egg 应用迁移的方案,在不同的 BU 中也进行了落地尝试,效果非常不错。


经过一年我们在平台测的统计和业务开发方的走访,新的研发模式对业务整体的交付效率有一定的提升,这个提升是普适性的。


以前端完成需求为例,传统完成业务需求需要后端的介入以及联调,而新的研发模式在代码层面会开发更快,虽然单人来看工作量增加了,但是整体的交付时间,投入人员以及联调成本都有明显的降低。



除了业务感性的交付数据外,我们还统计了整体的研发代码量,提交的代码频次以及需求的迭代周期和发布。经过一年业务跟踪和数据的测算,我们得出整体前端人效的提升约为 48%,整个核心的算法牵扯到很对内部的数据,抱歉无法提供,欢迎大家入职观摩。


Serverless 的弊端


任何事物都有两面性。Serverless 优势固然的大,但是毕竟是新东西,特别是在企业中落地的时候,难免会遇到一些问题。


一是基建的缺失,传统的各种客户端、日系投递、链路追踪等能力都非常的完善,而函数这些新的事物还需要时间逐步沉淀,加上弹性容器的影响,整个链路都还是新生事物,需要时间去验证稳定性和可靠性。


二是业务同学的整体理念还是停留在传统应用的层面,对函数的运作机制,事件触发的行为了解不深,加上框架做了很多屏蔽的工作,很容易出现某些代码编写错误或者前期需求评估不到位,能力无法实现的情况。这些都需要慢慢的打磨,相信在不断的实践下,整体都会越变越好。


最后


我们可以看到,50% 的计算方式是一个相对感性的数字,但是 Serverless 在其中实实在在的体现出了它的魅力和价值。最后庆祝一下 Midway Serverless v1.0 发布。通过整个 Midway Serverless 新体系,我们将阿里的 Serverless 能力逐步开放,希望整个前端能有不同的思路去承担更大的业务职能,进入一个崭新的时代。


活动推荐


最近,由于疫情影响,我们准备了 QCon+ 线上体验,欢迎围观。


2020 年 7 月 09 日 13:012567

评论

发布
暂无评论
发现更多内容

Idea工程启动时报错:Command line is too long

玏佾

intellij-idea

国内10大前端团队网站

有思且行

技术 前端 大前端

Java中的Stream用还是不用

孙苏勇

Java 流计算 程序设计 性能

Fire Fast 再深一层的是什么?

树上

管理 考核 Fire Hire 用人

复用到何种程度

孙苏勇

Java 程序设计 复用 面向对象 抽象

如果明天没有恐惧——两小时看完余欢水后想到的……

伯薇

个人成长 心理学 小说 恐惧

机房运维需要了解东西

Spider man

给业务线的总经理多交代了几句

泰稳@极客邦科技

创业 效率 团队管理

Windows环境MySql8.0忘记root密码重置

玏佾

MySQL

过滤数组中重复元素,你知道最优方案吗?

麦叔

数据结构 数组 数组去重

【SpringBoot】为什么我的 CommandLineRunner 不 run ?

遇见

Java Spring Boot

关于HSTS - 强制浏览器使用HTTPS与服务器创建连接

遇见

https 安全 浏览器 TLS 证书

太慢是不行的

池建强

创业 产品

像黑客一样思考

Fooying

黑客思维 黑客 安全攻防

当我们在说5G网络安全的时候,究竟在说什么?

石君

5G 5G网络安全 5G安全 网络安全

常用手机软件清单

彭宏豪95

效率工具 App 手机 移动应用

公司大了,人多事杂,如何落地项目制?

树上

项目制 落地 公司管理 业务线 考核

一个值得推荐的人才测量标准

Selina

dubbo-go 中如何实现路由策略功能

joe

golang Apache 开源 微服务架构 dubbo

Nginx代理Oracle数据库连接

遇见

MySQL nginx oracle 反向代理

如何画一个闹钟

池建强

视觉笔记

媒体的经营 01 | 媒体/内容行业投资分析的维度

邓瑞恒Ryan

创业 内容 重新理解创业 媒体 投资

回"疫"录(1):口罩危机也许是一种进步

小天同学

疫情 回忆录 现实纪录

像经营咖啡店一样扩容 Web 系统

Rayjun

Web 扩容

死磕Java并发编程(3):volatile关键字不了解的赶紧看看

七哥爱编程

Java Java并发 volatile

个人知识管理精进指南

非著名程序员

学习 读书笔记 知识管理 认知提升

用python爬虫保存美国农业部网站上的水果图片

遇见

Python GitHub 爬虫

【SpringBoot】给你的 CommandLineRunner 排个序

遇见

Java Spring Boot

我敢说 80% 的程序员都掉进了「老鼠赛跑」的陷阱

非著名程序员

读书笔记 程序员 程序人生 提升认知

程序员陪娃看绘本之启示

孙苏勇

生活 程序员人生 读书 成长 陪伴

【SpringBoot】为什么我的定时任务不执行?

遇见

Java Spring Boot 定时任务 debug

NLP领域的2020年大事记及2021展望

NLP领域的2020年大事记及2021展望

阿里自研开源框架 Midway Serverless ,如何让前端提效 50%?-InfoQ