软件开发架构师

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

前端 12 2019-11-09 01:36

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

02 设计 / 开发

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

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

主要有三部分:

1. 静态资源存放

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

2. 数据存储使用

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

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

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

3. 应用逻辑实现

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

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

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

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

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

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

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

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,将给前端发展带来大变革的技术?(下)-InfoQ-5

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

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

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

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

05 运维 / 告警 / 监控

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

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

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

结语

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

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

原文链接:

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

文章评论