API 流量优化支持项目

背景

API 流量抓取，数据发送到 Kafka，通过 Flink 计算框架，实时关联策略规则，离线规则库，匹配计算，丰富规则结果指标，再将结果写入 clickhouse。 计算资源：单台，70G 内存 20 核 配置信息：200M 配置信息放在 ZK，还有部分离线配置库在 clickhouse 人员：3 位 Flink 开发同学

流程图

通过去现场贵公司相关技术人员的讲解，答疑，看了一遍代码，理出来一个目前测试代码的大概的流程图

瓶颈：

  • 性能瓶颈 压测要支持 3GB/s 的数据量，目前峰值能达到满足度百分之 56，会持续产生背压，目前压力位上不明确，性能还续提升一倍以上，遇到瓶颈
  • 稳定性瓶颈 任务在运行 4 个小时左右，可能会遇到内存 OOM，导致 Flink 计算进程宕掉

预期：

  • 时间预期：9 月 27 号之前提供优化版本，能通过压测，完成 POC 技术环节
  • 性能预期：性能提高一倍

可调整组件

不可变：clickhouse， 可变：zk，flink，kafka

整体目标

短期目标：提升一倍以上性能，能满足压测要求 长期目标：架构调整，达到生产级别的稳定业务线

方案

目前来看，还存在不少问题，比如组件搭配还需要优化，算子链过多，基建不完善等，资源有限等等，要想达到一个稳定性，高性能，生产级别的产品线，还有很大的差距。

几天的时间要做架构调整不太现实，投入时间杯水车薪，完不成改造，短期内只能是先锁定压力细节点，然后针对性的做一些优化调整。

支持方式

远程：

  • 提供远程支持
  • 方案信息传递
  • 提供 VPN 或者是代码访问权限，可以远程 review 代码。

现场：

  • 现场测试
  • 方案评估
  • 现场指导等

短期方案:

  1. 通过监控，火焰图等手段找到性能瓶颈
  2. 针对性的对性能压力点做优化
  3. 代码层面不影响计算逻辑，做部分的结构性改造来提升性能
  4. 通过参数等优化提升资源利用率

长期方案：

  1. 架构调整：从基建上入手，组件架构调整
  2. 业务流程：分析业务场景，针对性的出一套适合的流程，上下游可能要做一些调整
  3. 代码改造：架构，流程变化，代码层面随之改造
  4. 人员培训：实时计算思维培养，Flink 最佳实践
  5. 稳定性提升：完善运维周边组件及人员培训