TL;DR

「五」更乏味一点

一、概念梳理

  1. 前情提要，@midway/faas 是原生 serverless 模式的开发，然而目前还在演变中，集体的应用体验是离成熟还挺远
  2. 我想要的是 @midway 的语法糖，和原生 serverless
  3. deployType: egg 从外观上看满足了这个要求

二、锁版本

# dep@midwayjs/cli@1.2.32@midwayjs/decorator@2.4.7@midwayjs/web@2.5.4egg@2.29.1egg-scripts@2.13.0egg-view-nunjucks@2.2.0# devDep@midwayjs/egg-ts-helper@1.0.4# 局部不影响本文但确是外围的依赖并没有列出来

三、提供接口

  1. 规范 egg 利用目录构造，没有特地的，把你的旧代码复制过去就能用
src/  app/    controller/      api.ts  config/    config.default.ts# app/controller/api.ts@Provide()@Controller('/')export class ApiController {    @Inject()  ctx: Context;  @Inject()  dataService: DataService;    @Get('/api/fetch-data')  async fetchData(@Query('pn') pageNo: number=1, @Query('ps') pageSize: number=10) {    const { page, data } = await this.dataService.fetchData(pageNo, pageSize);    return { code: 0, message: 'ok', page, data };  }}
  1. package.json 要害配置：要指定 framework 为 @midway/web
"scripts": {  "start": "egg-scripts start --title=bilibili --framework=@midwayjs/web --env=prod",  "dev": "cross-env ets && cross-env NODE_ENV=local midway-bin dev --ts"},"egg": {  "framework": "@midwayjs/web"},
  1. package.json 要害配置：ts 要手动构建，这里把钩子设在了生命周期的公布前阶段
"midway-integration": {  "lifecycle": {    "before:package:cleanup": "npm run build"  }},
  1. f.yml 要害配置：deployType: egg
  2. f.yml 要害配置：能够按前缀将一类申请都指向这个服务
functions:  myservicename:    runtime: nodejs12    handler: index.handler    events:      - http:          path: /api/*    environment:      FORCE_COLOR: 0

四、提供动态资源

  1. 和三实际上是一样的，这就是 deployType: egg 美好之处，能够了解为后端真的起了一个 egg 利用，而不是像 faas 模式那样封装了一个长得很像 egg 的货色
# f.yml 概念代码，理论配置参考三functions:events:- http:  /api/*  /public/*

五、那这不就是一般的 egg 吗，套娃了？

  1. 最近反微服务反中台的论调又多了起来，我司执行微服务（伪）中台（伪）也挺久了，最直观的感觉就是，对微服务种种的不称心，解决方案都是还不够微，粒度还是太粗了
  2. 老板说前端要千人千面，千是个虚指，翻译过去实际上是 2 亿人 2 亿面，仿佛很有情理无奈反驳，然而后端就区区 300 个利用就开始闹合并了，什么 SOLID / DRY 都来了，为啥呀
  3. 很多探讨 serverless 的文章都说是为了节俭估算，而后反驳的文章都说实际上没有节俭估算，300 个利用换成 300 个 serverless 当然不省估算，然而 2 亿个呢
  4. Serverless 是一种思维状态，它能让你更专一于解决眼前的问题，而不被原有代码影响，因为这里只有以后的代码，没有其它代码
  5. 解决需要变更的最好的形式，就是按需要免费，来一个需要做一套「零碎」，而后等那些没有流量的「零碎」天然淘汰

  1. 抉择 traefik 的起因是它自带的 docker 模式很好用
  2. 抉择 envoy 而不是 nginx 的起因是看上去前者应该就是将来了
  3. 终端客户认为本人购买了一个产品的四种性能，但实际上这四个性能是由四个独立团队别离开发的

六、为什么 serverless 这个事件是前端的同学比拟上心

  1. 因为前端长年以来就是以「需要」为粒度开发的，「npm」的体量和品质就是很好的阐明，正是因为有很多低质量的包，才阐明这是一个沉闷的市场；而且那些低质量的包，很有可能在某个场景粒度是性价比最好的
  2. serverless 岂但能够让前端疾速地响应客户的需要，也能够让中台更疾速地响应前端的需要
  3. 甲方爸爸永远是对的，服务数量指数式激增管不了是乙方本人的问题

七、一些小技巧

  1. 同时开 n 个我的项目，node_modules 真的很占空间，所以必须要上 lerna 了
# 目录构造packages/  appa/    package.json    f.yml -> service: myappname, function: appa, path: /a/*  appb/    package.json    f.yml -> service: myappname, function: appb, path: /b/*lerna.json# 在根目录执行$ lerna run dev --scope appa --stream$ lerna run deploy --scope appa --stream
  1. 阿里云函数计算的日志是以 service 为单位的，所以上述多个 package 子利用的日志局部配置必须统一，否则会相互笼罩
# f.yamlservice:  name: myappnameprovider:  name: aliyun  logConfig:    project: myprojectname    logstore: myappname

参考文献：

  1. Egg/Midway 利用迁徙
  2. Serverless 是一种思维状态

系列文章：
阿里云函数计算（Midway FaaS）一探
阿里云函数计算（@Midway/Egg-Layer）二探