# convoy-design-flow

**Repository Path**: erchoc/convoy-design-flow

## Basic Information

- **Project Name**: convoy-design-flow
- **Description**: 网关运行时的设计流程
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2024-02-08
- **Last Updated**: 2024-02-08

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

1. 为什么基于 Koa 来做上层框架?

> 执行 1-koa 文件再看看代码, 体会一下洋葱圈请求-响应模型在扩展性上的优势。
> 请求和响应阶段, 允许开发者插入任意执行函数, 用于拦截请求或封装响应内容。
> 这个设计具备极强扩展性, 很方便对 请求-响应 模型进行前置和后置能力的扩展。

2. 为什么不基于 Koa 来做上层框架?

> Koa 本身过于简洁, 水平较好的团队完全可以从零实现, 水平较差的团队没有能力将上层模块封装好。
> 你可以通过 2-compose 文件了解 koa 洋葱圈实现的基本原理: 通过 koa-compose 将中间件串联起来。
> 对于能力较差阶段, 可以基于 express/fastify 等含有日志、插件、错误处理等基础功能的框架进行封装, 但后续你可能会觉得他们略微有点重。

3. 所以我们怎么基于 Koa 改造洋葱圈模型呢?

> Koa/Express/Fastify 等框架的中间件, 都没有动态启停控制功能, 所以我们得自行封装一层"插件"概念。
> 我们允许不同的中间件在运行时进行流程编排, 类似 NodeRed 的设计: 流程编排并发布实时生效。
> 可以查看 3-cube 和 4-cubeflow 文件, 我们就这样简单实现了 NodeRed 的可视化编排能力。

4. 网关需要接配置中心, 应该怎么做?
> 考虑到网关以后会存在不同的部署环境, 我们至少要支持 HardCode、K8sYaml、环境变量、Consul、Apoll、Nacos 等多种配置中心。所以打算封装一层 configAdapter 来抹平差异。ConfigAdapter 应该是个抽象类, 定义具体的能力, 由对应的 EnvConfigAdapter、FileConfigAdapter 来实现对应接口。
> 配置中心要支持数据加密存储、配置下发、权限控制、下发通知等常见功能。
> 后续将沉淀为配置中心接入模块, 以供所有 Node 应用接入。

5. 网关需要有路由/接口的配置、加载和执行能力
> 动态执行 JS 代码这个功能已经用的很普遍了，核心就是尽可能隔离、安全。所以目前一般都在使用 vm、vm2、docker 这几类隔离方案。
> TS 转 JS 需要用到 typescript 运行时依赖, 以后也可以借助 Rust 实现扩展其他语言在线编辑打包功能。

6、插件代码应该如何存储, 是和接口配置一样存 db 长字符吗
> 考虑到插件在调试完成后基本就锁版本不再变更, 我们更倾向使用 npm 包来维护, 这里可以封装个 BaseDataAdapter 来适配不同插件代码的存储方式。
> 目前需要支持从 File、NPM 和 Redis 中读取用户插件代码,


7. 这不仅仅是 API 网关, 也要实现 Nginx Proxy 能力。
> Nginx/Ingress 规则配置对前端而言较为麻烦, 规则较多对性能影响大。
> 所以我们要实现 Proxy 功能, 建议用户在 Node 网关层面配置请求代理。 
> 通过封装 http-proxy 的能力, 暴露特定的代理功能和参数给业务方使用。
> 可执行 6-proxy 文件并访问, 你会发现请求 koa 服务被代理到百度官网。
> 网关会统计代理性能, 这个功能本质是给 SSR 场景使用的。