今天讲的是怎么使用 Serverless 做后端技术分享。我的职业偏向是后端,可能不是写前端,不是使用 Node.js,更多是使用 CR 做后端语言,今天关注的微信小程序,我这一块的分享更多是怎么实现它的后端。我所使用的是 Serverless 技术,也是在近两年新出来的一种架构。讲 Serverless 这个架构之前,我也给大家讲一下小程序和传统的后台技术。
目录
小程序的后台技术
小程序,是一种全新的连接用户与服务的方式,它可以在微信内被便捷地获取和传播,同时具有出色的使用体验。它的加载方式比传统的 APP 方式更快速上线,体验也不差,除了它本身的界面展示和刷新之外,小程序里面的数据获取通过微信和后端进行交互,小程序的运行实际上是一个类前端的运行方式,整个运行是在微信内,它和后端的交互实际上通过微信进行转发的,运行起来之后,它会提出一个 api 的请求,这个请求首先给到微信,微信再通过网络 apr 转到你自己的服务器上,服务器拿到这个请求以后进行数据的处理,然后再响应到前端,这就是小程序和后台交互的一种架构。
微信小程序后台架构
对于后端服务,这张图是大家传统做的方式,暴露 api,这些都可以用来开发业务应用,业务应用之后需要有相应的存储文件,结构化的数据存储,或者是非结构化的数据存储,需要有数据库和缓存,为了实现这一套架构且不会由于某一块的服务器宕掉,或者有一些漏洞等等,我们通常的实现是一个较为复杂的过程。比如说,我们为了保证的 Serverless 和服务器不会垮掉,需要建立一个集群,我们要对外提供服务,需要 LB 的请求,请求到之后分到某一台服务器上。比如说文件存储,如果单纯只用一台设备,这台设备挂了,整个文件服务就挂了,所以我们要使用分布式存储来解决文件存储的问题。数据库和缓存也是一样的,需要构建集群,无论是两台还是三台还是多台,构建集群以后能确保不会由于某一个单点的问题导致整个服务不可用,从而导致服务瘫痪。
传统后台架构
传统后台架构
如果作为一个小程序开发者,这套架构在互联网公司已经搭建了,作为个人来说这一道太重了,需要了解这里面的某一块和它的配置,比如说数据库的集群怎么配?让大家没法把精力集中到你的业务和小程序本身,而是过多耗在运维和支撑上。
Serverless 架构
Serverless 架构
我下面要介绍的 Serverless 架构,采用无服务器的方式,主要会介绍无服务器和云怎么结合,怎么利用云的服务减轻架构化的工作。介绍它的架构之前,我介绍一下 Serverless 架构,英文称之为 Serverless,中文称之为无服务器,大家不用购买服务器,不用购买虚拟机或者物理机,这一块怎么运行呢?它使用计算托管的方式,在 Serverless 这里,我们可以看成两块,第一块就是函数即服务,它真正实现了你业务的托管计算。另外一种是后端即服务,包括对象存储,大家不用自己构建分布式存储,不用担心数据的丢失和安全性问题;同时在云上提供的数据库,消息队列和对象存储都是一样的,不用购买服务器自己搭建,在购买使用的过程当中我们可以称之为 Serverless。因为这些都是托管型的,使用的时候不用关心它的安全性,不用关心可能服务器宕机导致的故障。
Serverless 架构
Serverless 的计算托管式云在服务函数内,下面来讲一下云函数的架构。大家看到这个架构以后,我们后面在拿一个实际案例来看怎么把具体的 api 服务落地。云服务器架构本身是计算托管型的,计算托管意味着把真正的业务代码托管到云上面,然后在云上面运行,它的运行方式有一个特点是触发式运营,跟各个产品打通以后,各个产品产生的事件,后面的案例就是和 API 网关进行结合,从 api 网关来的事件就是 api 事件,当这个请求到达 api 网关时,我们就认为是一个事件,然后再运行。大家最初进行托管的时候,把代码和触发期的配置提交到云上面来,并不是说提交之后代码就运行起来,而是事件到达才运行起来,代码对这个事件进行处理。在这个过程中,对于每一次的事件,每一个代码拉起的过程,实际上都是单独处理一个事件,为什么呢?因为我们在这儿使用并发的模式,如果你有上万个用户同时访问你的小程序,要同时对上万的用户进行服务,启动上万的实例,它是在事件时运行起来,没有事件不能运行,这与微信小程序本身点开即用、用完即走的概念是符合的,有请求时才运行,没有请求时不运行。产品的计费模式也是根据实际运行的时间计费的。
Serverless 的使用
Serverless 的使用
怎么使用 Serverless 呢?传统的架构就是前面说的 web 服务,然后是使用存储、缓存,我们对外服务以后,有对外暴露相应的 api,实际上用户的业务逻辑都是放在云函数内,需要结构化存储,需要进行缓存或者对象存储,我们需要数据服务或者云缓存服务等,其他的服务都可以直接在线服务,这些服务直接通过代码调用。
前面讲了 Serverless 的架构介绍,后面是对于这个后台开发的介绍,后面也是基于这个方式进行详细案例的说明。
serverless 后台开发方案
小程序除了本身的页面启动,后续与网络的交互都是由小程序发起,经过微信本身以后,首先请求到达 api 网关,对于对外的 api 的管理,把这个 api 暴露到官网上,可以被要程序访问得到。它本身也能够提供 api 的发布和版本的切换能力,api 网关之后就是云函数。云函数就是实际处理业务的逻辑,如果你需要使用数据库,就在代码内发数据库的连接,需要存储文件,就调用相应的窗口写文件。
基于这个方案我们来看一下,传统提供的是中间的一块,因为前端是用户的小程序,后端是微信本身提供的接口服务,中间建议的是开发者自己的服务器。我们现在要展示的一个案例,也就是怎么把中间的开发者服务器替换掉,用 Serverless 的方案落地,我们使用了 api 网关加云数据库实现开发者服务器所能够做到的事情,不需要购买服务器而落地我们的 api。
首先从最前面的小程序来看,这个案例也是小程序开发者上面的 demo,demo 的前端包括登陆端口,以及 session 展示,我们在小程序这端首先获取一个 talk,开发者拿到以后再跟微信交互,验证合法以后,我们这里选择了记录到云数据库,这就是小程序界面提供点击登陆的位置,后面的业务会发送请求到云上面来。
对于这个小程序的核心,我们在某一个 api 上面的路径就是在 hos 的 login url 上发起 GET 操作,根据 Wx.login 构造请求的头部,body 内容,发送获取到的 code 及加密数据到后台。
用户示例
api 网关
我们看一下 api 网关做的事情,它对外以一个 api 的接口呈现出来,我们直接提供了对外访问的域名,用户基于这个域名绑定自己所拥有的域名,这种情况下可以实现发布的要求,微信小程序的开发者要求域名要备案,把自己的域名绑定到 api 的服务上面来,对外提供,在右侧 api 的网关上,配一个/login Get,在后台还未实现之前,可以配置为 mock 方法,解耦前后端,小程序可以基于 api 构造的 mock 数据开发。实现云函数后,对接 api 到云函数并更新发布 api,避免开发的同时影响到在线业务。
云函数的处理流程
从云函数的方面来说,用户会承载计算业务。按照我们最开始用户给的官方图,拿到 api 的请求以后,解析请求内容,根据规范连接微信认证服务器,获取认证情况并记录 session,返回 session 信息给到请求端。拿到微信服务器的返回以后可以判断用户的登陆过程是成功还是失败,如果成功以后可以拿到用户相应的值,这个地方我们发起到数据库的连接,建立一个 masico 的连接,完成 session 的记录。
云函数的处理流程之后,下面展示的是我们怎么和数据库建立连接,登陆信息的细节流程,创建连接并可复用连接,拼装 SQL 语句并执行。
数据库的配置
这个地方就是我们购买以后,数据库启动并且做了登陆以后,可以进入到数据库里面查看数据,查看 session 的记录。
实操案例——用户登陆及 session 展示
创建并初始化实例,按照 mysql 标准化使用方式操作,计算托管式的优势用户关心核心的代码,不用关心周边的运维,由于托管式业务,无论是个人请求,个人开发者的小程序,很有可能你的一个小程序就成为爆款,爆款以后可能访问量就是突增的形式。
我们利用 session 的架构实现小程序,而且不用去担心运维;秒级启动,弹性计算能力满足用户上万的并发。核心点关注业务代码,而不用关注 web,这就是快速的应用实现小程序的落地的方法。
Q/A
Q:在 api 网关部署 HTTPS 证书吗?
A:对,这个证书是腾讯云提供的,绑定你自己域名的时候,可以实现 HTTPS 的支持。
Q:我们在生产环境的时候由腾讯云提供的证书?
A:对。
Q:在生产环节需要腾讯云提供的证书上线我们的服务?
A:对,这是小程序方面的要求,因为小程序要求必须使用自有域名和小程序打通。
Q:小程序即用即删,如果手机里面有很多会很卡,如果小程序用过在微信上面的页面会显示出来,如果上万个对微信本身有什么影响?
A:可以从一些限制可以看到,现在对于微信小程序的大小有限制的,它本身的大小是要求,目前我记得是 5 兆包 2 兆包的大小,如果是上千个,对于你手机来说可能是多存储了一些数据,每个包最大用满可能就是 5 兆,本身小程序页面的加载都是有限制的,这个限制从微信角度来考虑,都是为了保证小程序的流畅运行,不会对用户的手机造成很大的冲击,这一块要微信的同学介绍,我是偏后端的。
Q:我再举个例子,小程序进入的时候加载速度比较快的,举一个比较极端的,比如说跳一跳,第一次使用的时候,它的加载速度,比如说今天用完了,删掉,过一段时间再进去,相比来说加载速度有差别吗?或者第二次用的时候快一些吗?原因是什么?
A:这个要由微信的同学解答比较好一些,因为这些都是小程序本身的体现,或者说速度的一种体现。
Q:你好,我是做后端开发的,什么样的模型不是用 Serverless 来做的。
A:Serverless 它本身的一些特性也限制了它的使用场景,比如说对于内存的配置,cpu 的配置,运行时间的限制,不是所有场合都适用,它本身对运行时间有限制的,不能长时间的运用,包括内存的使用,包括 cpu 的应用,比如说动画的渲染,长时间的批量计算,这些都不适合 api 的服务,由于它的请求到达以后必须快速响应用户,api 比较适合的。
作者介绍:
黄文俊,现任腾讯云 SCF 无服务器云函数高级产品经理,多年企业级系统开发和架构工作经验,对企业级存储、容器平台、微服务架构、无服务器计算等领域均有涉猎。
本文转载自公众号云加社区(ID:QcloudCommunity)。
原文链接:
https://mp.weixin.qq.com/s/m_veVWIqWHXq5f_mnIEDnA
评论