新版tulip实施方案

新版tulip实施方案

背景：

基于《新版推广运营方案》的内容设计出新版的运营推广系统，针对里面涉及到各种业务场景提出各种解决方案，而目前最大的问题在于系统的边界划分，主要存在两种情况：

1. 业务数据在业务系统（mimosa）和运营推广系统（tulip）都存一份， 通过事件监听（也就是代码埋点），但是这样做出现：

1.这样tulip系统存在业务数据， 导致tulip系统的职责不够单一明确。
2.也正因为如此与其他系统耦合度太高，如将来对接借贷等其他系统还得修改代码埋点，不利于tulip系统的可扩展性。
3.另外人工干预的异常处理导致数据不同步，如对账定单处理、数据修复等。

1. 基于以上问题，可以考虑业务数据只存放在业务系统（mimosa）一方，推出如下三种解决方案：

方案一：

说明：原业务数据存储在mimosa中，tulip接受事件后根据活动规则需要的数据，通过第三方报表系统执行统计sql获取数据并处理优惠券活动。
业务边界：

优点：tulip与mimosa系统职责分离，复杂业务计算由第三方统计系统灵活拼接sql，最终在原数据库mimosa查询。 

方案二：

说明：原业务数据按目前模式在mimosa系统做统计，tulip接受事件后，通过报表系统执行查询sql获取数据并处理优惠券活动。 

业务边界：

优点：tulip与mimosa系统职责分离，参与者业务数据的统计由mimosa自己完成，tulip系统只负责针对活动规则查询需要的数据处理。

方案三：

说明：原业务数据通过主动监听mimosa库的binlog日志，存入如mysql/mangodb等适合查询的库中，tulip查询mysql/mangodb数据处理优惠券活动。
业务边界图：

优点：tulip与mimosa系统职责分离，数据同步不用代码埋点，而是通过对db的binlog日志监听数据同步，tulip最终只与三方库交互。 

报表/统计系统设计：
功能：1，连接业务数据库
2，根据业务分类拼接业务查询统计SQL列表。
如：sqlId，dataBaseName， sql模板语句， sql条件字段参数，sql返回字段参数。通过具体字段参数拼接成完整的sql语句，去业务数据库查询。
3，提供SDK接口查询并返回业务数据。
设计优点：1，灵活设计sql语句，满足业务的随时变更。
2，可灵活获取多个库的数据，高可扩展性。