一、前言
之前说完了玩法之间的解耦、玩法之间的串联，已经基本解决了功能上50%的问题，基本可以完备地搭建一个活动出来，但是离一个好的活动还是有差距的，主要是对于用户体验上和活动效果方面上，本篇要讲的就是如何从后端角度处理用户参与活动过程中的交互问题。
系统架构设计或功能抽象时，为了扩展性等原因把系统能力进行了割裂，每个玩法都能独立存在，可以动态关联，系统架构设计层面是优秀的，但这样搭建出来的活动，没整体处理交互反馈的话是有伤用户体验的，一定程度上来说用户感受到的还是一个拼图式的活动，每个玩法处理各自的交互，联动性对用户感知不强烈、玩法和玩法之间的交互可能存在冲突等，整体性不够强。
我们整个系统产出的活动应该是完整的而非割裂的，每次定制处理成本又太高，放弃玩法编排就又退回到了原地，所以为了更好的用户交互体验、活动交互逻辑开发成本的缩减，我们需要一个集中的“总线”来负责用户的整体交互。
二、解决方案
1. 问题分析
交互总线的职责是：“集中处理用户交互过程中的事件反馈，负责交互的整体感”。对于事件进行分类，按照来源主要分为：
既定的活动交互规则（玩法自身、玩法间）、运营操作触达的两大类。
- 按照表现形式可以分为：toast、弹窗、活动内通知、私信、push等等；
- 按照时机分又基本可以分为实时触达（被动接受）、交互时触发（主动触发）。
本质上这些动作都属于活动同用户间的“互动中的反馈”，我们只需要抓清楚触动的本质就可以啦，然后对于“反馈”出现的场景、形式、时机进行分析，然后归纳抽象就可以了。
2.定位确定
交互总线集中负责了一个活动对于用户交互过程中的反馈，那它必然是一个“切面”般的存在，所有交互的反馈都由这里发生，也就是说玩法和业务事件总线提供了集成好的功能呈现、交互总线提供了统一的用户交互反馈，这两块围绕用户参与的上下文对用户提供好的用户体验。
3. 抽象一下
先确定上下文：我们是在活动领域处理用户参与时的交互反馈问题，核心的处理的对象是反馈，要解决的问题主要是交互过程中反馈不统一、过多or过少、无法集中管理、维护成本相对较高的问题。
对于运营者来说，反馈是一种活动交互规则，需要被配置管理、触发；对于用户，可以被主动推送，也可以在进入活动的时候主动拉取，然后这些反馈有自己具体的内容、具有不同的表现形式、接受用户，反馈之间存在优先级或者互斥逻辑等等，总体来看反馈可以大致抽象为如下情况：
所以只需要落地一个能够生成&维护反馈、统一处理反馈之间关系的服务即可。
4. 运行视图
先大体看一下整体的运行时视图，后面详细说一下如何完成交互反馈之间的统一处理。
首先交互总线的事件来源可以是某个异步事件，比如说任务完成、助力成功等，还可以是用户的一次点击或者界面打开，再或者运营集中发的触达召回等。在接收到事件后我们需要创建事件本身交互反馈及事件相关连的交互反馈，比如说任务完成会有toast提示，任务完成后加抽奖机会会有一个刷新动作或者特效。
取到对应的反馈之后，灌到现有buffer中，或者直接走后续的流程，然后对事件按照规则进行标准化处理，如果存在buffer同当前的其他事件进行合并或者舍弃处理，并同当前的前端交互序列作融合，确定当前buffer的最终序列等待被消费。
最终可被消费的序列可以通过server长链接主动push给用户，或者在用户发生交互时带给用户。
5. 消费规则
整个总线的消费规则的维护是整个实现中最复杂的部分，通常消费队列的消费方式可以分为拉取和推送两种，拉取通常的逻辑是取用户在上次交互和本次交互之间产生的交互的反馈行为，而推送通常为定时&定量的消耗逻辑，并且反馈的消费要支持多维度处理，比如说只消费某个玩法相关的，只消费本次互动相关的。
所以反馈有一个很重的业务处理特征，这块实现起来可以非常复杂也可以非常简单，主要看面临的业务场景，通常来说活动维度稍微包装一下规则就可以了，并不会膨胀到非常复杂。
举个相对常规的例子大家可以简单地感受一下：
- 消费方式<拉取、推送<定时、定量>、拉取&推送<定时、定量>；
- 特征集合<合并特征、优先级、舍弃标示、反馈标签>。
很多简单的活动是没有很强烈的反馈诉求的，这时候我们只需要一套简单的默认时序规则或者无特殊规则就可以啦。
这部分的规则设计实践和业务场景强相关，我们只要能保证规则能灵活插拔就足够了，有想交流的可以单独细聊。
三、写在最后
本篇就先暂时写到这里，中间涉及的很多技术细节没有仔细说，比如DSL的定义、文本的生成方式、存储到底是redis还是mysql，再或者是SDK提供服务，还是个rpc对外，又或者是buffer的计数机制、推送机制、性能和数据一致性保证等等，可以根据公司的技术选型和业务场景具体来定，有相关疑惑的可以单聊。本篇描述的思路其实不仅仅是活动场景可以使用，一些通知系统或者触达系统等都是这种思路来处理问题。