通知网关架构设计

问题背景

一般公司的APP后台、监控系统都有发短信、邮件的通用需求，比如：APP后台在用户注册时需要向用户发送验证码短信；监控系统遇到异常状态时，需要向管理员发送告警邮件。最简单的做法是在业务代码中嵌入发送短信/邮件的代码，这样的设计会有以下劣势：

1、代码重复，在需要发送短信/邮件的地方就需要引入重复代码

2、不适合SOA化环境，由于后台系统不同模块可能采用不同语言编写，所以需要将发送短信/邮件的逻辑用不同的语言重新实现一遍，加大了编码和维护的工作量

因此，将发送短信、邮件等通知类需求提取出来，成为一个独立部署的通知网关（Notify-Gateway），对外提供发送通知（短信、邮件等）的服务。

需求细化

• 功能性需求

  1. 支持短信

  2. 支持邮件

  3. 支持插件化集成第三方消息方式，比如bearychat等

     ​

• 非功能性需求

  1. 采用Web API方式，便于业务模块快速集成

  2. 通知渠道插件化：比如发送短信是一个插件、发送邮件是一个插件

  3. 多通道重试：比如发送短信时，由于某个短信通道暂时不可用，所以需要向其他的短信通道重试

  4. 过载保护

     对内部系统而言，需要限制消息堆积数，避免系统过载导致不稳定

     对外部系统，需要限制发起的并发请求数，不能将第三方渠道打垮

系统架构

设计思路

• Web API接收到通知消息，根据通知类型（短信、邮件）将消息放入不同的队列中，返回200 OK
• 每种通知类型都有一系列的消费者，从队列中取出消息，进行处理

设计要点

• 队列使用Redis List结构，入队用LPUSH，出队用RPOP
• 出队时需要批量出队，比如一次性出队10个消息然后依次处理，从而避免大量的I/O
• 每种通知类型的消费者线程个数需要限制，避免当通知消息太多时启动大量线程，一是对系统性能产生影响，二是避免同时发送大量的请求给第三方通道
• 不同的通知类型使用不同的插件，便于后续扩展
• 对每种消息类型的队列长度进行限制，防止消息大量堆积
• 支持冗余通道，当向主通道请求失败时，在冗余通道进行重试
• 每条消息都有一个创建时间戳，发送消息时需要判断消息是否过期（不同消息类型可设置不同的过期时间），若过期就放弃发送

高性能、高可靠、高可用性保障

• 可用性

  对于高可用场景，可利用HAProxy + KeepAlived搭建高可用集群

• 可靠性

  • 消息持久化：

  使用Redis自身的持久化功能，开启AOF归档，设定1s fsync一次，因此有一个很小的时间窗后会丢失数据，不过由于队列中的消息并不是交易类非常重要的数据，所以容忍这样的失败

  • 冗余通道

  由于第三方系统宕机等原因可能导致请求失败，所以增加冗余通道机制，在主通道失败后会在冗余通道进行重试，防止某个第三方通道成为SPoF

  ​

• 高性能

  • 每个客户端的连接由独立的goroutine处理，由于goroutine非常轻量，因此可以同时创建成千上万的goroutine处理大量并发

  • 通知网关本身是无状态的，所以可以通过Nginx、HAProxy、LVS等软件进行负载均衡，从而实现水平扩展

  ​

API接口文档

• 发送邮件

  URL: http://127.0.0.1:1988/email

  Method：POST x-www-form-urlencoded

- 发送Bearychat消息

URL: http://127.0.0.1:1988/bearychat?msg=%e6%b6%88%e6%81%af

Method：POST Query String

- 发送SMS

URL: [http://127.0.0.1:1988/sms

Method：POST x-www-form-urlencoded