背景

随着得物App消息平台的推送越来越多，业务接入也越来越多。针对具体业务的兼容逻辑已经不能满足业务快速开发的需求。研发效率越来越差、稳定性、时效性指标逐步降低等。在推送容量确定的场景下各个业务指标数据相互影响。消息平台需要针对不同的业务不同处理、平台统一能力编排等进行平台化优化&改造。

消息中心演变过程

v 1.0 版本

各个业务直接调用push/notice接口发送消息，消息没有进行管控。调用量多少无法感知，各个业务的业务逻辑处理耦合在一起，消息没有优先级。我们先看看整体流程以及会遇到了哪些问题。

1.0版本的架构流程

推送流程如下

在使用1.0版本的推送过程中，我们看到各个业务的推送都耦合在一起。一旦某个业务的推送出现问题，由于耦合严重无法针对某个具体的业务进行拦截，只能全部拦截这样就对我们推送的稳定性、触达率很大挑战，同时因为各个业务的消息通道都是1个，当发送订单消息、营销消息时属于先到先发，通常我们都知道营销消息发送量较多，这样在营销消息发送阶段，其他业务的消息都必须等待营销消息发送结束，才能进行发送,时效性上大大降低.同时在使用过程中发现其他很多问题，我们总结下述的痛点：

• 各个业务在既要发送push消息又要发送通知消息时，需要调用多次接口，对业务调用发送多类型消息时rt增加。
• 业务的一些基础能力需求（防疲劳、版本控制发送）等实现开发难度大，每个消息推送都需要实现一份，开发量重复。
• 业务调用接口不能统一，出现异常无法快速拦截，需要多个推送类型拦截。

v 2.0 版本

我们在v1.0版本的推送，已经越来越无法满足我们的业务迭代需求了。在针对第一个版本的痛点，我们构建的消息平台2.0的版本。在分析过程中，我们采用下面几个思路：

• 针对消息平台对外接口进行统一接口收口,增加业务身份识别。通过泛化的方式对业务可以快速添加推送内容，无需调用多次。
• 增加消息平台基础通用能力(包含防疲劳、优先级、免打扰、多版本发送)等相关基础能力，减少业务方信息的判断。
• 切换之前的es存储改用其他可以支持高写少读的数据库。
• 需要在消息推送的各个阶段进行数据监控，异常快速告警。

v2.0 整体架构

推送流程进行如下的改进

v2.0虽然解决了 v1.0版本中各个问题。但是随着业务快速发展，基础服务混淆比较多，临时兼容性代码越来越多,造成平台系统的代码冗余增多，在开发过程中不能快速定义属于业务扩展或者基础服务，从而导致研发效率降低。针对业务的特殊需求扩展和修改困难，牵一发动全身，每次新增特殊需求都需要在之前的代码上进行改造。对系统的稳定性造成一定影响。

v3.0 版本

在v2.0版本过程中，我们在特殊业务场景下的兼容太多。于是我们想需要重新定义什么是消息平台的基础能力?什么是业务定制的拓展能力?同时增强统一的流程校验能力。

什么是消息平台的基础能力?

• 基础能力有如下的准则

• 相互独立、无循环依赖

• 能力点都是无状态

• 各个业务都迫切需要的能力

• 按照上述的准则，我们也定义了消息平台所需要的能力点

• 限量/流、用户防疲劳、消息防疲劳、消息优先级、消息聚合、屏蔽发送、定时/延时能力、消息版本发送、消息风控审核拦截能力等。

那什么又是业务定制的拓展能力呢？

• 那业务拓展能力的准则又是什么呢？

• 需要依赖具体业务的参数数据

• 业务定制化需求，包含兼容业务具体字段数据等

• 其他业务不必的场景，包括透传相关的数据

在定义完概念之后，我们就可以采用相关的概念进行技术方面的改造。本次还引入业务编排引擎，通过业务身份维度按照策略的方式构建动态化扩展能力，达到业务&业务之间互不影响。同时建立统一标准SLA关于时效性、稳定性的监控，包括不限于（接口异常告警 、实时推送变化告警、延时推送告警 ）。通过上面的思路我们设计下面的架构。

v3.0 整体架构设计

改进之后流程

改进之后梳理完整链路，对于基础能力只要新增拓展即可，业务的定制需求采用策略的方式修改即可，无需对其他业务逻辑进行改造。

未来规划

虽然现阶段的优化已经解决相关痛点问题，但是在流程编排、业务动态拓展、稳定性保证、监控体系完善上仍然有优化的空间，这个也是我们后续优化的方向。

总结

本文介绍了消息平台从1.0版本到3.0版本（还在进行中，逐步完善）的平台化建设演化过程。主要包含v1.0的原始时代基础消息推送能力。v2.0主要包括统一接口，构建以业务身份为主的基础能力支持。以及目前正在进行的增强业务扩展+监控+编排一体的架构。虽然这个期间我们对后台改造相对较多，也遇到不少兼容问题。但我们做到了在业务在接入之后的平滑过渡，为后期消息平台的优化提供了不错的基础。