我最近被分配了一个开发通知引擎的任务。对于通知,我们将使用推送通知。我正在寻找引擎的最佳解决方案,因为在未来我们必须将应用程序扩展到其他设备也。以下是项目的一些细节
后端:应用程序的后端是用Ruby on Rails作为webservices开发的
将具有推送通知的设备iPhone、Android、Pebble(智能手表)、Web应用
当前解决方案:目前,我们正在考虑为通知创建一个后端数据库表。Rails中的工作类将在1分钟后运行,它将把所有通知推送到存储在数据库中的设备。从webservice方法中,我们将在通知表中插入数据。
对于推送通知,我们不希望使用UrbanShip这样的服务。我们将只使用Ruby Gems来实现它们。目前,我们基于GCM gem为android推送通知做了一个小的演示。问题:我的解决方法是正确的吗?或者对于这种问题有没有更好的解决办法。
编辑:我认为我之前对这个问题的描述有点令人困惑。
最终我们将在Ruby中使用GEMS来发送推送通知。例如,我们将在iOS上使用Houston或Grocer gem,而在Android上使用GCM。
问题:我们需要一些数据库表来存储通知,以便GEMS(上面提到的)可以使用它们向用户发送通知。现在,为了填充数据库表,我们需要在某个地方编写逻辑,以便在表中插入通知。
例如,假设当用户第一次在应用程序中注册时,我们向他发送通知。现在,要做到这一点,我们需要编写在Register函数中添加通知的代码。
public void Register()
{
//Registration logic
//Add a notification in the notification table
}
现在,这是一个问题,因为我们需要在所有需要发送通知的函数中添加通知逻辑。在ROR或一般情况下,有没有其他好的解决方案?
我花了相当多的时间研究基于Ruby的推送通知解决方案。最好的是RPush https://github.com/rpush/rpush。目前,RPush已经经过了很好的测试(我们使用它来发送数百万条通知),并且很好地处理了许多困难的边缘情况。我不建议你自己从头开始构建,因为有太多潜在的陷阱和边缘情况。RPush不支持Pebble或Web应用程序通知,但可以扩展到这一点。
如果您决定探索其他替代方案,请确保它们:
-
为APNS优雅地处理已关闭的连接-在许多情况下,Apple可能会关闭与其服务器的连接,您的推送通知库必须正确处理此问题,否则数千个后续通知将无法传递
-
与Apple的反馈服务沟通- Apple要求您轮询其中一个端点,以获得停止向其发送通知的设备列表。如果你不这样做,你可以得到速率限制。
-
可以以足够快的速度发送通知。
在Ruby之外,最好的推送通知库似乎是PushSharp (c#)和Node-Apn (NodeJS,仅限iOS)
最后,听起来你有特殊的需求,需要你自己做这件事。但对于其他人,我强烈建议您使用第三方服务。可靠地发送大量推送通知是很困难的,有许多第三方服务可以以低成本为你做这件事。例如,UrbanAirship、Parse和onessignal(我的服务)都是很好的第三方解决方案。
更新以解决修订后的问题:
最好的设计模式是使用第二个守护进程或Cron Job来处理消息传递。在Ruby on Rails应用程序中尝试这样做是不实际的。
RoR应用程序可以像您所描述的那样将行作为队列插入通知表。然后守护进程或cron作业可以从队列中获取通知并发送它们。
如果你使用RPush,这是它遵循的模式。它附带了一个Gem,可以加载到Rails应用程序中,将通知插入到数据库队列中,还附带了一个守护进程,可以在服务器上运行,定期检查要发送的新通知,并交付已排队的通知。
我想知道这个问题是否仍然开放或您已经有一个解决方案,但我想提出这个宝石我最近发布:https://github.com/calonso/ruby-push-notifications
它真的很容易使用,足够灵活,以适应您的架构和工作!
目前只是宝石本身,但我正在围绕它构建一个完整的Rails插件,与所有的表结构和东西。您可以在这里看到一些正在进行的工作:https://github.com/calonso/rails-push-notifications
本文描述了一种非常简单但相当全面的方法来处理Rails后端上的推送通知。
简而言之:
- 实现一个
Device
模型和一些控制器动作一起记录用户的设备令牌在你的数据库。 - 创建一个
Notification
模型,在文章中是一个Redis列表,但如果你真的不想使用Redis,你也可以使用ActiveRecord。 - 创建一个后台工作器,它积极地运行传入的通知,并将它们作为推送通知发送。文章提到grocer和GCM分别将它们发送到iOS和Android,但你也可以使用其他有用的宝石,如rpush, houston等。
有一个单独的工人处理通知是一个好主意,因为你不想不断地打开和关闭连接到苹果和谷歌的服务器被锁定的风险,因为它可能看起来像拒绝服务攻击(取决于你的通知频率)。