迈入现代 Web 开发

独家号 数据淘金 原文链接

前言:7月4日,字节跳动Web开发引擎负责人杨扬(dexteryy)在 GMTC 全球大前端技术大会(北京站)2021 上又搞了一场「跨年演讲」(内容超多的意思),不但现场爆满、超时严重,而且一如既往的讲完之后只要把讲稿和幻灯片拼起来就能发出来,大家可按需取用。
亮点:为了方便大家理解,杨扬(dexteryy)同学为这次分享画了 90 张图(工具是 Keynote),其实在内部版《Modern Web Stack》里有 120 多张图…



大家好,我是来自字节跳动 Web Infra 部门的杨扬。在开始分享前先解释下:


可以看到幻灯片上的标题,跟会议日程里的标题有些不一样,「现代 Web 开发」这几个字加上了引号,做这个修改是因为,原文很容易被断句成「现代的,Web 开发实践」,「现代」看上去只是一个普通的形容词,其实「现代 Web 开发」是作为一个整体的专有名词,来代指现在全球技术社区和全行业里,越来越重要的一个「大趋势」(Megatrend)、一场正在进行中的「范式转移」。


今天这场分享的主题,就是字节跳动如何把「现代 Web 开发」转化成具体的技术栈和研发工具体系,在内部广泛落地和从中获益。



这次分享的内容可以分成三个部分。


第一部分,先整体回顾「传统 Web 开发」范式中的「前端开发」技术和工程体系,有哪些瓶颈问题。


第二部分,对于在这些问题的背后、在这些问题的驱动下,正在发生的转变,做一下归纳和比较。


第三部分,介绍字节跳动在落地和推动这种转变中,发展和建设出的技术体系。对于字节这个「App 工厂」来说,这种发展相当于一场「引擎升级」的过程。



大家都知道字节跳动在业界有一个既含贬义也含褒义的外号,叫作「App 工厂」,如果我们从软件研发的角度来看待这个外号,那其实在字节内部,各种产品、工具、软件应用的开发,比大家从外部看到的更像「App 工厂」:无论数量还是多样性,形态和场景的丰富度,都是非常高、海量的。


而这些软件项目中,基于 Web 技术、前端技术的,占了大部分(这并不是因为字节有特殊的技术选型,而是行业的大背景和必然规律,我在19年一次关于「现代 Web 开发」的分享里有介绍过)。


由于字节有这种特点,所以前端技术和工程体系中的问题和瓶颈,在字节会体现的很全面、很典型,很多时候也会体现的更明显。


现代 Web 开发的现状与未来:https://zhuanlan.zhihu.com/p/88616149



传统的前端技术体系,无论在字节内部,还是在全行业,都可以总结为图上这个样子。


图中从下到上,代表抽象层从底层到顶层。最右边三个方块,都从最下面延伸到了最上面,代表它们都是端到端的解决方案,跟左边的体系,以及彼此之间,都是割裂的,包含大量重复,这次分享因为时间关系,不讲这几个部分。


蓝色的方块都是代码层面的,绿色的方块都是平台层面的。


这套体系是字节曾经的主流,是从业务中自然发展出来的,但随着这种发展趋于停滞,这套技术栈正在同样自然的演变成历史遗留的「祖传技术栈」,其中每个部分都有比较大的瓶颈问题。




我们逐个看一下图里的每个问题域,首先是大家最熟悉的「前端脚手架」。




不管哪种形式的脚手架,本质都是复制粘贴一堆样板代码,组成新的项目。


虽然跟建筑行业使用的脚手架一样,都是在搭建过程中使用,用完就放到一边,只留下搭完的项目。但建筑脚手架拆掉之后留下的建筑,有一套不能动的钢筋混凝土骨架,而脚手架生成的前端项目,是混杂在一起的样板代码,虽然有文件结构,但可以随意修改,而且因为基建和示例代码混在一起,所以不仅是「可以改」,而且经常是「必须改」样板文件的内容和结构,才能完成真实项目的完整搭建。



假设一个脚手架包含 A、B、C 三块功能,用这个脚手架创建出的三个项目,最初都是一样的,也都包含 A、B、C 功能。



