第六期 | 谈谈从Serveless宏观发展到实际落地

扛把子_商
996 阅读8分钟

serverless是什么

Serverless字面意思是无服务，但并不代表再也不需要服务器了，而是指开发者不需要过多的考虑服务器的问题，计算资源作为服务出现而不是服务器的概念出现。 那么Serverlss，是对全部底层资源和操作的封装，让开发者专注于业务逻辑。

Serverless = FaaS(Frontend as a service) + BaaS(Backend as a service)

宏观谈云计算的进化史

我们通过下面这张图来看一下云计算最经典的进化历程。

  1. On-Premises: 裸金属时代。从最底层的那台机器开始，包括上传的虚拟化，操作系统、容器、运行时，开发人员都要去解决。而并不是买一台机器就完事了。并且是按机器付费。

  2. IaaS: 基础设施服务，Infrastructure-as-a-service。这里IaaS，那么云厂商提供机房、计算中心，作为云服务的最底层，开发者需要多少东西，厂商通过虚拟化的方式提供出来，用户需要多少来买就可以了。用户需要自己控制底层，实现基础设施的使用逻辑。按照使用量来计费。典型的厂商有Amazon EC2、Digital Ocean、RackSpace Cloud。

  3. PaaS: 平台服务，Platform-as-a-service。PaaS更近一步，抽象出操作系统、容器、运行环境，提供软件部署平台（runtime），那么开发者只需要关注自己的业务、应用，不需要关注底层。PaaS力度进一步降低，按照应用来收费，启动多少应用，收取对应的费用。典型的厂商有Heroku、Google App Engine、OpenShift。

  4. Serverless: FaasFunction-as-a-service是说厂商连应用这一层都可以帮助开发者来解决，那么开发者只需要关注自己的业务。付费方式为，用户有多少个函数，函数执行了多少次，按请求次数、资源占用市场、外网出流量来付费。比方说中午执行了1w次，晚上执行了200次，那么就会按照12000来进行收费，而不是按照整个虚拟机的方式来收费。 典型的厂商有AWS 的 Lambda、腾讯云、阿里云。

所以综上阶段可以看到，对于云计算这个产业来说，开发者的投入回越来越少，研发的成本也就越来越低。

并且云计算的发展历程，从物理机->虚拟机->容器->函数，就是一个以“业务执行”为力度的分配方式的转变过程。

无服务器云计算（Serverless Computing），几乎封装了所有的底层资源管理和系统运维工作，使开发人员更容易使用云基础设施。 它提供了一种方式，极大的简化了基于云服务的编程，犹如汇编语言到高级编程语言般的转换。

结合实际到我们的生产中

为什么要使用serverless

首先我们一定要考虑好一个问题，就是为什么我们要使用serverless，现有情况下项目开发上线也比较顺畅呀，我们从以下两个角度来分析一下：

  1. 减少资源成本: 一般集团内部会有大量的中后台系统、管理系统等。并且这些系统对于cpu的使用率都是很低的，5%左右甚至零点几，甚或是基本没有人访问。并且，集团分配的机器一般都是两个起，甚至可以申请更多，有的一开始有流量但是后面就没人用了，就会给集团造成大量资源浪费。所以使用serveless的第一大诉求就是减少资源使用成本。

    举个例子来说我们的业务每天都会有个流量小高峰，那么这个时候我们一定会按照高规格的流量来配置机器，所以其他时间就浪费了。那么在于Serverlsee的计算模型下面，是真正的按照使用量来计费的，按请求次数、资源占用市场、外网出流量。比如说中午执行了1w次，晚上执行了200次，那么就会按照12000来进行收费，而不是按照整个虚拟机的方式来收费。

  1. 职能进一步分化: 目前前端已经处在一个相对的瓶颈期，从最开始的切图、前后端分离、BFF全栈，那么我们是时候能被认可、能产出的方向，不仅仅考虑页面，也可以从整个应用去考虑整个架构/数据流，这对整体前端的职能有非常大的提升。

场景

  • 静态网站托管 结合云解析、SSL证书、CDN和COS等组件，快速支持静态网站托管）
  • 构建RESTful API（通过SCF云函数及API网关组件，轻松构建RESTful API，即可完成CRUD操作）
  • 部署全栈应用 通过以上两种方式并结合多个Serverless Components，帮助开发者更便捷地部署Serverless全栈Web应用
  • 传统低流量应用 中后台场景，有些甚至无人维护的应用，请求量很低但是又不敢下线，这时可以采用serverless架构减少对资源的浪费。
  • 小程序应用

目标

  • 函数体系能承载80%的传统应用的能力
  • 节省掉90%的低流量机器 我们可以通过这种方式为集团节省很大一部分成本。

如何做

我们可以考虑两种方式，怼一个大应用 vs 接口力度拆分 怼一个大应用做迁移，有些应用没人维护了，那么就可以直接通过一个包裹器，直接包裹出部署上去。 接口力度拆分，适合一些新应用，能够复用大部分传统能力的一个新的框架来支持函数。

