从​开发调试到部署运维 一套完整的Serverless项目开发经验分享

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

前端开发的横向演进

在刚开始的互联网时代,网页很简单,就是一些静态或简单动态的页面,主要是用来做信息的展示和传播。开发一个网页主要就是通过 JSP、PHP 等技术写一些动态模板。这个阶段还没有前后端的分工,通常是后端工程师顺便写了前端页面。

在 AJAX 技术出现之后,可以把 Web 分为前端和后端,前端负责界面和交互,后端负责业务逻辑的处理。前后端通过接口进行数据交互。随着页面越来越复杂,移动网络的应用的兴起,对加载性能有了更多的要求,通常异步渲染页面白屏时间比较长,另一方面对SEO也不够友好,所以落地页又回归到服务端渲染的这个方案。

前端在发展,后端也在发展,在分层和模块划分上更加的粒度化,微服务化。微服务的接口不再是面向页面,前端的接口调用变得复杂了,所以需要在微服务和前端中间,加了一个 BFF 层,全称(backend for frontend),由这一层 对接口进行聚合、裁剪后,再输出给前端。而这层不是后端本质工作,距离前端比较近,关系更大一些,所以前端工程师很自然选择了 Node.js 来实现。这也是当前 Node.js 在服务端比较广泛的应用。

可以看到,每一次前端开发模式的变化,都因为某个变革性技术的出现。先是 AJAX,然后是 Node.js。那么下一个变革性的技术是什么?不言而喻,就是 Serverless。

但是,如果完全让前端工程师来开发一个后端,需要考虑很多内容。

  • 首先要考虑代码运行的环境和相关资源。比如前端代码运行的环境是用户的浏览器。后端环境需要服务器,网络,访问服务的域名、证书,服务器的操作系统,软件安装,webserver,数据库等。
  • 除此之外,前端要考虑的是用户的网络,浏览器的兼容性,交互的流畅程度,还有视觉效果。后端还要考虑负载均衡,流量控制,弹性伸缩,高并发,备份容灾,安全防护,监控警告等。

前端并不擅长这些,但有了Serverless之后,这些我们基本上不用考虑,我们的主要精力可以用来实现业务逻辑。Serverless为什么能帮助做这些事情?

FaaS+BaaS可以称之为一个完整的Serverless,FaaS(Function as a Service) 是函数运行的平台。BaaS(Backend as a Service)则是一些后端云服务,比如云数据库、对象存储、消息队列等,通过使用BaaS,可以极大简化应用开发难度。开发者将代码上传到云函数平台,并配置相关的触发器。平台根据触发器事件,完成运行环境的准备、调度、执行和扩容这些工作。

从架构上,可以看到Serverless 的这些特点:

  • 无运维,使用 Serverless 我们不需要关心服务器,不需要关心运维,这也是 Serverless 思想的核心。
  • 无状态,因为每次函数执行,可能使用的都是不同的容器,无法进行内存或数据共享。如果要共享数据,则只能通过Redis 、COS等第三方服务。
  • 事件驱动,函数在 FaaS 平台中,是需要通过事件来触发函数执行。
  • 低成本,实现按需调用,按需伸缩、按使用收费。

基于Serverless的前端开发模式

01

BFF

基于Serverless,前端的一些通用开发模式可以怎么来做呢?下图是比较通用的BFF架构。最底层是后端微服务,最上层是前端应用,在微服务和应用之间,是通常由前端工程师开发的 BFF层,对接口进行聚合裁剪,在返回给前端使用 。

这样的架构解决了接口协调的问题,但也带来了一些新的问题。以前前端只需要关注浏览器端的渲染,现在却需要维护各种 BFF 应用以及运维,但是通常前端并不擅长运维。Serverless的出现可以很好的解决这些问题。基于 Serverless,可以使用云函数来实现BFF层,只需要关注业务逻辑,运维的工作交给了Serverless平台。

