我们是怎么做到每小时推送百万级通知的

推送通知是让用户立即接收到事件的一个非常有效的工具。在 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 秘钥就不一样。

一个用户多个设备

我们允许一个用户同时登录多个设备，所以通知需要被推送给用户已登录的所有设备上，这就存在之前的两个问题：

1. 用户可以在单个设备上登录多个 App（Gojek 和 GoLife）；

2. 用户可能会登录多个设备，每个设备需要使用不同的通知服务提供商。例如，用户可以在 Android 设备和 iOS 设备上登录 Gojek。

多个需要推送通知的服务

Gojek 采用了微服务架构，我们想要让每个服务都能推送通知，不需要操心多设备和多服务提供商问题。

为了解决上述问题，并尽可能保持 API 简单，我们的通知系统被分为三个组件：

1. 通知服务器——提供通知推送 API，并将通知推送到作业队列中；

2. 令牌存储——保存已登录用户的设备和设备令牌数据；

3. 通知处理器——处理作业队列中的消息，并将消息发送给通知服务提供商。

每个组件都解决了上述的一部分问题，接下来，我们来深入介绍这些组件。

令牌存储

用户在登录 App 后，App 会使用设备令牌和 App ID 调用令牌存储 API。

在用户退出时，这些记录会被删除。

令牌存储用于决定向用户的哪些设备推送通知。

通知服务器

这是 HTTP 服务器，提供用于推送通知的 API。

为了简单起见，API 要求把用户 ID 和 App ID 放在 HTTP 头部，把通知信息放在请求体里：

POST http://<base_url>/notificationuser_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 百多万个推送通知的系统。

原文链接

How We Manage a Million Push Notifications an Hour