15158846557 在线咨询 在线咨询
15158846557 在线咨询
所在位置: 首页 > 营销资讯 > 网站运营 > Serverless从入门到放弃 | 4. 网站开发实践

Serverless从入门到放弃 | 4. 网站开发实践

时间:2023-05-25 07:24:01 | 来源:网站运营

时间:2023-05-25 07:24:01 来源:网站运营

Serverless从入门到放弃 | 4. 网站开发实践:前面几篇文章介绍了Serverless的基本概念、开发平台和框架。

本文介绍使用Serverless搭建网站实践,包括技术栈、优化和最终为什么放弃。

第一阶段 一体化

灵题库是一个前端题库网站,包括用户端和管理后台。

一开始采用了前后端一体化的方案,部署在FaaS。

使用在阿里云申请的免费证书支持https。

FaaS使用阿里云的函数计算,使用Midway Serverless框架的React模板,用mysql库连接数据库,orm使用typeorm,使用nodemailer发送邮件实现注册功能,joi进行接口参数校验。

前端方面,该模板使用vite进行打包,灵题库使用redux管理状态 + react-router实现路由能力,组件库用antd,css预编译用stylus,富文本用quill。

由于Midway框架丰富完善的功能,第一版很快就上线了。

第二阶段 前后端分离

但是马上出现了性能问题。白屏时间太长,经过排查,大概猜测到了原因,因为购买的是FC的按量模式,这个在之前文章中有介绍,当没有请求时候,没有实例在工作,当开始有请求时候才会启动实例来响应,实例可以复用,所以多个请求在一段时间内可能响应很快,但是长时间没有请求,突然一个请求过来,会有初始化时间的延时。

而且,前端代码不断迭代,代码、图片、字体等不断增加,整个项目体积会不断增长,白屏时间也会越来越长。另外阿里云的FC规定如果体积超过50M需要提供oss的地址以存放代码。


总结一下就是

1. 如果使用按量模式,白屏会比较严重,如果使用预留模式,则要支付额外费用

2. 前端项目体积在迭代过程中增长较快,会导致超过50M限制,FC要求提供oss以存放代码。

基于以上问题,经过权衡,网站放弃了一体化方案,将前后端分离,前端项目部署到ecs上,后端api继续使用FC。

第三阶段 优化

分离之后白屏问题消失了,前端页面很快展示。但是API依然存在首次启动慢的问题,导致首次访问时候,数据加载中的loading时间较长,这也是让用户难以接受的体验。


为了解决首屏内容加载慢,采用了前端预渲染的方案。

但前端预渲染只能解决首屏加载慢,从首屏继续访问其他页面、从其他页面退回首屏,都可能因为FC首次启动慢而导致需要用户长时间等待的情况。

因此又采取了数据预下载的优化方案。

预渲染和数据预下载不能保证每次成功,因为本地请求接口时间也不固定,即使设置为60s,也还是存在FC接口没有几十响应的情况,因此每次本地构建完,都需要手动检查一下(如果自动化检查,当项目更新,也还要更新检查脚本),这让项目变得不好维护。

每次后台数据更新,都要重新构建,以保证首屏渲染数据是最新的。




前后端拆分还要注意一个问题是跨域访问问题

本地支持跨域cookie设置和访问,需要服务器设置header:access-allow-control-credentials为"true",并设置access-allow-control-origin为指定的origin,前端xhr.withCredentials设置为true。另外前端需要通过ip访问,请求后端接口也需要通过ip访问。注意有些浏览器(如chrome)默认设置cookie的samesite为"lax",且拒绝接受不为secure的samesite为"none"的cookie,sucure必须设置为“true”,即https访问。

本地调试,如果前端项目和后端项目都用ip访问,即使端口不同也不会导致跨域,因此我们通过ip访问本地项目就可以前后端调试了。

最后 放弃

注意到这时候系统已经渐渐变得复杂起来。

除了项目更加复杂,FC还有一个让人头疼的特性:IP不固定,这个很好理解,因为实例都是动态管理的,IP不固定的话对于Serverless平台更好管理。这个特性导致API放在FC时候,在和其他开放平台交互的场景(如微信公众后台)需要特殊处理,如果API server需要调用微信的接口,必须在微信公众平台配置服务器的IP白名单,但是FC实例IP不固定,没有办法配置白名单,对于这种情况,FC给出的建议是,通过一个拥有固定IP代理服务器发送请求,这就增加了系统的复杂度,而且还需要额外购买服务器。

还有一个问题,由于使用FC实现API,实例是并发的、动态的,对于在内存中保存多个接口共享的数据的场景(虽然这样做不推荐),FC就无能为力了,在灵题库网站中,为了实现验证码登录,只好采用了token的方式。

因为存在这些问题,对于轻量的、资金投入受限的网站,后续还是想把API从FC上迁出来,用Go重构到ECS上面。

总结

下面总结下使用Serverless搭建网站大半年的个人的感受,在web开发场景说说Serverless对于前端的机会。

FaaS是后端服务运行环境,简化后端运维,但对于小型的应用,不用考虑并发,其运维成本和ESC差不多,而且在一些场景还更麻烦(如它没有固定ip,不能在内存中存储状态)。只适合有一定规模的大型应用的使用。而Serverless普及程度不高,目前没听说有公司全站上Serverless的,因此前端想通过Serverless转全栈还是不太现实。

BaaS可以绕过后端服务,可以开发一款独立应用,因此对于前端想开发独立产品,可以选择BaaS产品,还省去了联调,提高开发效率。但同样普及度不高,因此在提高职场竞争力方面还是没什么空间。

结论:对于纯前端(没有太多后端运维经验),可以学习Serverless作为技术储备,但不建议作为提高核心竞争力的方向。

关键词:实践,入门,放弃

74
73
25
news

版权所有© 亿企邦 1997-2025 保留一切法律许可权利。

为了最佳展示效果,本站不支持IE9及以下版本的浏览器,建议您使用谷歌Chrome浏览器。 点击下载Chrome浏览器
关闭