实时业务场景技术解决方案

项目背景

来自业务需求，简单来说根据用户的实时行为，进行统计计算，达到一定要求后，实时给用户下发小奖励。这是公司第一个业务实时计算类的需求，并整体交给服务端来承接。

公司日活百万，业务的实时数据量为每天大几千万，会有晚上的流量小高峰。

技术选型

由于当时并不具备Flink等实时计算框架（flink经过后续学习，作为技术优化解决方案）采用传统的服务端技术：

Java + SpringBoot + Kakfa + Redis + MQ + TiDB + EasyRules + （Flink）+ 长链接服务

长链接服务在“Netty实战” 文章里有详细介绍。

总体架构设计

1、数据源

用户的在我们的APP上实时产生的行为数据，作为主要的数据源，当前通过统一的埋点服务，会将这些行为数据推送到指定的Kafkfa上。还有一部分用户的数据为业务数据，由业务服务提供。

2、数据接入层

规划统一的业务数据接入层，用来承接所有的外部数据源，根据不同的业务需求，过滤不同场景的业务数据，并将原始的数据落库，存入TiDB。同时将数据通过Kafka下推到服务计算层。

3、数据计算层

数据计算层，首先根据业务需求，设计不同业务维度的数据表，将业务数据实时高效的计算写入不用的业务表中。同时将计算后的数据，组装好后，下推到数据规则引擎层。

4、数据规则引擎层

为了更好的用户体验和产品使用体验，可以灵活支持奖励规则的动态配置并可以实时生效，于是调研了相关规则引擎，（之前并没有太多的相关经验）。调研了easyRules和drools，最后选用了easyRules作为规则引擎，通过demo的测试验证，结合业务场景，输出规则的定义模式，匹配到业务规则管理端（CMS）。

当接到数据计算层下推来的业务数据后，将数据推到规则引擎模块，匹配出用户获得不同奖励，再次通过MQ将最后的业务数据推送到下游相关业务服务。

5、业务接入层

业务服务接到规则引擎层推送的业务数据，进行数据的存储，同时将奖励通过长链接服务实时推送到客户端。

6、数据检索层

技术赋能业务。业务有了上面的业务数据多维度的计算存储，在面对C端业务产品需求时，可以更从容面对。一些业务场景需要用户的实时不同维度数据，对性能要求极高响应时间（100ms）.于是便搭建了业务数据检索服务，所有的业务数据查询走Redis。同时业务数据由TiDB的binlog 通过TiCDC写入到Kafka，再由Kafka通过Cache服务写入到Redis。

架构设计

7、数据容错

1、首先保证Kafka、TIDB、MQ等中间件及存储服务的高可用性，稳定性。

2、微服务下，要考虑每个处理层、每个节点都有可能出现问题，当出现问题时，要思考补偿模式，来最大程度减少降低对业务的影响。（这里不做过多介绍，需要结合具体业务来针对性输出方案）

3、持续的迭代，循序渐进改进！

小结

1、在业务高峰期，数据接入层下推的数据会有积压告警，为了业务计算层处理能力，引入了动态线程池，不用业务流程计算单独开辟线程池组，提高业务处理处理能力。

2、搭建Flink计算服务，数据接入层数据推送到Flink计算服务，通过按用户，按业务属性分组开窗口计算组合，再将数据下推到数据计算层，来减少数据处理压力。

3、不同业务维度的数据表，采用不同的存储方案，提升存储及检索效率。

4、结合实际的业务需求，仍在持续的迭代优化！

项目代码示例

后续补充维护