2020-11-07

最近接手了一个融合日志的服务. 经过梳理, 我认为当前服务的设计上存在缺陷. 与 Leader 开会讨论后, 决定重新进行技术方案调研, 最终我们选择使用 Flink 重构了该服务.

目前重构后的服务已成功经受了国庆节流量洪峰的考验, 今日特来总结回顾, 和大家分享一下经验.

业务需求及背景
首先我们要明确, 我们要解决什么问题以及目前的服务是如何解决的.

当前的业务逻辑还是比较清晰的:

采集同一时段不同数据源的日志.
对采集的数据进行处理.
将处理后的数据上传到指定位置, 供客户下载.
我们面临的痛点和难点:

日志的量比较大, 每小时未压缩日志在 50 多个 G 左右; 如果是节假日等特殊时间节点, 日志量一般都会翻倍.
目前服务使用单机进行处理, 速度比较慢, 扩容不方便.
目前服务处理数据时需要清洗字段, 按时间排序, 统计某字段的频率等步骤. 这些步骤都属于 ETL 中的常规操作, 但是目前是以代码的形式实现的, 我们想以配置形式减少重复编码, 尽量更加简单, 通用.