接下来,三个项目必然需要在脚手架的生成结果上,做各种增删改,可能是因为业务需求,也可能是因为技术沉淀和工程改进。时间长了之后,三个项目之间会差别非常大,如果要做统一的改进,或者把一个项目的沉淀和改进,应用到另一个项目里,都会很困难。有时甚至要推迟需求开发,先对这些项目做一轮统一的重构,但这也只能应付眼下,之后这些项目仍然会继续分裂和腐化。


另一方面,脚手架本身也在迭代改进,但因为脚手架是一次性的,一用即抛,这些改进不能对原先创建的项目带来好处,引入这些改进的成本,跟从其他项目里引入改进的成本差不多。



进一步看看脚手架中「项目模板」的问题。



脚手架的必然结果,是需要各种项目模板。不但脚手架建设者需要提供多种模板,覆盖不同的需求,使用者也经常需要复制原有模板,修改成新的模板,比如产品的技术形态是 SPA 还是 MPA,都会产生不同的模板。


图上每个方块,都代表一个真实存在的模板,可以看到这些模板中有大量重复、又不会完全相同的内容,升级维护模板、在模板之间同步技术沉淀,都有成本。很多模板会缺少更新,长期停滞,把成本留给搭建项目的人。



如果从项目场景的角度出发来设计和维护模板,也有相同的问题。图中的方块是一些最基础、最典型的场景,和场景中的技术需求,可以看到,不同场景之间的技术需求,重合度很高。



除了场景类型,一个项目还有很多类型维度,图中的每个方块,代表一种维度,比如按照图上的第三种维度,不同项目之间仅仅因为「组件库」和「设计系统」不同,就要设计和建设不同的模板。


这些维度之间的排列组合,要么会导致模板进一步分裂和数量爆炸,每种模板的维护成本更高,应用场景更小,ROI 因此变低,更加倾向于停滞;要么会导致模板对很多维度中的需求,不做考虑,只覆盖小部分需求,对项目开发的支持,局限在比较低的水平。



「传统技术栈」的第三个问题域,来自前端工程化建设中常见的对 Webpack 的「包装」。



为了避免每个前端开发者都成为「Webpack 工程师」, 很多脚手架、工程化建设,都会对 Webpack 做图上这样的包装,在最上层,提供围绕编译构建的两个命令 dev 和 build,搞出不同「规范」的配置文件和插件机制。



这种包装的第一个问题,是抽象程度很有限,配置 API 的设计也五花八门,体现不同的个人偏好和业务经验,这种配置虽然被称作「规范」,但在真实业务项目中存在感不高,业务项目还是要直接靠 Webpack 来解决很多问题,项目中包含很多 webpack 配置,脚手架模板也包含大量相关的样板代码,避免不了前面说的问题。


图中这段话来自 Redux 作者 Dan 写的一篇文章,讲 JS 工具的配置 API 的设计,这段话就是在讲这方面的抽象和设计能带来巨大的影响,有很高的门槛,需要非常严肃专业的对待,这种工作也需要高度的集中,而不是交给「Webpack 工程师」们搞各种各样的「规范」。


* The melting pot of JavaScript: https://increment.com/development/the-melting-pot-of-javascript/



业务项目深度依赖 Webpack、包含很多 Webpack 配置,还带来另一个问题:


JS 开发工具从去年开始又出现新一轮更新换代的征兆,有人把这种趋势称作 「JS 的第三纪元」,新范式的项目涌现,开始进入到日常业务的开发实践,很多场景下已经没有 Webpack。


* The Third Age of JavaScript: https://www.swyx.io/writing/js-third-age



图中右侧的 esbuild 和 swc 这样的构建工具,把编译、构建、打包、压缩等在 Webpack 里属于不同环节的部分,合并在一起,加上非 JS 的系统编程语言的帮助,大幅提升构建速度。另一方面,也能支持 ESM 优先的、不需要打包的构建场景。


Snowpack、Vite 这样的工具,在此基础上实现了开发者体验(DX)优先的、不打包(Unbundled)的开发调试模式。


这些工具和模式跟 Webpack 的设计有一些本质矛盾,目前已经被用于公共库的构建、业务项目的开发调试等真实场景里。



基于 Webpack 包装的工程化建设,第三个问题是:对项目开发的工程支持只停留在比较低的水平,比如就像 dev 和 build 命令一样,局限于跟编译构建有关的环节。


而随着行业和业务的发展,随着前端技术的发展,一个前端工程的完整需求,就像图中一样,会包含蓝色方块代表的整个研发链路的每个环节,以及每个环节下面,绿色方块代表的工程需求。这些都超出了 Webpack 的能力范围。