图中的APIGateway代替了我们的nginx代理服务器,以前可能是将转发规则写在代理服务器的配置文件中,现在在API网关中有了可视化的管理、可监控、可设置版本等等更多更易用的功能。

02

SSR

传统的服务端渲染,服务端根据路由返回渲染好的HTML页面。而在Serverless上实现也类似,可以将多个页面返回放到一个函数中,也可以将每个页面拆分成一个个云函数,这样用户请求的一个页面,对应的就是每个单独的函数。

03

小程序

目前国内使用 Serverless 较多的场景可能就是小程序开发了。在传统的小程序开发中,需要前端工程师进行小程序端的开发;后端工程师进行服务端的开发。小程序的后端开发和其他的后端应用开发,本质是是一样的,需要关心应用的负载均衡、弹性伸缩,备份冗灾、监控报警等等运维操作。

但基于云开发,开发者只需要关注于业务的实现,由一个前端工程师就能够完成整个应用的前后端开发。应用的运维转移到了云平台上。

04

后端思维

前端工程师去基于Serverless去写后端,最好也要具备一定的后端知识。涉及复杂的后端或者Serverless不适用的场景,还是需要后端去开发,只不过后端变得更加靠后。简单说说前后端开发异同之处。

1、共性思维,就是前端后端都通用的。

  • 第一个工程化,分层模式,前端的工程化现在也相当的成熟,视图和数据分离,组件和页面的组装,而后端最基本的一个分层模式就是DAO层,业务模块层,接口层。
  • 可用性:监控一切。这个大家都比较好理解,服务端监控包括:接口,各种服务,机器的性能等等
  • 高性能:和前端有各种缓存技术方案一样,在后端如果要提升性能,一样需要利用缓存,理论上每个层级都可以缓存,从数据库到Redis,内存,从元数据到渲染好的页面,但缓存越多,系统复杂度也越高,需要根据需求成本来平衡方案取舍。

2、安全意识。

  • 防别人对付用户 :设置 CSRF Token
  • 防用户对付系统:参数校验、权限检查、防SQL注入
  • 防系统对付自己:提交防重/频率控制

3、并发意识。服务端和前端主要不同的点是,服务端同时服务所有用户,需要有并发的意识。

  • 资源多级隔离:防止一个有问题导致系统雪崩。
  • 共享数据加锁:比如有限数量的商品多人同时下单的场景。
  • 任务队列缓存:将高并发放到任务队列中,减缓并发高峰,让高并发变得更为可控一些。

如何基于Serverless进行项目开发

程序受众广易传播,开发成本低,效果好等特点,非常适合老产品拉新/创新,新产品快速尝试。这里以一个背单词小程序为例。

01

项目需求

这个项目的核心需求是学习单词,记录学习情况,学习单词又包含看单词,听单词发音,读单词,系统对用户发音进行评分,还有检验。

基于Serverless的技术方案如下,可以看到有登陆模块,通过云函数,调用微信的API进行登录校验。语音合成和口语评测这两个功能,腾讯云就有这两个服务,可以直接调用,需要做的仅仅是通过云函数进行鉴权中转。学习记录这部分,就结合函数逻辑和云数据库来完成。可以看到项目的完整层级架构,是非常清晰简单的。

一个项目的完整开发流程包括设计/开发、调试、测试、上线、监控/运维,下面展开说一下基于Severless每个阶段具体是怎样做的。

02

设计/开发

以下是一个基于serverless的web应用通用架构。

主要有三部分:

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

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

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

  1. 应用逻辑实现

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

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

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

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

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

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个环境,每个环境可以指定云函数的版本。这样看起来就可以将测试和线上的环境区分开。

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

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

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

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

05

运维/告警/监控

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

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

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

开发者所想,也是服务商所想,这些功能腾讯云都正在开发中,近期将会发布,敬请期待!

关联阅读:前端学Serverless系列--性能调优

原文发布于微信公众号 - ServerlessCloudNative(ServerlessGo)

原文发表时间:2019-07-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券