算法工程化算力方案设计

我们的根本需求其实有两点:

• 解决不确定的算力需求
• 解决算法同学工程化能力不足
• 解决后端同学集成难读过高

硬需求：

• 入口与流量
  • 流量可视化
• 进程/部署
  • 自动化算力动态扩缩
  • 自动化部署
• 健康观测
  • 指标收集与可视化
  • 服务健康查询
• 韧性

值得一提的是，任何一个硬需求部分都不是一蹴而就的，也许我们需要按照优先级先实现其中一部分，或者实现其中大部分的一个起点

方案A 内部常驻进程算力 + 队列调度

• 算法部分仅完成function 级别交付
• 队列调度部分仅完成task 级别交付
  • 上报观测指标
  • 日志记录
  • 幂等/重试/死信/回压
• 外部调用API
  • 提供RESTful API接口 （必备)
  • 提供统一认证机制 （可选： JWT/OAuth2）
  • 提供流量监控与调度 (接入到可视化的云负载均衡中) (必备)
  • 提供指标观测接口 /metrics ( prometheus) （可选)
  • 提供健康观测接口 /healthz /readyz (可选)

优点 :

• 解决方案可以通用化，可以封装成有价值的框架，方便后续其他接入
• 实现可拆解，按需引入 健康检测/日志收集/指标收集/可视化观测
• 难读适中
• 外部运维需求容易拓展
• 接入云厂商的动态负载较为容易
• 不依赖云厂商生态

缺点

• 周期较长
• 如果有多套服务需要治理，那么框架本身需要维护成本

方案B docker 封装的 serverless api 服务

• 将环境与代码共同打包至docker image中
• 使用serverless框架自动部署docker image至云服务

优点

• 云原生的动态算力扩缩
• 并发能力近乎无限
• 无需人工调整算力扩容参数

缺点

• 及其依赖云厂商能力 （包括日志/监控等)
• 要求封装较为严格，必须是

无论怎么选，我们一定要交付的三件事

1. 接入规范

• API规范: /invoke（同步）+ /jobs（异步）+ /healthz /readyz /metrics
• 交付规范: 必备的Schema：请求/响应/错误/metadata/version
• SLO规范：服务登记目标的规范 可用性，延时，吞度等目标的具体参数

2. 运行时

• Python SDK：完成参数校验、错误包装、埋点（耗时/失败率/队列延迟）、日志关联 ID
• Worker Runtime：统一处理重试、超时、取消、DLQ、回压

3. 手脚架

• 手脚架生成模板脚本 ：一键生成模板仓库：示例函数、Dockerfile、CI、部署 YAML、Grafana dashboard、告警规则
• 算法同学集成时紧要修改核心函数即可