刚才说的这个问题,其实也是传统前端工程化建设本身的问题。



传统的工程化建设,就像图中文字说的,只能实现「代码层面」的基础建设,在创建项目的时候,做的事情大部分都属于「代码初始化」。



现代的 web 工程和前端工程,越来越多的包含「代码层面」之外的「平台层面」。


图中绿色方块代表的,是靠「代码层面」来实现工程需求,橙色方块代表的,是要靠「平台层面」才能更好实现的需求。



第五个问题域是,很多前端开发场景,比如像字节内部的前端开发,都在统一收敛到 React 技术栈,但 React 本身也是有局限的。



在 Web Infra 部门建立之前,字节内部的业务方向,比如今日头条和抖音,就已经在推进统一到 React 技术栈,目前字节的现代 Web 研发体系建设,也有意收敛和围绕着 React 来进行。


选择 React 的原因可以归纳为图上这四个,其中,符合技术趋势,设计演进更快,走在最前面,这两点让 React 在基础建设中,在有基础建设团队支持的业务场景中,都具备很大的优势。



图上高亮的这句话,很好的表达了 React 引领业界和社区发展的特点。



刚才在选择 React 的原因里,还提到 React 庞大的生态红利或验证规模。图中可以看到,在比较贴近实际使用情况的依赖下载数据里,React 在绝对数量遥遥领先的情况下,增长势头也是更快的,React 生态下的 CRA、Next.js,单独拿出来都达到或接近其他非 React 技术的使用量。


* https://www.npmtrends.com/@babel/[email protected]/cli-shared-utils-vs-next-vs-nuxt-vs-react-vs-react-scripts-vs-vue-vs-vue-loader-vs-vite



这种生态和规模上的差距,在国内环境中也回避不了,国内 JS 开发者的数量差不多是球的十分之一,所以单靠国内开发者,影响不了整个行业和技术社区的生态和基建,导致在业务支持和工程建设中,React 目前都无法取代


* 「全球的 JS 开发者已经上千万了」:https://zhuanlan.zhihu.com/p/111204309



但在工程体系中只靠 React 自己是远远不够的,React 本身只解决视图层的问题,距离一个 Web 框架还缺很多东西,在框架层面上,React 是无偏见的,比如没有限制路由实现、组件类型、SSR 解决方案等,也没提供默认的配置和工具体系,跟一个真正框架的必备要素,是完全相反的。


* Advancing the web framework ecosystem (Chrome Dev Summit 2019): https://youtu.be/QDljY2I1Pfw



由于 Webpack、React 都不解决全链路的问题,缺乏框架级别的解决方案,很多前端项目会把目光转向发展时间更长、已经形成框架级别基建的服务器端框架领域,但这方面的 Node.js 框架,也有瓶颈问题。



业界主流的 Node.js 框架 NestJS 的作者,在文档首页的设计理念部分,就指出 React、Vue、各种开发工具,都没有解决「应用架构」的问题,而 NestJS 就是要提供开箱即用的应用架构。


传统的前端开发局限于视图层,跟完整的软件开发、产品开发相比,最缺的就是「应用架构」。


* NestJS Philosophy: https://docs.nestjs.com/#philosophy



但是 Node.js 框架能提供的,只是「服务器端应用架构」,是以服务器端开发为中心的。


有些情况下,比如活动页面,客户端部分本来就很薄,谈不上「客户端应用架构」,但这种情况下的业务关注点仍然在客户端部分,如果基于有完整服务器端应用架构的 Node.js 框架去开发这种项目,对前端开发者来说有些偏离重点。


在另一些情况下,客户端部分比较厚,这种情况下需要的「客户端应用架构」,就像图中右边的蓝色部分,跟左边代表「服务器端应用架构」的橙色部分,是完全不同的,如果使用 Node.js 框架,蓝色部分仍然需要自己摸索和搭建。



不管什么软件架构,核心都是「分层」和「关注点分离」,完善的现代 Web 工程里,「服务器端应用架构」和「客户端应用架构」不会割裂,而是混为一体的。


* The Clean Architecture: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html



除了架构,Node.js 框架也解决不了前面说的其他问题,同时还引入了图中右边的新问题:


业务逻辑既分散割裂,同时又重复,导致项目变得「低内聚高耦合」。


