Serverless,将给前端发展带来大变革的技术?(下)

阅读数:376 2019 年 10 月 31 日 20:40

Serverless,将给前端发展带来大变革的技术?(下)

本文将从前端的角度来看 Serverless 究竟是什么,Serverless 的出现会给前端带来什么样的机遇和挑战,并以一个具体的项目为例说明如何基于 Serverless 实现项目功能。

02 设计 / 开发

以下是一个基于 Serverless 的 Web 应用通用架构。

Serverless,将给前端发展带来大变革的技术?(下)

主要有三部分:

1. 静态资源存放

  • 静态资源(JS/CSS/IMG/HTML)放在 COS(对象存储),COS 可以自定义域名和开启 CDN 加速,通过 URL 直接访问。
  • 模板文件和数据文件放在 COS,函数通过 COS SDK 可以很方便的对文件进行读写。

2. 数据存储使用

由于 Serverless 的特点是事件触发,用完释放。那么需要考虑本地存储和缓存必须依赖于第三方服务如 COS(对象存储)和 Redis。不过函数实例本身会有延迟释放的时间,便于在新请求来的时候可以复用,可以利用本地缓存作为第一级缓存。

Serverless,将给前端发展带来大变革的技术?(下)

DB/Redis 的连接访问和原来一样,在云平台申请相关存储资源,设置和云函数相同的虚拟子网,云函数就可以通过内网地址进行资源访问,保证了数据服务和外网的安全隔离。腾讯云数据库提供了全套运维解决方案,大大简化了运维工作。

3. 应用逻辑实现

传统架构上请求是由 Nginx 代理转发到相关 NodeServer 上去处理,而 Serverless 是请求到了 API 网关再转发到云函数上处理。原来的转发内容是 HTTP 请求,云函数上接收的是 API 网关事件。为了应对这种变化,可以在代码中直接去解析使用 API 网关事件。但如果已经很习惯 express 的开发框架,而且很依赖一些好用的中间件,如果需要重建这部分中间件,这会是不小工作量。

那有没有方案兼容原来的写法?可以将 API 网关事件转换成 HTTP 请求,通过本地 Socket 和函数 NodeServer 进行通信。

Serverless,将给前端发展带来大变革的技术?(下)

但这样中间经过了一层的转发,性能会不会有所损耗呢?在耗时统计来看,有了这一层转发,云函数平均耗时也在 20ms 之内,中间即使有性能损耗也在毫秒级别的了,相对于网络耗时来说,就是小巫见大巫了。

所以非必要的情况下,无论是迁移还是新开发的 Web 项目其实都可以采用这个方案:

中间转发代理层已经有一些可用的框架(serverlessplus, scf-framework)。

Serverless,将给前端发展带来大变革的技术?(下)

03 调试

接下来看一下怎么调试云函数。

  • 第一种,通过命令行可以很方便的将代码发布到云函数平台上,支持云上调试
  • 第二种,对于复杂一点的应用,可以使用 SCF 命令行工具在本地环境进行调试。
  • 第三种,我们前端可能比较习惯在浏览器中直接刷 url 来调试,如果项目是基于 koa 或者 express 之类的框架,可以直接增加一个 server 的入口,调试的时候就直接本地起一个 nodeserver 来调试。

但是目前发布到云函数是要包含 node_modules 文件夹的,压缩之后,需要通过网络传输上去。如果改一行代码,就要上传一次来执行,这样比较复杂,而且在线的 IDE 也是只能编辑入口文件的,但是代码都不是写在入口文件那的,升级 IDE 需求也在规划开发中。

如果在本地调试,需要提前安装 SCF CLI 命令行工具、docker,这个运行方式的原理是,加载一个和云函数环境相同的一个镜像,然后在 docker 中去执行。然而还是会遇到一些问题:

  • 比如连接的数据库需要是外网地址,因为 docker 的网络环境和本地并不能连通,与云上的环境也不能连通。
  • 还有,比如我在本地安装的 npm 包,也不能正常执行,因为本地开发环境是 mac 系统,而镜像是 linux 系统。

SCF CLI 本地命令行工具,可以支持 native 调试,就是用本地的环境进行调试。这样就解决了数据库连通问题,以及调试时操作系统差异问题。(那么系统差异的问题只能是需要一个专门的编译机了,一般情况下,如果依赖的 npm 库如果不涉及到操作系统差异的话,npm 包都是可以通用的。)

如果项目是基于 koa 或者 express 之类的框架,可以直接增加一个 server 的入口,调试的时候就直接本地起一个 server,和普通 node server 一样的进行调试。

04 测试 / 上线 / 迭代

前面说到用命令行工具很方便的将代码发布到云函数平台上。还需要测试、上线与回滚。云函数本身有发版本功能。API 网关也默认有测试、预发布、发布 3 个环境,每个环境可以指定云函数的版本。这样看起来就可以将测试和线上的环境区分开。

Serverless,将给前端发展带来大变革的技术?(下)

但是,测试和线上连接的资源是不一样的,比如 DB,我们通常是通过读取环境变量来判断是测试环境还是线上环境,但是一个云函数只有一个配置。

腾讯云函数还提供了命名空间、函数复制这样的功能。利用这些功能可以:

  • 测试和线上放在两个不同到命名空间,隔离测试和线上代码,更加安全;
  • 测试和线上环境通过函数配置不同的环境变量来区分;
  • 上线通过复制函数来完成,选择不复制配置;
  • 回滚通过 API 网关切换函数版本来完成。

这样就可以满足我们的测试部署、上线部署,回滚的需求了。

05 运维 / 告警 / 监控

在 Serverless 下,运维需要做哪些呢?负载均衡,流量控制,扩缩容,高并发,安全防护这些都由云函数平台做了。另外云函数接入了云监控,在云监控我们可以自定义统计视图,配置告警阈值和告警方式,还可以上报自定义的监控点。

Serverless,将给前端发展带来大变革的技术?(下)

至此,从开发到调试,从部署到运维,一个项目的完整开发流程都已经完成了。

结语

最后,谈一下对云函数的展望,现在使用 HTTP 协议时,需要通过 API GATEWAY 中转一层,能不能去掉这一层中转?如果业务应用比较复杂,需要拆成多个云函数来承载,对于这样的现有项目能否 0 改造迁移?现在部署云函数的时候,需要将 lib 库也打包上传,未来希望能和代码仓库打通,在 git push 的时候,能够在线编译,并且自动部署。

本文转载自公众号云加社区(ID:QcloudCommunity)。

原文链接:

https://mp.weixin.qq.com/s/ooX7uMFjxFfSai9URo6kYw

评论

发布