前言
智能茶饮机(TeaPod)是一款能够制作咖啡、茶等饮料的设备，搭载安卓系统，可以进行智能操控，支持线下直接点单和手机APP线上点单。浓度、杯量等随意调节，充分满足个性需要，轻松享受DIY的乐趣。
本文写在极光推送已经在公司稳定使用四年多之际，这四年多完美支撑了公司的线上推送服务。四年时间，经历了互联网泡沫到寒冬，还好，极光还在，我们也在。本文不描述接入基础，这些都可以在极光推送文档中找到。只是把业务实践写出来，给有相似业务场景的公司一种参考。
极光SDK下载
Android SDK接入
IOS SDK接入
服务端 SDK接入
正文
线上APP点单，需要实时地把订单消息推送到机器上。具体流程就是线上点单支付之后，需要实时推送订单消息到机器，机器根据订单制作饮品。当时考虑了3种方案：
方案一，基于openfire进行实时消息推送。openfire是免费的、开源的、基于可拓展通讯和表示协议(XMPP)、采用Java编程语言开发的实时协作服务器。 Openfire安装和使用都非常简单，并利用Web进行管理。单台服务器可支持上万并发用户。
这种做法缺点是需要自己部署和运维openfire服务器，维护android和ios推送相关的客户端接口，扩展部分XMPP协议，而且在使用过程中，肯定要踩不少坑，不确定性比较大，运维成本也高。
优点是可以自己灵活定制，加上自己的业务逻辑，保证消息的实时性和可达性等。
方案二，基于Netty框架用Socket开发推送。Netty是由JBOSS提供的一个java开源框架。Netty提供异步的、事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序。
这种做法的有点是可以“快速”和“简单”实现推送。
缺点是需要从头开始写，需要自己进行心跳保持等，没有较为成熟的方案进行参考，相当于从头开始造轮子。
方案三，基于极光推送(JPush)实现消息推送。JPush 是经过考验的大规模 App 推送平台，每天推送消息数超过 5 亿条。 开发者集成 SDK 后，可以通过调用 API 推送消息。同时，JPush 提供可视化的 web 端控制台发送通知，统计分析推送效果。 JPush 全面支持 Android, iOS, Winphone 三大手机平台。
这种做法的优点很明显。使用者众多，支持平台丰富，有专门的维护团队，关键是免费、免费、免费。
这种做法主要是对消息可达性的担忧，因为订单消息如果不可达，就会导致一系列的问题，这个下面会说。
通过几个方案的对比，最后选择了方案三，拿来就能用。现在已经稳定使用4年多了，多谢极光的服务。
其他
接下来就使用过程中几个问题做一下总结：
1、极光推送主流的应用场景是资讯、通知消息的推送，对实时性和可达性不是特别敏感，用在订单消息这种要求实时、可达性的消息上，可行吗？
这个问题，也是我们接入之初一直困扰和担忧的问题，但是4年实践下来，我们的结论是可行的。极光消息的实时性和可达性非常高。过程中只有1-2次，由于极光服务，导致某个时间段内消息延时，大部分时间都是稳定运行的。这里面我觉得还有一个问题，就是大部分面向客户的推送都是一对多的类型，比如某条消息需要推送给很多人，这时候可能会采用分时、分段推送，不保证同时受到消息。我们的使用场景是一对一的，所以实时性和可达性都非常好。
2、登录成功，收不到Action - cn.jpush.android.intent.REGISTRATION的推送消息，曾经收到过。
这个问题困扰很久，其实极光在文档里面小字部分提到过一次。我司的机器在启动之后，会监听cn.jpush.android.intent.REGISTRATION的通知，获取注册成功的registerId在服务器端进行绑定，但是连续多次重启，发现一直收不到cn.jpush.android.intent.REGISTRATION的通知。最后极光社区Lris给我的回复如下:
这个消息cn.jpush.android.intent.REGISTRATION，是只有在初次注册的时候才会有，并是不会每次启动APP都会收到这个通知。在极光文档中也有说明：
极光的社区回复比较迅速，这个非常赞。很多互联网公司，在使用其产品过程中，出现问题，找不到解决办法，也无法联系到。
3、对调用JPush API提示消息推送成功，但是实际并没有送达的处理。
极光推送应该是分为多步的，第一步把消息发送到推送服务器，第二步通过推送引擎开始推送。有的时候消息发送没有问题，但是推送过程中某些原因导致消息没有实际推送，比如终端设备不在线等。我的建议是极光能给出一个类似webhook的回调通知，提示某些消息没有实际送达，需要重发或者按照异常处理。针对这个问题，极光的回复如下：
这里给出的做法是一定时间之后调用JPush Report API去获取消息的送达统计，这里的统计是实时的。我们最后的做法是，对于需要确保送达的消息，终端在收到消息之后，给一个ack，如果一定时间之后没有收到ack，就认为消息没有送达，立即重新发送或者按照异常处理，并不是调用推送没有问题之后，就认为消息已经送达，同时终端支持相同消息的过滤，不会对重复推送的消息重复处理。
本文为极光征文参赛文章。