在「前后端分离」之后从「后端项目」里独立出来的「前端项目」,使用 Node.js 框架之后,又混入了很重的后端业务逻辑和研发需求。而 Node.js 框架随着发展,本质也越来越清楚:还是服务于专业服务器端开发的,降低不了前端开发者的服务器端开发门槛,这是一个最大的瓶颈。



从这张图可以看到,包含服务器端部分的「前端项目」,并不是真正的「全栈」,只是包含了服务器端最上面的、很薄的一层,解决 Web 和 BFF 需求(注意这里说的 Web 是指处理 HTML 请求,而 BFF 这个词在国内有很多误用,实际上是专指面向特定 UI 的 API 服务)


对于前端项目里的这些服务器端需求,用 Node.js 框架来开发,很多时候带来的问题比解决的问题更多。


* The BFF Pattern (Backend for Frontend): An Introduction: https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf



最后,看下最底层的 IaaS 和 PaaS 部分。



传统云计算中的 IaaS 和 PaaS,就像图中的绿色部分,从最底层到最上层,有这样几层,最上面这层,有不同的平台和服务形态,传统上,前端项目跟后端项目一样,直接部署这一层上,比如字节内部后端技术栈的项目,都部署在被称作 TCE 的 PaaS 上,而前端技术栈的项目,以前也只能这样部署。


* 《容器云在头条的落地和实践》:https://time.geekbang.org/dailylesson/detail/100016772



但是在这种 PaaS 上或直接在 IaaS 上做部署和运维,对前端开发者来说,不但复杂低效,而且在很多前端部署需求上,没有获得任何支持。


比如图中粉色部分中这些前端部署方面的通用需求。由于 IaaS 和 PaaS 都源自后端开发场景,是后端研发技术的平台化沉淀,设计和演进都天然的受到局限,对前端研发场景缺乏理解,就算理解,也无法在相同的基础设施里去兼顾这些前端部署需求。



也就是说,多数前端项目和底层的 IaaS 和 PaaS 之间,存在一大片空白,也就是图中粉色的区域。


在真实业务中,为了避免每个前端项目都直接跟 IaaS 和 PaaS 打交道,很多业务都会有意无意的做一些集中建设,填补这片空白。


比如字节的一些 web app 项目,会由后端负责的 go server 来运行。


很多有 SSR 需求的业务,会搞一个统一的 SSR server 项目,在开发各种前端仓库的时候,需要本地有 SSR server 的仓库,才能运行和调试这些前端项目。



像这样的集中建设,要么把前端项目中的正常组成部分,放到了前端开发者无法掌控的地方;要么反复重复的建设出被业务需求扭曲的部署方案,难以沉淀和演进,最大化的提效。


所以图中粉色这片区域的空缺,该由什么来填补,是传统前端技术栈里的一个大问题。



回顾了「祖传技术栈」的这些问题,接下来我们看下在这些问题的驱动下,业界和技术社区里已经形成的趋势,这些趋势带来的发展和优势,也反过来,让前面说的这些问题变得更明显,更急需解决。



这种趋势可以归纳为「传统 Web 开发」范式到「现代 Web 开发」范式的转变。我在图中这两次技术活动上,分别介绍过「现代 Web 开发」范式的起源、背景和发展状态,这里不再重复了。


* 现代 Web 开发的现状与未来(JSDC 2019 演讲全文): 

https://zhuanlan.zhihu.com/p/88616149


* 理解现代 Web 开发(JSConf China 2017):

https://youtu.be/515pkXWHgnE
https://2017.jsconfchina.com/files/02-modern-web-dev-dexteryy.pdf



这种转变,可以称得上是一场「范式转移」,原有的理解和习以为常的假设被打破,在原有的东西上小修小补解决不了问题,需要建一套新的东西,做出根本性的变化。


图中左边蓝色部分是最能代表「传统 Web 开发」的一些技术栈和规范,右边橙色部分是在「现代 Web 开发」趋势下出现的技术栈和技术形态,接下来把它们展开看看包含哪些要素,就会看到左边的东西跟右边的东西,差别非常大。


* 「范式转移」:https://wiki.mbalib.com/wiki/%E8%8C%83%E5%BC%8F%E8%BD%AC%E6%8D%A2



Ruby on Rails 是「传统 Web 开发」范式的一个典型代表, 本质上是以服务器端开发为中心的、MVC 架构的「服务器端 Web 框架」,就像图上右边这样,产出网页和 API。


