作者｜伍振河
本文以博时基金的金融场景为事例，阐述 RocketMQ 在提高客户陪同功率和丰富金融场景化才能等方面的提高效果。
职业背景
基金公司的中心业务主要分为两部分，一部分是投研线业务，即出资办理和职业研讨业务，它体现了基金公司中心竞争力。另一部分是商场线业务，即基金公司使用本身途径和商场才能完结基金出售并做好客户服务。
博时基金管作为中国内地首批建立的五家基金办理公司之一，截至 2021 年 6 月 30 日，博时基金公司共办理 276 只公募基金，办理资产总规模逾 15482 亿元人民币，累计分红逾 1465 亿元人民币。
随着互联网技能发展，基金出售途径愈加多元化，线上成为基金出售重要途径。比较传统基金客户，线上途径具有客户基数大，水平参差不齐的特点。关于那些还不成熟的客户，咱们需求做好陪同，让他们了解风险，了解出资。
RocketMQ 在陪同系统中的使用
1、陪同场景概述
博时基金建立了一套全方位多层次陪同系统，从用户层面、商场层面和产品层面为用户供给投前、投中、投后的有温度的出资陪同体会。
每个陪同场景的达到，需求公司多个部门不同团队协同配合来完结。依靠与投研、合规、运营、大数据等上下游多个系统。但这些系统或许采用不同技能架构，完成方法各异，假如采用同步调用方法来完成协同，耦合度太高，不利于未来扩展。
2、RocketMQ 解耦异构系统
RocketMQ 供给高效牢靠的音讯传递特性和发布订阅机制，非常合适用于这种上下游异构系统间的解耦。咱们把本来基于文件、邮件的协作方法全部线上化、流程化和机制化，大大提高了陪同输出功率。关于这种涉及多方系统的协作，需求对音讯进行合理地归类，以便进行过滤和索引。RocketMQ 供给的 Topic 和 Tags 便是用来做这件事的。
3、Topic 和 Tags 最佳实践
Topic 与 Tag 作为业务上用来归类的标识，分别归于一级分类和二级分类，这种层次化的分类标识与企业安排架构比较类似，能够结合起来完成音讯过滤。举个比如，关于陪同系统的 Topic，运营系统订阅运营类音讯，咱们给这类音讯打上 TagA 的标签，客服系统订阅客服类音讯 TagB，陪同编列系统订阅编列类音讯 TagC，合规系统需求对运营和陪同音讯进行合规审查，因而它需求订阅 TagA 和 TagC，终究是数据中心，一切的音讯都要处理，因而它需求监听一切 Tag。
RocketMQ 业务音讯的金融使用场景
1、金融场景概述
接下来，咱们讲解一下典型的金融场景–优惠购。在博时基金 APP 上申购基金能够享受低至 0 折的费率优惠，详细业务怎么样完成？这儿有有两种方法，第一种先充值博时钱包，底层是替客户购买了一笔货币基金，然后再用博时钱包购买方针基金。这种方法需求用户操作两次，比较繁琐，简略引起客单流失。别的一种方法便是优惠购，把两步购买基金封装成一次业务操作。对出资者来说，敞开优惠购服务后，操作少一步，出资更简略！
2、范畴事情理论模型
范畴事情是指业务流程的一个步骤将导致进一步的业务操作，比方说登录事情，比方说基金购买事情等。在范畴模型里边，范畴事情业务采用的是终究共同性，差异于强共同性，它是弱共同性的一种。在范畴模型映射到微服务系统架构时，微服务之间的数据不用要求强共同，因而范畴事情能够解耦微服务。根据是否跨微服务，能够分为两种场景：
第一种场景：当范畴事情发生在同一个微服务。因为大部分事情发生在同一个进程内，本身能够很好地控制业务。但假如一个事情需求一起更新多个聚合，按照 DDD 中一次业务只更新一个聚合的原则，就需求引入事情总线，便是 eventbus 这种形式。
第二种场景：跨微服务。范畴事情发生在微服务之间的场景比较多，事情处理的机制也愈加复杂。跨微服务的事情能够推动业务流程或者数据在不同的子域或微服务间直接流转，因而需求一个和谐者来推动全局业务。跨微服务的事情机制要总体考虑事情构建、发布和订阅、事情数据持久化、音讯中间件、分布式业务机制等，其间具有业务音讯功能的音讯中间件是这个处理计划的中心组件。
3、布式业务计划比照
在博时基金的业务场景下，需求处理的问题是业务共同性与服务解耦度之间的矛盾，因而咱们的方针是让主从业务解耦，确保中心逻辑稳定，一起不因为解耦而献身终究共同性。因而，其时做出了几种不同的处理计划：
- 第一种计划：最常见一般音讯+异步对账，这个计划的问题是无法确保主业务的履行和入队一起成功，需求时效性低的对账补偿处理，共同性只是较高。
- 第二种计划：本地音讯表，比照上一种做法，它由业务将写入音讯表放到主业务中，把主业务和入队变成一个原子操作，然后业务读取入队记录，自己投递给从业务。它的缺陷是主业务和音讯表在存储上是耦合的，没有解耦度。
- 第三种计划：引入 XA 业务，是个两阶段提交的协议，完成难度较大。并且面对两个问题：一是这是一种同步阻塞协议，有锁占用导致并发不会太高，别的便是 XA 业务过程中，在参与者投赞成票后，假如和谐者发生故障，节点不清楚应该提交还是中止，只能等候和谐者恢复。这时候或许会出现业务中止。
- 第四种计划：TCC，专门处理分布式业务的 TCC，只侧重于共同性，无解耦度，也是不行行。
- 第五种计划：业务音讯，它能一起兼顾解耦度和共同性，是最合适的形式。
终究咱们挑选了 RocketMQ 的业务音讯作为分布式业务的处理计划。
4、RocketMQ 业务音讯中心流程
基于 RocketMQ 的业务音讯建立业务中心，和谐分布式业务的推动和回滚。以优惠购为例，中心流程如下：
- 第一阶段：Prepare 阶段 ，即业务系统将 RocketMQ 的半业务音讯发送到业务中心，业务中心不做发布，等候二次确认。这个阶段 RocketMQ 的半音讯在顾客端是感知不到的。
- 第二阶段：业务系统履行主业务，即购买货币基金。
- 第三阶段：主业务成功后 commit 到业务中心，由业务中心投递音讯到从业务。假如主业务失利，就投递 rollback 给业务中心。这儿需求两阶段提交的原因是：一般的入队操作不管放在主业务之前还是之后都无法确保终究共同。假如先履行主业务，再入队，那么或许在入队前，业务会宕机，就没有机会再入队了。假如先入队再履行主业务，那么或许主业务没有履行成功，但是从业务履行成功了，业务逻辑就会发生紊乱。
因为网络抖动等原因，或许导致业务音讯的二次确认丢掉。此时需求依靠某种机制恢复整个分布式业务的上下文，RocketMQ 供给的反查机制正是为处理分布式业务中的超时问题而设计的。咱们的业务中心的反查机制流程主要是，先查看业务中心的内部状态，再通过反查接口查看本地业务的履行成果，恢复业务上下文后，正常推动后续的流程。
5、RocketMQ 怎么确保业务音讯在消费端正常消费
消费端消费失利后，MQ 服务端需求进行必定次数的重试，咱们需求拟定合理的重试战略。因为有消费重试，这要求消费方接口需求完成幂等性；假如重试多次后仍失利，咱们会把音讯压入死信行列 DLQ，RocketMQ 供给了死信行列的功能，对进入死信行列的音讯进行告警处理。
6、业务音讯的适用场景、
第一类场景：需求同步履行的范畴事情，比如说范畴事情逻辑失利概率大，业务要及时将返回码告知客户端，天然不能放在异步流程中。举个比如，做过付出系统的小伙伴都知道，付出扣款前要查看余额是否足够，假如余额不足，那在异步流程中重试多少次都是失利。
第二类场景：是业务不行重入场景，例如业务系统发送音讯时没有确认一个仅有业务 ID，那后续的业务逻辑就无法确保幂等，假定其间一个业务是创建订单，假如不能确保幂等的话，重试多次就会发生多个订单；所以这儿需求使用到业务音讯，用来清晰一个分布式业务的开始，生成一个仅有业务 ID，让后续的流程能以这个业务 ID 来确保幂等。
未来规划
