Skip to main content

聚合部署

Midway 针对 HTTP 场景，提供了一种聚合部署的方式，在开发时和传统 Web 应用类似，在部署时将多个路由部署在同一个函数容器中，可以节省冷启动时间，节省费用。

聚合部署模式特别适合用于传统中后台服务。

创建代码#

创建聚合部署的代码示例。

$ npm -v
# 如果是 npm v6$ npm init midway --type=faas-aggr my_midway_app
# 如果是 npm v7$ npm init midway -- --type=faas-aggr my_midway_app

也可以执行 npm init midway ，选择 faas-aggr 脚手架。

info

该脚手架针对 HTTP 的场景做了特殊处理，会将所有的 HTTP 接口部署为同一个函数（聚合部署）。

目录结构#

以下就是一个函数的最精简的结构，核心会包括一个 f.yml 标准化函数文件，以及 TypeScript 的项目结构。

.├── f.yml           # 标准化 spec 文件├── package.json    # 项目依赖├── src│   └── index.ts    # 函数入口└── tsconfig.json

我们来简单了解一下文件内容。

  • f.yml   函数定义文件
  • tsconfig.json tsc 配置文件（没有 IDE 会报错）
  • src 函数源码目录
  • src/index.ts 示例函数文件

函数文件#

我们首先来看看函数文件，传统的函数是一个 function ，为了更符合 midway 体系，以及使用我们的依赖注入，这里将它变成了 Class。

和传统应用相同，我们依旧使用 @Controller 装饰器来开发聚合的 HTTP 函数。

如下代码，我们暴露了三个路由，在聚合部署模式下，会只部署成一个 HTTP 函数：

import { Inject, Provide, Controller, Get, Post } from '@midwayjs/decorator';import { Context } from '@midwayjs/faas';
@Provide()@Controller('/')export class APIService {  @Inject()  ctx: Context;
  @Get('/')  async hello() {    return 'Hello Midwayjs';  }
  @Get('/get')  async get() {    return this.ctx.query;  }
  @Post('/post')  async post() {    return this.ctx.method;  }}

函数定义文件#

f.yml 是函数的定义文件，通过这个文件，在构建时生成不同平台所能认识的文件，示例中的文件内容如下。

service:  name: midway-faas-examples ## 函数组名，可以理解为应用名
provider:  name: aliyun ## 发布的平台，这里是阿里云
aggregation: ## 对 HTTP 函数使用聚合模式部署  all: ## 部署的函数名    functionsPattern: ## 匹配的函数规则      - '*'

本地开发#

HTTP 函数本地开发和传统 Web 相同，输入以下命令。

$ npm run dev$ open http://localhost:7001

Midway 会启动 HTTP 服务器，打开浏览器，访问 [http://127.0.0.1:7001](http://127.0.0.1:7001) ，浏览器会打印出 Hello midwayjs   的信息。

本地测试#

使用和应用相同的测试方法来测试，针对 HTTP 函数，使用封装了 supertest 的 createHttpRequest 方法创建 HTTP 客户端。

唯一和应用不同的是，使用 createFunctionApp 方法创建函数应用（app）。

createFunctionApp 方法是 createApp 方法在函数场景下的定制（其中指定了函数的 @midwayjs/serverless-app 框架）。

info

这里不直接使用 @midwayjs/faas 框架，而是使用 @midwayjs/serverless-app   框架，因为后者包含了网关模拟到函数调用的系列步骤。

HTTP 测试代码如下：

import { createFunctionApp, close, createHttpRequest } from '@midwayjs/mock';import { Framework } from '@midwayjs/serverless-app';import * as assert from 'assert';
describe('test/index.test.ts', () => {  it('should get /', async () => {    // create app    const app = await createFunctionApp<Framework>();
    // make request    const result = await createHttpRequest(app).get('/');
    // use expect by jest    expect(result.status).toBe(200);    expect(result.text).toBe('Hello Midwayjs');
    const result2 = await createHttpRequest(app).get('/get').query({ name: 123 });    // or use assert    assert.deepStrictEqual(result2.status, 200);    assert.deepStrictEqual(result2.body.name, '123');
    // close app    await close(app);  });});

和纯函数的区别#

普通的函数，会将单个的函数注册到特定的路由上。客户端请求的流量，会分别打到不同的函数实例上，这样的好处是每个接口对应的函数实例数量可能都是不同的，调用多的接口，实例就多，调用少的接口就会少。

坏处就是，如果调用量较少，函数的冷启动概率就大，调用的时间会明显变大，由于每个函数都会有开销，资源没有复用，最终的收费也会变多。

而聚合部署，会将所有的路由都注册到 /*  路由上，由框架内部的路由代码进行分发，所有的函数共享同一个容器，任意的请求都会让这个容器保活，使得冷启动的可能性大大减少。同时，由于代码是复用的，容器的复用率大大增加，比较适合于中后台这类请求均衡且接口的调用量相对均衡的场景。

函数名规则#

使用聚合模式部署的函数，我们一般使用 @Controller  装饰器或者一体化方式进行开发，和传统 Web 开发、测试保持一致。

在构建时，我们会生成 f.yml  中的 functions  字段，一般情况下用户不需要关心函数名，接口等信息。

在使用 @Controller  装饰器的情况下，生成的函数名规则为 providerId_methodName ，即依赖注入的 key 和方法名的组合。

比如：

@Provide('userService') // <--- 取的是这个名字，如果不填，默认是类名的驼峰形式@Controller('/api')export class UserService {  @Get('/get/:id')  async getUser(@Query() name) {}
  @Post('/create')  async createUser(@Query() name) {}}

构建时会自动生成 userService_getUser  和 userService_createUser  两个函数并做内部路由处理。

下面是生成的 YAML 伪代码（实际由于是聚合部署，变为内部路由，并不会创建这段代码）。

functions:    userService_getUser:    events:        - http:          method: get          path: /get/[:id]  userService_createUser:    events:        - http:          method: post          path: /create