原回放链接以及PPT请访问这个推文
Web与serverless研发
Web研发遇到的问题
1. webServer的性能(自己开发?Nginx)
2. 流量激增
3. SSR与灰度
解决方法之一：将许多需要开发者手动配置的东西移到平台上，使其工作流化。
大纲
Web研发模式的演进以及遇到的问题
面向Serverless需要解决的问题
字节在Serverless中的实践
Web研发的演进
前后端分离(Ajax)->MVVM等框架可以更好的开发前端页面->小程序,全栈等应用工程师
Web研发的问题
1. 前端研发如何让应用流量激增带来的的运维问题自动化
2. 脱离对于大型框架的依赖
3. 开发时如何更好的配合后端的研发
字节的实践
应对大峰值问题
传统方法
静态CDN抗流量,少量回源.
缺点:不能自定义逻辑和服务器功能,对于SSR等需要根据用户信息来改变返回内容(不是在用户浏览器上渲染,而是直接根据请求信息返回对应结果)的时候,静态资源就雅达摸雅达了.
动态CDN加速与源站的传输.
缺点:源站难以保持业务独立,压力大
解决方案
CDN缓存
1. CDN根据源站头/Path分辨可以缓存的静态资源(基操)
2. 如果访问有特定的Header,说明可能是特殊请求,就不缓存(这个挺难决定啊)
3. 在CDN层对特定业务进行缓存,用回源作fallback
快速扩容
传统的Docker模式,扩容时需要给每个新增的容器配置环境(Node).通过V8的虚拟机机制,让不同的用户代码跑在同一个比较大机器所支撑的V8引擎,这样就可以不用给每个用户代码单独配置环境,而是可以在引擎级别上进行容量管理.
虽然热启动相比于冷启动可以节省启动基础镜像,下载用户代码并启动用户进程的时间,但是依旧需要花费启动V8引擎,初始化运行环境等时间.但是Fastworker就实现了去Pod化(使用V8 Isolate机制,同进程,但是可以隔离用户代码),只需要加载V8 Snapshot就可以直接执行(免除了解析编译等过程).
Worker资源池业务级隔离,公共池兜底.
研发框架协同
传统开发
框架+CLI---build--->Dist----->部署
难点:构建出的资源,平台本身是不知道该如何部署,需要开发者手动指定
MordenJs
框架在build的时候生成一个说明书,指导平台对构建出的资源进行部署.
例如:CSR:路由映射信息,是不是SPA;为了避免用户访问SPA子路由时源站返回404,该如何对负载均衡配置访问的Rewrite
快速预览
传统开发
发布到测试环境
缺点:地址可能重复,网址如何鉴权/根据访问者权限进行AB分流
字节实践
研发平台网关进行分流,测试者携带不同特征(例如浏览器插件加header,客户端的隐藏设置等),让网关把请求打到对应服务器上.开发者只需要在PR的时候提交分流策略即可.
在线调试
1. 定制runtime,在用户代码外层包裹Debug工具,可以线上检测堆栈等信息
2. 埋点建议,日志输出
常见部署实践
Full Stack App
Gateway根据url与header判断打到哪些server上(例如CSR/BFF)
微前端
CSR/SSR的server会拿到工程的配置,注入子模块的信息,让用户可以拿到对应的子工程;部署者只用单独配置工程,然后在部署平台约定微前端主/子工程的关系,可以让工程师独立部署,分流以及AB.
探索-Custom Server
场景:根据请求特征返回对应的文件.例如不同域名时返回不同的Meta标签(SEO);区分浏览器是否支持ESM等.
传统做法:在前端代码判断运行环境,请求并渲染特定的模块;增加proxy server劫持请求,但是不能让平台进行运维管理,需要自行解决扩容等问题
基于平台的做法:服务器暴露接口,开发者实现对应的hook,让用户Server(干预构建好的文件)与平台Server一同部署在平台提供的Fast Worker中.