demo

结合腾讯云的一个小demo示例，后端egg.js+前端vue.js，这里我将前后端工程放到一起，整体部署到一个serverless框架上面。

首先分别构建后端，前端项目 下面是整体的文件目录（构建的过程在此就不列了，采用配套的脚手架即可）：

创建配置文件serverless.yml，更多配置

# 后端配置
backend:
  component: "@serverless/tencent-egg"
  inputs:
    code: ./backend
    functionName: demo
    # 这里必须指定一个具有操作 mysql 和 redis 的角色，具体角色创建，可访问 https://console.cloud.tencent.com/cam/role
    role: SCF_QcsRole
    functionConf:
      timeout: 120
    apigatewayConf:
      protocols:
        - https

# 前端配置
frontend:
  component: "@serverless/tencent-website"
  inputs:
    code:
      src: dist
      root: frontend
      envPath: src # 相对于 root 指定目录，这里实际就是 frontend/src
      hook: npm run build
    env:
      # 依赖后端部署成功后生成的 url
      apiUrl: ${backend.url}
    protocol: https

如果没有安装serverless命令，我们需要全局安装一下

npm install serverless -g

部署

serverless

也可使用简写命令sls

部署成功后，控制台会跳出一个二维码，扫码成功后返回项目及部署成功的信息。

我在里面简单写了一下CRUD，主要用了云数据库功能，有需要的同学可参考。 下面是主要的controller部分

'use strict';

const Controller = require('egg').Controller;
const tcb = require('tcb-admin-node');

// TODO 这里的secretId/secretKey换成你自己的
const app = tcb.init({
  secretId: "xxx",
  secretKey: "xxx",
  timeout: "10000"
});

class UserController extends Controller {
	constructor(ctx) {
		super(ctx);

		this.bookCollection= app.database().collection("user");
	}
	// 获取user列表
	async index() {
		const { ctx } = this;
		const data = await this.bookCollection.get();
		ctx.body = data;
		ctx.status = 200;
	}
	// 查询一个user
	async show() {
		const { ctx } = this;
		const id = ctx.params.id;

		const data = await this.bookCollection.doc(id).get();

		ctx.status = 200;
		ctx.body = data;
	}
	// 创建user
	async create() {
		const { ctx } = this;
		const { name, age } = ctx.request.body;

		const result = await this.bookCollection.add({
			name,
			age
		});

		ctx.body = result;
		ctx.status = 200;
	}
	// 删除user
	async destroy() {
		const { ctx } = this;
		const id = ctx.params.id;

		const result = await this.bookCollection.doc(id).remove();

		ctx.body = result;
		ctx.status = 200;
	}
	// 更新user
	async update() {
		const { ctx } = this;
		const id = ctx.params.id;
		const { name, age } = ctx.request.body;

		const result = await this.bookCollection.doc(id).update({
			name,
			age
		});

		ctx.body = result;
		ctx.status = 200;
	}
}

module.exports = UserController;

简单快捷，当然如果你想要使用其他内容，包括登录、云存储、云函数、静态网站托管、日志等，欢迎阅读文档尝试。

serverless的难点与挑战

  • 不适合长时间运行应用
  • 完全依赖第三方服务
  • 冷启动时间
  • 缺乏调试和开发工具
  • 构建复杂
  • 语言版本落后

其实上述的一些问题还是可以通过一些方法来解决的，比方说冷启动，我们可以在我们的项目中做一些网络优化、预启动等。当然业界上也有一些比较流行的fass框架，比如OpenFaaS、fission、OpenWhisk、Kubeless，但是要做一个私有化的serverless，难度会很高。

面向未来

Serverless是一个非常适合前端去开拓和挖掘的一个新体系，因为本身很轻量，免运维，不需要去维护服务器，而更专注于业务逻辑。非常适合一些小公司或者开发者搭建自己的官网或者博客这种。小程序的体系也非常适合

不断的寻找新场景。比方说基于已有的SSR系统、怎样将传统技术栈迁移上来，性能优化（极速启动）怎样能让系统启动更快。

感谢

感谢前端早早聊给予的课程，以及大佬们细心的讲解。本篇文章是基于以上的课后总结，突然发现自己的视野太狭隘了，还是要多听多看多试，加油！

如果我的文章能够解惑或者带来一些启发，请点个小心心吧～

前端早早聊大会目标成为用得上、听得懂、抄得走的技术大会，计划 2020 年办 >= 15 期，由前端早早聊与掘金联合举办，前端早早聊大会行程动态、录播视频/PPT/讲稿资料下载请关注 「前端早早聊」 公众号跟进。 5 月 30 日举办第七届 - 前端如何搞微前端，报名请戳：www.huodongxing.com/go/tl7 ，海报及讲师行程如下：

5 月 31 日举办第八届 - 前端跳槽的新攻略，报名请戳：www.huodongxing.com/event/25439… ，海报及讲师行程如下：

avatar
文章
阅读
粉丝