《Apache Flink 案例集（2022版）》——5.数字化转型——翼支付Apache Flink 在翼支付的实践应用（上） https://developer.aliyun.com/article/1227825
生产实践
在实践过程中翼支付遇到了很多挑战，总结起来主要是业务 State 数据一致性、指标重复计算问题、动态规则配置以及全链路监控监控问题。
首先是指标作业升级过程中，通过指标引擎配置的 job State 数据一致性问题。早期指标作业是通过手动开发，部分业务 State 存储在 HDFS 中，指标引擎配置的 job 没有单独管理业务 State 的数据，老的任务迁移到平台过程中就会遇到数据一致性问题。
解决思路是扩展老的计算程序，读取全量 State 数据存储到外部，然后停止老任务。指标引擎配置的作业从指定的 offset 进行数据计算，然后从外部存储补齐原有的指标数据。
上图展示了作业升级的流程。Task 在 open function 的时候读取业务 State 数据存储到外部。如果是 KeyedState，则 State 接口无法获取当前 task 的所有 State 数据，需要将 State 对象进行向下类型强转，然后获取所有 State 数据指标引擎。作业通过配置指定对应的 offset，通过从外部补齐数据的方式进行指标计算，从而完成数据恢复。
其次是指标作业在不断新增过程中存在的痛点，多个作业重复消费同一个 Kafka 导致上游消费压力大以及指标重复计算的问题。解决方法是对所有作业进行统一优化，对所有消息源进行统一预清洗，按照业务过程分发到对应的数据域 Topic 中。对指标进行统一的口径管理，保证指标不重复计算。目前没有对实时指标进行分层处理，主要为了避免在计算链路过长从而影响业务的时效性。
第三是Flink CEP 存在的问题。实时决策的模块是通过 Flink CEP 进行规则匹配，最初是通过程序编码的方式实现规则的匹配，然而随着规则越来越多，不便于维护，开发成本也随之增加。Flink CEP 无法进行动态的规则配置以及多个规则并行决策。针对上述问题，翼支付对 Flink CEP 进行了扩展开发来解决规则动态配置以及多个规则决策的问题。
上图展示了 Flink CEP 扩展开发的逻辑架构。用户通过 RuleManager 配置规则并将规则变更事件发布到 Zookeeper 中，RuleListener 监听到事件的变更后，若是新增规则，则会通过 groovy 动态语言编译生成 RulePattern 实例。随着规则的增多，CEP operator 线程处理效率会下降，需要通过把规则分组绑定到对应的 Worker 上来加速规则处理。CEP operator 线程接收到事件后会分发给所有 Worker，Worker 线程处理完后通过队列发布到 CEP operator 线程，最后发布到下游。
最后是数据全链路监控的问题。数据流从收集端经过 Flume 传输，再到消息中心指标计算，然后发布到下游的实时决策，不允许大量的数据丢失以及数据延迟。基于以上诉求，需要对整体数据链路进行监控，采用 prometheus + grafana 进行 metrics 的收集以及告警。这里主要针对 Flume 消息中间件进行消息堆积以及丢失的监控。Flink 指标计算主要监控运行状态以及背压情况，下游监控 CEP 决策的时间。对数据链路的监控能够帮助运维快速定位并解决线上的问题。
未来规划
未来，翼支付计划在以下几个方面进行持续探索：
第一，数据库增量采集的方案统一。目前 MySQL 的采集是使用 Canal 实现的，未来计划使用 Flink CDC 来针对 Oracle 和 MySQL 进行统一的增量采集；
第二，离线实时的批流融合。目前离线数仓通过 Spark SQL 计算，实时数仓使用 Flink SQL 计算，维护两套元数据以及不同的指标口径使得日常工作负荷很大，未来希望使用 Flink 来完成批流一体计算；
第三，Flink 作业自动扩容缩容。目前 Flink 无法进行自动扩容缩容，早晚流量变化较大，会导致较多的资源浪费，计算能力不足的时候只能通过人工进行作业扩容。未来希望基于 Flink 来实现自动扩容，降低运维成本。
