美团点评酒旅运营需求在离线场景下，已经得到了较为系统化的支持，通过对离线数据收集、挖掘，可对目标用户进行T+1触达，通过向目标用户发送Push等多种方式，在一定程度上提高转化率。但T+1本身的延迟性会导致用户在产生特定行为时不能被实时触达，无法充分发挥数据的价值，取得更优的运营效果。
在此背景下，运营业务需要着手挖掘用户行为实时数据，如实时浏览、下单、退款、搜索等，对满足运营需求用户进行实时触达，最大化运营活动效果。在运营实时触达需求中，存在如下具有代表性的业务场景：
本文以该典型实时运营场景为例，围绕如何设计出可支撑业务需求高效、稳定运行的系统进行展开。
为解决早期方案中出现的问题，对系统建设提出了以下挑战：
针对以上挑战，结合业务规则特点，美团点评数据智能团队调研并设计了酒旅运营实时触达系统。
前面已经提到，美团点评酒旅运营需求在离线场景下，已经得到了较为系统化的支持，通过对离线数据收集、挖掘，可对目标用户进行T+1触达，通过向目标用户发送Push等多种方式，在一定程度上提高转化率。但T+1本身的延迟性会导致用户在产生特定行为时不能被实时触达，无法充分发挥数据的价值，取得更优的运营效果。运营业务需要着手挖掘用户行为实时数据，如实时浏览、下单、退款、搜索等，对满足运营需求用户进行实时触达，最大化运营活动效果。对比若干开源实时计算系统，我们最终选择了Flink作为我们的实时计算系统，主要原因在于几点：
Flink作为第三代大数据计算引擎(第一代为Hadoop及周边计算引擎，第二代为Spark，第三代为Flink)，其流式方面相比于Spark有绝对优势，包括完整窗口语义、乱序数据处理、复杂事件处理等等。
Flink提供针对流式处理完备的SQL/Table/DataStream，之前在Storm和Spark任务上大量的底层代码开发全部可以使用SQL来解决，进一步提升了流式任务开发效能。
提高灵活度需要从业务规则和系统代码解耦和入手，规则和代码耦合直接导致了重复代码增多、业务规则修改困难等问题。那如何将业务规则和系统代码解耦和呢？我们想到使用规则引擎解决这一问题。
规则引擎是处理复杂规则集合的引擎。通过输入一些基础事件，以推演或者归纳等方式，得到最终的执行结果。规则引擎的核心作用在于将复杂、易变的规则从系统中抽离出来，由灵活可变的规则来描述业务需求。由于很多业务场景，包括酒旅运营实时触达场景，规则处理的输入或触发条件是事件，且事件间有依赖或时序的关系，所以规则引擎经常和CEP（复合事件处理）结合起来使用。
我们对业界已有的规则引擎，主要包括Esper和Drools，进行了调研。
Esper设计目标为CEP的轻量级解决方案，可以方便的嵌入服务中，提供CEP功能。
Drools开始于规则引擎，后引入DroolsFusion模块提供CEP的功能。
以上两个问题在Flink的CEP已经能够解决，因此我们考虑使用FlinkCEP作为规则引擎实现的基础。由于我们最终是基于阿里云平台构建我们实时推送平台，最终选择使用阿里云实时计算Flink作为我们的基础计算引擎，相比于社区而言，云上FlinkCEP已经具备SQL表达能力，因此我们可以更加简单使用上FlinkCEP功能。
确定引入规则引擎后，围绕规则引擎的设计开发成为了系统建设的主要着力点。通过使用实时数据仓库中的用户实时行为数据，按业务运营活动规则，组合成有意义的复合事件，交由下游运营业务系统对事件的主体，也就是用户进行触达。将系统抽象为以下功能模块:
规则配置基本实现由业务分析师、产品经理或运营人员自助完成。
规则配置系统是基于FlinkSQL之上提供了一层规则的封装，方便大量对于底层大规模分布式流式处理原理不明白的业务人员使用我们的规则系统。该规则系统将常见的规则计算逻辑封装为一个个独立的组件，使得上层业务人员可以仅了解业务流程即可实现规则编排。
考虑到仍然有部分非常复杂的业务规则，使用界面方式不易表达，我们仍然保留了FlinkSQL作为业务人员编写规则入口，确实有部分高级业务人员和技术团队愿意使用SQL作为规则编写方式。
这部分是运行的核心逻辑，规则系统编排的所有规则(排除直接使用FlinkSQL的规则)将翻译为底层FlinkSQL并提交到底层实时计算系统。