阅读 1561

聊聊Push系统

最近一年多工作的主要精力都放在了Push系统的开发上,投入了不少心血在里面,但是这一年多的时间一直在写代码埋头赶路,疏于总结,借此机会回顾总结下系统的相关设计,希望对自己与读者都有所帮助。

概念

Push:有主动推的意思,实际上就是一个服务端主动推送消息到用户App的一个系统。从用户的视角Push

  • App外部:主要展示形式为手机通知(手机系统功能,样式固定)。
  • App内部:展示根据需求可以定制展示样式,各种Pop

从技术的角度来看,主动推送的东西主要是数据,数据可以用作上面的展示,也可以推一些无需展示内部处理的数据到客户端端上,但最终目的都是为了用户的体验。

架构

Push系统初始状态下包含的元素,只有发送者,系统通道,接收者。

image-20210524072122446

发送者:生产推送内容的人,生产内容的方式 系统通道:将生产的内容触达的用户的通道,可以看做Push系统的核心

  • 能对接各大手机厂商,用户设备离线状态下交给厂商发送
  • 自建服务器与用户App的长连接通道,在线状态下直接通过自建通道触达用户

接收者:用户,内容在用户手机上展示

以上肯定比较简化,想要让其真正成为一个系统,还需要更多的事情在其中,比如说单次发送1亿条用户呢? 系统上则需要将人群进行分片,分到不同的机器上处理这件事情,还有最好能灰度发送,如果对系统有一定压力还需要进行限流。当然还有对后续的效果有一定的监控措施,实时的数据表现。

  • 大数据处理:任务分发
  • 并发处理:灰度,限流
  • 数据监控:数据平台

image-20210524073656071

当然还可以在运营侧做一些东西,降低风险,增加一些审批流,所有发送内容数据管控,运营之外还有许多需要用到通道的业务进行支持。

  • 内容系统:所有的用户可接触内容
  • 开放平台:系统功能对外服务,支持横线业务
  • 审批流:保护系统安全,防止一些胡乱操作

image-20210524074728974

如果用户量较大,纯手动方式肯定是无法完成的,需要一些精细化的控制,个性化服务,内容个性化,时间个性化。此时系统的各种入口在抢占通道资源,还需要对通道做一些优先级分配,一些监控报警。

image-20210524080953525

到这里基本上大致的元素都具备了,还能做的是一些细节的打磨,还有组件的职责,做一些决策:

  • 通过系统定义运营的工作流程
  • 整个开放平台,运营平台的易用性
  • 系统的稳定性,扩展性;一些压测链路改造,模型的设计。除了Push,系统还可以是什么?

服务组成

其中一些比较重要的的服务或者依赖的平台:

  • 内容平台
    • 内容安全工具
  • 审批流平台
  • 算法平台
  • 数据平台
  • 长连接平台
  • 配置中心
  • 监控报警中心
  • ...

技术使用

主要用到的技术:

  • 缓存,限流,降级
  • 配置中心,消息队列,调度中心,集群存储,RPC调用,日志管理
  • 实时计算平台,离线计算平台
  • 多线程知识,一些设计模式

想法

技术上不见得多么高深,主要因为用户基数较大,一定程度上增加了系统的复杂性。在技术上,在内部都有对应的平台封装了技术难点,真正技术难点的地方在一些底层或者中间件那边处理。

而业务开发主要做的事情,目前变成了理清楚业务重点,识别技术阻碍,推动项目进行。对分析能力,社交能力的要求高于技术的能力。

当然因为自己是技术,还是不能停下对技术的学习和探索上。

最后

时间有限,能想到的Push中比较有印象的东西应该都有提到,希望能对读者有所帮助。

文章分类
后端
文章标签