随着得物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主要包括统一接口，构建以业务身份为主的基础能力支持。以及目前正在进行的增强业务扩展+监控+编排一体的架构。虽然这个期间我们对后台改造相对较多，也遇到不少兼容问题。但我们做到了在业务在接入之后的平滑过渡，为后期消息平台的优化提供了不错的基础。
*文/逸飞