Serverless 背景下的前端困境与解决方案

本文涉及的产品
函数计算FC,每月15万CU 3个月
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
简介: 回顾 2018 年的前端届,笔者看到的是 PWA、SSR、AMP、Web Component & Polymer、GraphQL 等半生不熟的技术,其中最有创新点的大概就是 Truffle(区块链)和 TFJS(TensorFlow.js)了。到了 2019 年 ,当数 Serverless 的发展最为迅速。那么,当下去分析 Serverless 背景下的前端困境就显得尤为重要——从自身痛点出发,才能更好地赋能前端。本文将从 Serverless 背景下的前端困境入手分析,结合具体的技术点,最后给出解决方案相关的建议。

Serverless 专场.png

回顾 2018 年的前端届,笔者看到的是 PWA、SSR、AMP、Web Component & Polymer、GraphQL 等半生不熟的技术,其中最有创新点的大概就是 Truffle(区块链)和 TFJS(TensorFlow.js)了。

到了 2019 年 ,当数 Serverless 的发展最为迅速。那么,当下去分析 Serverless 背景下的前端困境就显得尤为重要——从自身痛点出发,才能更好地赋能前端。

本文将从 Serverless 背景下的前端困境入手分析,结合具体的技术点,最后给出解决方案相关的建议。

Serverless 背景下的前端困境

国内各个公司在 Serverless 投入很大,腾讯和阿里云都铆足了劲在上面发力,提出了各自的解决方案,腾讯推出了 Serverless 2.0,以及前段时间阿里云推出的预留模式,都是对 Serverless 越来越重视的表现。

阿里近期在做前端研发升级,为拓展前端的边界和职能,尝试做了一次和 Serverless 的结合,希望能将传统应用快速迁移到 Serverless 体系,让大家都能享受到 Serverless 的红利。

image.png

Serverless 技术已经来临,Web 应用是 Serverless 技术一个重要的场景。

应该以什么姿态和角色去迎接新的技术变革,是每个端开发需要思考的问题。

我们可能会有如下思考:

  • Serverless 能给我们带来多大价值?
  • 有没有符合 Serverless 应用的开发框架?
  • Serverless 下前端传统的渲染,该如何做?
  • Serverless 应用的开发模式会不会和过去的开发模式存在很大的差异?

为了让 Web 应用在 Serverless 场景下,保持甚至超越传统开发体验,我们做了许多探索。我们尝试将传统 Web 应用框架迁移到 Serverless 平台上,比如 Egg.js 等框架,虽然与传统开发体验相差不大,但是也带来了不少问题,例如不支持跨云平台,还需要针对 Serverless 特性做好适配,相关的工具也没法深度适配 Web 应用框架这种特定场景。

FaaS 架构研发模式如何升级

Node.js Web 的浪潮,把前端变为了全栈开发工程师,体会到了传统前后端一体应用的魅力,也扩充了前端的边界,而 Serverless 则成了工程师们从 DevOps 到 NoOps 的另一次契机,新的革命即将到来。

传统应用开发、调试、部署的整个研发流程,在新的机会下需要模式升级,也需要从工具链、框架、到整个发布和灰度以及回滚流程,整体来重塑原有的体系。

面对基建成本和技术革新,阿里集团利用传统的 Node.js 技术栈的经验积累,演进出全新的 midway-faas 框架,结合完整的工具链从整个研发流程,调试,发布着手,通过平台化,工具化,将整个工程从头迁移到 Serverless 新体系。

为此,阿里开始了「前端研发升级」这个大项目。

整个前端研发模式升级的目的有两个,一为「前端赋能」,二为「提效」。所谓的「前端赋能」,是因为我们希望能够打破现有的技术壁垒,朝着更底层、面向数据的地方去深入探索,在这之中可以从面向 UI 和视图本身变得更加了解业务,从更全面的视角来理解现有的体系。而「前端提效」,则是希望让 Serverless,用更轻量化的方式进行业务研发,降低整个前端参与业务交付的门槛,同时,在开发期间,也能减少人力总成本,让前端减负,业务小步快跑成为可能。

概览如下,用户代码桥接函数和 BaaS 服务,其中 HTTP 网关和函数运行时、容器是三大核心技术。

image.png

基于现有生态,如何实现函数运行时,其中也是有很多故事的。

image.png

Node.js 基础团队的使命,就是为阿里集团 Node.js 生态提供各种基础能力,包括但不限于框架,中间件包等,而在 Serverless 体系中,我们要负责框架、工具链、运行时、发布系统,同时也需要和周边的网关,监控系统等对接。

