Flink时间窗口的机制解析详细的时间窗口分析

转载自博客：https://www.fintechinchina.com/cases/4824

https://www.fintechinchina.com/cases/4824

相当的经典

 flink具有日志清理和日志聚合的任务，清理的数据存储带到es集群中，聚合的时候存储在mysql的数据库中

这种采集方式有效的避免了因数据采集失败或采集代理资源过度消耗而产生的对被监控对象的性能干扰。在数据处理方面，因消息异步推送机制的存在，将监控对象业务活动和监控系统内部数据处理进行了解耦，实现了微服务调用流水信息的旁路采集，在本系统中进行的监控数据采集和处理活动不介入原交易（微服务调用）业务处理逻辑。

同时，此种采集模式为应用性能监控系统的采集扩展提供了便利。必要时，可以对接不同的注册中心、第三方的监控数据，实现对采用分布式架构的其他技术平台监控数据的敏捷接入。

 

2.高吞吐、低延迟的数据多维处理

随着我社以网点智能化转型项目为代表的数字化转型工作不断推进，陕西信合分布式技术平台上承载的微服务数量将不断增多，本系统所监测的交易数据（微服务调用流水）量也会成几何式增长。为减少本系统在处理海量交易数据流水时的数据延迟，大化发挥实时监控的价值，通过反复比较和验证，我们终选择开源的流处理引擎Flink作为本系统的实时数据处理组件。考虑到实时数据处理组件对并发处理能力和组件可用性要求较高，我们对其部署架构进行了高可用、高扩展性的集群设计。

 

此外，项目组根据实际场景需要，对Flink进行了接口改造和个性化功能封装。通过系统上线前的非功能测试实测，目前分布式技术台监控系统已确认可支持2W笔/秒的实时数据处理计算。

 

3.有效的延迟数据补偿机制

在本系统对实时交易数据的处理过程中，由于微服务调用流水信息中存储的各类时间信息为微服务实例所在主机的本地时间，微服务通讯SDK组件在向分布式技术平台注册中心组件进行微服务调用流水信息上传时采用异步通讯机制，故本系统在接收分布式技术平台注册中心所推送的微服务调用流水信息时，无法完全保证这些信息是严格按照时序排序的。按照一般应用性能监控系统对流式数据处理的逻辑或惯例，往往在聚合周期内进行窗口数据聚合时，对这部分错序数据将按当前处理窗口时间而非交易实际应对应的窗口时间标识，导致应用性能曲线绘制不精确，出现预期外的畸变点（曲线毛刺），一定程度上影响了应用性能监测效果。在传统的各类应用性能监控系统（APM）中，因为采集点分布在不同设备或主机上，在异步数据处理的机制下，亦会出现同类问题。

 为有效的规避上述问题，项目组通过对陕西信合分布式技术平台上承载的交易数据（微服务调用流水）进行充分的调研分析，通过自主创新的时间补偿机制设计，对部分监控采集数据的错乱时序进行准实时修正。基本实现原理如下：通过调研发现，数据可能会存在0~3秒内的正常延迟（由于异步数据处理机制导致），或大1分钟的异常延迟（如功能接口响应超时），因此在聚合窗口处理数据的时候，对于延迟小于3秒的正常延迟数据，首先比对待处理交易的实际发生时间与当前聚合窗口的窗口时间（窗口期内所处理的晚交易时间作为当前窗口时间），若不匹配，则将已错过聚合窗口的数据放至初聚合缓存区内，并通过独立线程定期将缓存区内的数据与其真实交易窗口内的其他交易数据进行重新聚合，并刷新性能曲线，以此来进行曲线修正，通过以上机制能够及时修正正常延迟导致的错序数据。同时，为了保证数据处理的性能，大于3秒的异常延迟数据会通过新增聚合周期结果，在数据消费时通过逻辑计算进行数据修正。通过对于不同延迟类型的不同处理机制，既保证了新的交易聚合周期95%的数据及时性，也同时保证数据时间准确性达到100%，同时极大的提高了Flink任务处理数据的效率，保证了监控数据的有效性和实时性。

 