网页部分需要的前端代码和工程化,一般包含在同一个仓库里,框架本身也会内置一些前端相关的工程化,经常会需要被专业全面的前端工程化替代掉。


* The Asset Pipeline: https://guides.rubyonrails.org/asset_pipeline.html

* Hotwire: https://github.com/hotwired/hotwire-rails



「十二要素应用宣言」本质上是一种工程标准,是进入云计算时代之后,服务器端应用和工程项目中形成的规范,这套标准可以保证应用能很好的运行在「后端 PaaS」或其他的传统云计算平台上。 


可以看到,在 Node.js 帮助下形成的前端工程规范,不管有没有服务器端代码,也都受到了这个规范很大影响。


* The Twelve-Factors App: https://12factor.net/



MERN 技术栈,是前端代码和工程,从其他技术栈的服务器端框架中「分离」出来之后,又融合相同技术栈的服务器端框架,形成的「全栈」开发方案。


组成 MERN 的 4 个首字母,能体现这套技术栈的本质,也就是图上右边的 4 个组成要素,整体上还是以服务器端的研发方式、应用架构、平台基建为中心的。


* MERN Stack: https://www.mongodb.com/mern-stack



在「现代 Web 开发」趋势下,在国外被称作「JAMstack」的技术栈,变得越来越清晰和主流。它还有另一种命名建议是图中第二行的「SHAMstack」。


这两个缩写的首字母组合虽然不同,但就像图中的推导结果,本质是一样的,都是由 4 个要素组成。


* JAMstack: https://jamstack.org/


* SHAMstack: https://css-tricks.com/jamstack-more-like-shamstack/


* "Content Mesh": https://www.gatsbyjs.com/blog/2018-10-04-journey-to-the-content-mesh/



再展开看这 4 个要素。


跟刚才说的 MERN 技术栈比较,Serverless 模式和基建取代了 M 代表的传统后端基建;前端应用的构建产物 、 服务器端渲染、静态网站生成、前端程序中的 BFF、等等,取代了 E 代表的服务器端 Web 框架和服务器端代码。


这种技术栈的项目仍然是「全栈」的 Web 项目,但变成以客户端研发方式、客户端应用架构为中心,看上去很像是纯静态的、纯前端的项目。


* ooooops I guess we’re* full-stack developers now: https://css-tricks.com/ooooops-i-guess-were-full-stack-developers-now/



还有人归纳了这种叫「STAR」的技术栈,本质上是图中右边这4个要素组成。


同一个现代 Web 项目,可以同时符合 JAMstack 和 STAR,JAMstack 强调的是前后端架构和开发范式,STAR 强调的是专业的编程方式。


特别要注意的是,STAR 其实体现了一个现代 Web 项目中的「前端工程化」,除了编译环节,也需要 Runtime 环节和代码编写环节的支持,除了视图层,也需要完整的应用架构和 Model 层的支持。


* STAR Apps: A New Generation of Front-End Tooling for Development Workflow: https://css-tricks.com/star-apps-a-new-generation-of-front-end-tooling-for-development-workflows/



在「现代 Web 开发」趋势下,国外技术社区里越来越多的提到 meta-framework,本质上是把 JAMstack 和 STAR 强调的部分加起来,用以客户端为中心的、包含更上层抽象的、通用的 Web 框架的形式,整体系统的满足这些需求,抽象、简化这里面的各种模式。


在「现代 Web 开发」里,这种 meta-framework 是更合适的基础抽象层,取代了以脚手架和构建工具为代表的更原始的基础。



「S 型曲线」是一种事物「发展成长规律」的表示方法,这张 JS 框架的 S 型曲线图,很好的表达了 meta-framework 在 JS 技术发展中的意义。


在图中左侧的早期阶段,各种 UI 框架在行业和技术社区里不断涌现,包含各种各样的尝试和破坏性创新,随着发展,UI 框架不再是快速发展的前沿了,选择也不再那么多,技术发展逐渐稳定和收敛成了基于 React 做上层的整合和框架建设,这种框架变成了新的发展前沿,也产生了大量选择,同时作为更成熟的技术,以更快的速度被采纳使用,之后又逐渐稳定和收敛,形成主流技术。


* React Distros and The Deployment Age of JavaScript Frameworks: https://www.swyx.io/react-distros/