image.png

渲染层如何做

从 beidou、Next.js、Egg-react-ssr 到 Umi SSR, 可以看出服务端渲染是很重要的端侧渲染组成部分。无论如何,React SSR 都是依赖 Node.js Web 应用的。那么,在 Serverless 时代,基于函数即服务(Functions as a Service,简写为FaaS)做 API 开发相关是非常简单的,因为它 1. 无服务,不需要管运维工作;2. 代码只关心函数粒度,面向 API 编程,降低构建复杂度;3. 可扩展。

image.png

那么,在 FaaS 下,如何做好渲染层呢?直出 HTML,做 CSR 很明显是太简单了,其实我们可以做的更多,笔者目前能想到的 Serverless 时代的渲染层具有如下特点:

  • 采用 Next.js/egg-react-ssr 写法,实现客户端渲染和服务端渲染统一
  • 采用 Umi SSR 构建,生成独立 umi.server.js 做法,做到渲染
  • 采用 Umi 做法,内置 Webpack 和 React, 简化开发,只在构建时区分客户端渲染和服务端渲染,做好和 CDN 的搭档,做好优雅降级,保证稳定性
  • 结合 FaaS API,做好渲染集成

为了演示 Serverless 下渲染层实现原理,下面会进行简要说明。在 Serverless 云函数里,一般会有 server.yml 作为配置文件,这里以 lamda 为例子。

image.png

通过这个配置,我们可以看出函数 app.server 对应的 HTTP 请求路径是 '/',这个配置其实描述的就是路由信息。对应的 app.server 函数实现如下图。

image.png

通过提供 ctx.ssrRender 方法,读取 dist 目录下的 Page.server.js 完成服务端渲染。

核心要点:

  • ssrRender 方法比较容易实现
  • 采用类似 Umi SSR 的方式,将源码打包到 Page.server.js 文件中
  • 在发布的时候,将配置,app.server 函数和 Page.server.js 等文件上传到 Serverless 运行环境即可

综上所述,我们大致可以推出架构升级的四大阶段。

image.png

  • 在 CSR 中,开发者需要关心 React 和 Webpack
  • 在 SSR 中,开发者需要关心 React、Webpack 和 Egg.js
  • 在 Umi SSR 同构中,开发者需要关心 React 和 Egg.js,由于 Umi 内置了 Webpack, 开发者基本不需要关注 Webpack
  • 未来,基于 FaaS 的渲染层,开发者只需要关心 React, 不需要关心 Webpack 和 Egg.js

在这四个阶段中,依次出现了 CSR 和 SSR, 之后在同构实践中,对开发者要求要更高,甚至是全栈。所有这些经验和最佳实践的积累,沉淀出了更简单的开发方式,在未来 Serverless 环境下,希望前端更加简单、高效。

Serverless 时代,我们还能干点什么

Serverless 是一个颠覆性的演进,与之伴随而来的,是对未知的探索,这既是机遇也是挑战。

1)自动化
目前看,从申请域名,到网关,到集群的链路,离「无运维」还有许多优化空间。

2)面向页面开发,会导致页面管理成本增加
页面和 API 都以函数的形式存在,其维护成本比微服务时还要高

3)多种技术栈的融合
像早年的 Portal,现在的微前端,其实都是在解决「Widget 或组件的复用和配置」问题。

一个大型应用被“碎片化”后,还要保持“一目了然”。它由哪些子应用构成、运行状态、异常监控、代码健康度、甚至一些运营数据的监控,就变得非常必要了。

简化开发,赋能业务,为大中台,小前台贡献应变能力,笔者畅想的未来是这样的:

  • 组件:开发只写组件
  • 页面:配置出来
  • 系统:集成出来

寄语未来前端

通过阿里前端的四大方向:Serverless、搭建、智能化、IDE, 我们可以看到未来对前端要求会越来越高,复合型人才(比如掌握算法),需要跨界(影响力),国际化,生在这样的时代是每一个前端的机遇和荣耀。

希望前端能够有更强的业务 Owner 意识,勇于创新,打破前端自身的局限和壁垒。无论 Serverless 还是智能化,我们都在突破,引领潮流。

本届 D2 Serverless 专场

其实,Serverless 背景下的前端困境对应的解决方案,业界都在探索,这是一条开拓的路,本次 D2 特地设置了 Serverless 专场,邀请国际国内知名一线专家,共同探讨,目前已入驻以下主题,邀你共赏。

