作者：InfoQ
mp.weixin.qq.com/s/EAyXDbPuY…
推送通知是让用户立即接收到事件的一个非常有效的工具。在 Gojek，我们每天需要处理 300 多万个订单，跨 20 多款产品。
可以想象的是，我们每天推送的通知数量有多大——大概每小时 1 百万个。这篇文章将介绍我们在处理如此体量的推送通知时所面临的挑战，以及我们的解决方案。
体量大还只是其中的一个方面，在 Gojek，我们还需要面对一些独有的问题。
多个应用程序
Gojek 不只有一个 App，除了用户 App，我们还有 GoLife、司机 App、商家 App，还有服务商 App。
当我们的系统要推送通知，要么是推给某个用户的 App（例如，推给 GoLife 的通知不会被推到 Gojek 上），要么是推给所有的 App（例如促销通知）。
我们的系统需要足够灵活，能够在广播和单独推送之间自由地选择。
多个通知服务提供商
因为我们的用户 App 需要支持 iOS 和 Android 两个平台，所以也需要支持多个通知系统。
Android 平台我们使用了 FCM（Firebase Cloud Messaging）和 GCM（Google Cloud Messaging），iOS 平台我们使用了 APNS（Apple Push Notification Service）。
每一个通知服务提供商都为不同的 App 提供了不同的 API 秘钥和令牌。例如，GoLife 和 Gojek 使用的 FCM API 秘钥就不一样。
一个用户多个设备
我们允许一个用户同时登录多个设备，所以通知需要被推送给用户已登录的所有设备上，这就存在之前的两个问题：
- 用户可以在单个设备上登录多个 App（Gojek 和 GoLife）；
- 用户可能会登录多个设备，每个设备需要使用不同的通知服务提供商。例如，用户可以在 Android 设备和 iOS 设备上登录 Gojek。
多个需要推送通知的服务
Gojek 采用了微服务架构，我们想要让每个服务都能推送通知，不需要操心多设备和多服务提供商问题。
为了解决上述问题，并尽可能保持 API 简单，我们的通知系统被分为三个组件：
- 通知服务器——提供通知推送 API，并将通知推送到作业队列中；
- 令牌存储——保存已登录用户的设备和设备令牌数据；
- 通知处理器——处理作业队列中的消息，并将消息发送给通知服务提供商。
每个组件都解决了上述的一部分问题，接下来，我们来深入介绍这些组件。
令牌存储
用户在登录 App 后，App 会使用设备令牌和 App ID 调用令牌存储 API。
在用户退出时，这些记录会被删除。
令牌存储用于决定向用户的哪些设备推送通知。
通知服务器
这是 HTTP 服务器，提供用于推送通知的 API。
为了简单起见，API 要求把用户 ID 和 App ID 放在 HTTP 头部，把通知信息放在请求体里：
POST http://<base_url>/notification
user_id: <user_id>
application_id: <application_id>
{
"payload": {},
"title": "You driver is here",
"message": "Please meet your driver at the pickup point"
}
服务器从令牌存储获取所有的用户设备信息，然后为每个用户设备安排一个调度作业。
通知服务器为系统提供了外部接口，需要推送通知的服务只要通过用户 ID 来调用它的 API，剩下的事情由通知服务负责处理。
作业队列
我们使用 RabbitMQ 作为作业队列，并为每一种 App ID 和通知类型创建了单独的队列。
分配单独的队列是很重要的，因为我们要为每一种 App 和通知类型做好故障隔离。例如，如果 com.gojek.app 的 FCM 令牌过期，就不会影响到 com.gojek.life 或者 com.gojek.driver.bike 的作业。
通知处理器
处理器进程从作业队列里拉取消息，把它们发送给对应的通知服务提供商。
为了保持代码简单，并能够支持不同的服务提供商，我们定义了统一接口：
type PushService interface {
Push(ctx context.Context, m PushRequest) (PushResponse, error)
}
Push 方法接收一个请求对象，并返回一个响应对象。
请求对象包含了与接收方和通知（比如过期时间、标题和文本）有关的信息。
type PushRequest struct {
DeviceID string
Title string
Message string
Payload map[string]interface{}
// 其他参数
}
响应消息里包含了通知是否发送成功的信息：
type PushResponse struct {
Success bool
ErrorMsg string
}
然后为不同的服务提供商实现接口。例如，FCM 和 APNS 对应的实现看起来像下面这样：
type FCMProvider struct {
// 配置信息，比如 API 令牌和 URL 端点
}
func (p *FCMProvider) Push(ctx context.Context, m queue.Message) (notification.PushResponse, error) {
// 发送通知给 FCM 服务器
}
type APNSProvider struct {
// 配置信息，比如 API 令牌和 URL 端点
}
func (p *APNSProvider) Push(ctx context.Context, m queue.Message) (notification.PushResponse, error) {
// 发送通知给 APNS 服务器
}
通知处理器负责选择对应的通知服务提供商，并将消息发送给它们。
结论
在面对这些挑战时，我们找出其中的一些常用模式，把它们抽离成不同的服务，将一个相对复杂的问题变成了一系列简单且易于管理的服务。
每当一个核心逻辑需要不同的实现时，我们就把它抽离成单独的服务：
- 多个设备问题通过令牌服务来解决；
- 多个 App 问题通过统一的通知服务器接口来解决；
- 多个通知服务提供商通过单独的作业队列和通知处理器来解决。
最终，我们构建了一个每小时能够处理 1 百多万个推送通知的系统。
公众号《架构文摘》每天一篇架构领域重磅好文，涉及一线互联网公司应用架构（高可用、高性能、高稳定）、大数据、机器学习、Java架构等各个热门领域。