比较了「传统 Web 开发」和「现代 Web 开发」中的不同现象,最后我们来归纳和定义一下这两种范式的本质特征和组成要素。



从框架和 UI 的角度来看,「传统 Web 开发」是以服务器端框架为中心来做全栈开发,客户端是围绕 HTML 和对象树的编程范式。


「现代 Web 开发」是以新一代客户端框架为中心来做全栈开发,客户端同样围绕专业、通用的软件开发语言和编程范式。



从架构的角度来看,「传统 Web 开发」中存在两套比较独立和欠缺融合的程序,「前后端分离」改善了分工协作,但对于分离出来的「前端技术栈的 Web 项目」,在架构和开发范式上没有真正实现「分离」,前端开发者需要跟服务器代码打交道。


「现代 Web 开发」实现了在同一套程序里一体化开发,在开发、调试、运行、部署等环节都能做到「无服务器化」,让前端技术栈的开发者更容易成为真正的「产品开发者」。



从抽象的角度来看,「传统 Web 开发」中前端部分的基础抽象是原始、初级的,比如脚手架、样板代码、基本的 Webpack 包装和 CLI 工具、React 和 JS 生态中的海量选择,很有「前端特色」,跟成熟的软件开发有显著差距。图中的 DX 是指开发者自身的效率,UX 是指开发出的应用的能力和质量,传统范式中的抽象太原始,导致 DX 和 UX 没法同时提升,提升其中一个,就会损害另一个。


「现代 Web 开发」中有了一体化的、更成熟的、框架级别的基础抽象,能同时追求和确保 DX 和 UX 的最大化。


* What Is DX? (Developer Experience): https://medium.com/swlh/what-is-dx-developer-experience-401a0e44a9d9

* What is developer experience?: https://www.tiny.cloud/blog/developer-experience/



从部署的角度来看,「传统 Web 开发」的项目,要么纯静态托管,要么作为服务器端应用来部署和运维。不同部署方式,会导致整个工程都不同,需要不同的脚手架模板。


「现代 Web 开发」的项目有更多样强大的运行和部署方式,但在 meta-framework 的支持下,项目模板的变化变少了,申请有机会完全融合、收敛成一个模板,成为「Universal App」。


* "SPR": https://vercel.com/blog/serverless-pre-rendering


* "SSG": https://www.freecodecamp.org/news/static-site-generation-with-nextjs/


* "ISG": https://www.smashingmagazine.com/2021/04/incremental-static-regeneration-nextjs/


* "Micro Frontend": https://micro-frontends.org/



最后,从平台角度来看,「传统 Web 开发」基于后端的云基础设施,由于代码层面缺乏抽象,客户端代码的复杂性容易停留在很基础的程度,有些时候会干脆直接改成 JSON 之类的配置。


「现代 Web 开发」基于新一代 Serverless 平台。在 Serverless 的支持下,能实现以前难以实用化的云研发。由于代码层面有统一的、上层的抽象,在开发中能引入更多低代码模式。



针对这些问题和趋势背景,字节在起步比较晚的 Web Infra 建设中,主动发展和建设了整套「现代 Web 技术栈」的研发体系,建立了「MWA」 —— 也就是「现代 Web 应用」—— 这种工程标准,形成了新一代「研发引擎」,支持了大量、多样的真实业务项目。



之前第一部分里我们讲了前端的「传统技术栈」是图上这样子。



可以看到「现代 Web 技术栈」的这张图,发生了非常大的变化,所以说这种转变是一场「范式转移」。


有几个需要注意的变化是:


图中绿色代表的平台化基建,占比超过蓝色代表的纯代码层面的基建。


没有割裂,中间的研发平台建立在「前端云」之上,工程框架基于研发平台支持研发全链路,右边的工程方案跨越上中下三层,是指可以通过工程方案,定制左边这三层的需求。



这套技术栈在字节内部,是一套被称作「Goofy」的研发体系,可以看到图中有多个名字里 Goofy 开头的产品,既可以整体使用获得更多高级能力,也可以单独使用,其中最早推出、应用最广泛的,就是最下层的「前端部署平台」,提供了 Serverless 的「前端云」模式,明天下午有一场分享是专门介绍这个部分的。


这次分享以图中蓝色部分代表的代码层为主,这个部分的解决方案,形成了一套被称作 Jupiter 的研发框架。