1)Serverless 赋能前端应用开发

  • 讲师:Matheus Fernandes & Shu Ding, 海外嘉宾,来自业界践行 Serverless 的先驱、知名 Serverless 解决方案提供商 ZEIT 公司。Matheus Fernandes 是 ZEIT 的技术负责人,知名的产品包括 Next.js 和 ZEIT now, 他帮助团队快速发展和业务的全球扩张。对开源、网络、CDN加速和摄影充满热情。为了追逐梦想,他辍学了,环球旅行和写代码,作为 ZEIT 的技术负责人,他两项爱好都实现了。Shu Ding 是 ZEIT 的产品设计师,他参与深受全球用户的喜爱的 Next.js、zeit.co 管理后台、SWR 等产品的设计。从高中开始编程,花了 4 年在算法比赛上。复旦大学计算机系本科毕业,目前是一名平面设计师和前端开发者,在上海工作。他创建了 inns.studio 以及其他很多项目。
  • 内容摘要:ZEIT 是如何应用 Serverless 思想,借助前端实现 API 目录以及 Serverless target 等功能,在无额外开发成本的情况下,大幅度提升应用的可用性与伸缩性的? 在本次分享中,我们将通过分析实际的案例,去了解 Serverless 在开发场景背后的工作方式,一起感受如何利用 Serverless 的思想和能力去编写功能强大的前端应用程序。

2)前端新思路:组件即服务和 Serverless SSR 实践

  • 讲师:狼叔,来自阿里巴巴,花名狼叔,前去哪儿前端架构师,StuQ 明星讲师,Node.js 技术布道者。曾就职于新浪、网秦,曾做过前端、后端、数据分析、移动端负责人、做过首席架构师、技术总监,全栈技术实践者,目前主要关注技术架构和团队梯队建设方向。
  • 内容摘要:今天,做 Node.js 的运维和高并发依然是富有挑战的,为了提效,我们将架构演进为页面即服务,可是粒度还不够,借着云原生和 Serverless 大潮,无运维、轻松扩展,是对前端极大的诱惑。那么,基于 FaaS 之上,前端有哪些可能性呢?2019 年上半年,我在阿里巴巴经济体前端委员会推进的 Serverless 研发体系共建项目中负责 Serverless SSR 的研究,将 CSR、SSR、边缘渲染进行整合和尝试,提出组件即服务的概念(Component as Service),试图结合Faas, 做出更简单的开发方式。本次分享主要围绕 Serverless SSR 和它的演进过程、背后思考为主。

3)Serverless 下函数应用架构升级

  • 讲师:陈仲寅,来自阿里巴巴,花名张挺,长期耕耘于 Node.js 技术栈,为淘宝和阿里其他BU提供框架和中间件解决方案,负责淘宝整体的 Node.js 体系基础建设,解决全栈开发的各种维护和稳定性问题,也同时负责 MidwayJs 系列内部和社区开源产品,包括 Midway、Sandbox、Pandora、Injection等开源产品的开发、维护等工作。
  • 内容摘要:Node.js Web 的浪潮,让前端变为了全栈开发工程师,体会到了传统前后端一体应用的魅力,也扩充了前端的边界,而 Serverless 则成了工程师们从 DevOps 到 NoOps 的另一次契机,一次革命。
    传统的应用开发、调试、部署的整个研发流程,在新的机会下需要模式升级,也需要整体重塑原有的体系,从工具链、框架、到整个发布和灰度以及回滚流程。

面对基建成本和技术革新,阿里集团利用传统的 Node.js 技术栈的经验积累,演进出全新的 midway-faas 框架,结合完整的工具链从整个研发流程,调试,发布着手,通过平台化,工具化,将整个工程从头迁移到 Serverless 新体系。
本次分享主要围绕 Serverless 体系下,使用全新的框架、工具链和研发模式,讲解在新的体系中进行业务快速迭代,研发升级以及多场景,多环境的问题。

4)基于 FaaS 实现 NPM CDN 同步

  • 讲师:张立理,就职于百度,现任资深前端工程师 & 百度 ECOMFE、FE-CMC 主席一职。作为行业享有盛名的大咖,张立理行事低调,对工作热情饱满,多次受邀作为嘉宾出席各类大会,并发表了精彩演讲。
  • 内容摘要:NPM 是 JavaScript 最权威的依赖仓库,通过 CDN 访问 NPM 任意包内的文件有助于快速构建前端应用,UNPKG 和 jsDelivr 是国际上比较知名的 NPM CDN 提供商,本次分享将介绍通过基于云服务(包括函数云、对象存储、CDN、容器引擎)和 Terraform 框架构建一个高弹性、高稳定性、免运维的 NPM 到 CDN 的同步服务