4.智能化监控-交易调用链

包含陕西信合在内的中小金融机构一直以来在分布式系统运维面临一个难题，即：当交易出现问题时，如何快速、准确的从成百上千的应用节点及微服务实例中，找到异常的节点。为了解决这个难题，陕西信合分布式技术平台充分发挥在建设初期定立的微服务交易报文头规范的标准定义价值，通过全局流水号在注册中心组件内，对单笔交易进行了链路追踪。链路追踪具体实现原理如下：

 

分布式技术平台通过交易的全局流水号将一笔交易的所有数据关联起来，根据交易的请求流水号和源请求流水号，确定每个应用节点两两之间的调用关系，描绘出每一笔交易的调用链，达到调用关系可视化的效果。

通过使用【查看交易调用链】功能，运维人员可以快速了解到交易的调用过程以及涉及到应用节点。当业务交易出现问题时，对应的交易链路图中的节点会变为红色，同时将鼠标悬浮到节点上，即可定位到问题节点。此外，通过交易调用链，可以调转到日志查询页面，将交易的全局流水号作为查询条件，对应用日志进行全文检索。用户亦可以自定义查询条件，对应用日志进行全文检索，点击操作栏中的“上下文”查看有问题的节点的日志数据。而本系统通过功能集成的方式引入了该项功能。用户在进行应用性能曲线观测时，可通过在交易曲线界面选中想进行详细探查的数据点，系统将根据选中的数据点时间，查询此区间的所有交易明细。用户在查询结果中可以指定交易条目，通过使用【查看交易调用链】功能，通过调用分布式技术平台内置的链路查询功能，查看每一笔交易在全生命周期中的微服务调用情况，了解业务交易的处理流程，从而实现对我社分布式技术平台上承载的各类应用系统的交易数据从“宏观”到“微观”的多视角监测。

 

 

5.智能化监控-业务场景监控

在分布式技术平台上落地的各类业务场景中，具体业务处理逻辑的调用链条深度、广度，往往会贯穿多个能力中心或外围系统，且单一业务场景上的微服务之间的调用关系错综复杂，加大了运维人员故障定位的难度。单纯依靠传统运维模式中通过调阅业务流程设计文档或者其他辅助文本资料来确定该业务场景的微服务调用链条设计，从请求发起首系统开始进行依次分析，采用传声筒式的故障定位和排查模式，将耗费大量人力物力。且随着业务逻辑的高速迭代，业务场景的微服务调用链路通过人工维护的有效性难以保证。

 

为降低各业务场景下微服务调用链路的人工维护成本，提高链路的精确性、可用性和及时性。本系统通过对存量离线数据进行持续学习，使用核心算法，依照不同的数据可信度使用差异化的链路拓扑生成机制。在高可信度数据满足的条件下，系统将持续自动分析和学习存储微服务调用流水信息中微服务调用关系，沉淀生成该业务场景下的微服务调用链路信息，并依据指定算法规则生成指定场景下的业务微服务调用链路拓扑。对低可信度数据，系统将根据可信度等级将预生成的微服务调用链路推送至人工确认环节或直接支持管理员维护业务拓扑脉络。以此解决数量众多、分支脉络复杂、频繁迭代的业务场景调用链路拓扑。

 

同时，为了实现更全面的监控业务场景，本系统将业务场景下的服务调用链路和实时监控数据进行了较好的融合。系统在简洁宏观的业务链路图上以流速、流量、颜色等方式实时展示各链路节点对应的微服务的交易量、交易响应时间、交易成功率等关键性能指标，使得监控人员更加直观快速的监测当前业务中交易量的趋势、交易耗时的快慢、成功率的高低。同时，为了解决上述视图下业务的调用顺序、调用层级无法良好体现的弊端，通过业务调用图按照由上而下体现调用顺序、从左至右体现调用层级，并加以数据过滤器，便于回溯任何时段中业务各调用层级的运行情况。