image.png

相关实践学习
【文生图】一键部署Stable Diffusion基于函数计算
本实验教你如何在函数计算FC上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。函数计算提供一定的免费额度供用户使用。本实验答疑钉钉群:29290019867
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
目录
相关文章
|
1天前
|
弹性计算 Serverless 调度
面向Workload级别的灵活可配置Serverless弹性解决方案
Serverless作为云计算的延伸,能提供按需弹性伸缩的能力,让开发者无需关心具体资源部署,优化资源使用,因而被众多云厂商采用本文将介绍四种资源可配置插件,探讨它们的核心能力、技术原理,以及在实际应用中的优劣势。
|
23天前
|
人工智能 Serverless
解决方案 | 函数计算玩转 AI 大模型评测获奖名单公布!
解决方案 | 函数计算玩转 AI 大模型评测获奖名单公布!
|
1月前
|
消息中间件 人工智能 弹性计算
《触手可及,函数计算玩转 AI 大模型》解决方案评测
一文带你了解《触手可及,函数计算玩转 AI 大模型》解决方案的优与劣
70 14
|
1月前
|
人工智能 弹性计算 数据可视化
解决方案|触手可及,函数计算玩转 AI 大模型 评测
解决方案|触手可及,函数计算玩转 AI 大模型 评测
33 1
|
1月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
99 1
|
2月前
|
人工智能 弹性计算 监控
触手可及,函数计算玩转 AI 大模型解决方案
阿里云推出的“触手可及,函数计算玩转 AI 大模型”解决方案,利用无服务器架构,实现AI大模型的高效部署和弹性伸缩。本文从实践原理、部署体验、优势展现及应用场景等方面全面评估该方案,指出其在快速部署、成本优化和运维简化方面的显著优势,同时也提出在性能监控、资源管理和安全性等方面的改进建议。
103 5
|
2月前
|
缓存 前端开发 JavaScript
前端serverless探索之组件单独部署时,利用rxjs实现业务状态与vue-react-angular等框架的响应式状态映射
本文深入探讨了如何将RxJS与Vue、React、Angular三大前端框架进行集成,通过抽象出辅助方法`useRx`和`pushPipe`,实现跨框架的状态管理。具体介绍了各框架的响应式机制,展示了如何将RxJS的Observable对象转化为框架的响应式数据,并通过示例代码演示了使用方法。此外,还讨论了全局状态源与WebComponent的部署优化,以及一些实践中的改进点。这些方法不仅简化了异步编程,还提升了代码的可读性和可维护性。
|
2月前
|
人工智能 自然语言处理 监控
体验《触手可及,函数计算玩转 AI 大模型》解决方案测评
本文介绍了《触手可及,函数计算玩转 AI 大模型》解决方案的测评体验。作者对解决方案的原理理解透彻,认为文档描述清晰但建议增加示例代码。部署过程中文档引导良好,但在环境配置和依赖安装上遇到问题,建议补充常见错误解决方案。体验展示了函数计算在弹性扩展和按需计费方面的优势,但需增加性能优化建议。最后,作者明确了该方案解决的主要问题及其适用场景,认为在处理大规模并发请求时需要更多监控和优化建议。
52 2
|
2月前
|
JavaScript 前端开发 Serverless
前端全栈之路Deno篇:Deno2.0与Bun对比,谁更胜一筹?可能Deno目前更适合serverless业务
在前端全栈开发中,Deno 2.0 和 Bun 作为新兴的 JavaScript 运行时,各自展现了不同的优势。Deno 2.0 重视安全性和多平台兼容性,尤其是对 Windows 的良好支持和原生 TypeScript 支持;而 Bun 则以卓越的性能和简便的开发体验著称,适合快速迭代的小型项目。两者在不同场景下各具特色,Deno 更适合企业级应用和serverless,Bun 则适用于追求速度的项目。
265 1
|
2月前
|
人工智能 弹性计算 运维
《触手可及,函数计算玩转 AI 大模型》解决方案测评
对《触手可及,函数计算玩转 AI 大模型》解决方案的整体理解较好,但建议在模型加载与推理过程、性能指标、示例代码等方面增加更多细节。部署体验中提供了较详细的文档,但在步骤细化、常见问题解答、环境依赖、权限配置等方面有改进空间。解决方案有效展示了函数计算的优势,建议增加性能对比、案例研究和成本分析。方案基本符合生产环境需求,但需增强高可用性、监控与日志、安全性和扩展性。

热门文章

最新文章

相关产品

  • 函数计算