微学堂第31期：百度外卖商户新单提醒优化之路

大家晚上好，感谢大家能够参加本次的关于商户新单提醒优化的分享，首先自我介绍一下，我是13年加入校招加入百度，15年来到百度外卖，主要负责百度外卖商户端的业务、架构等相关工作，商户新单提醒在很多O2O领域的一些场景上是一种非常普遍适用的一项技术，本次分享最主要是餐饮外卖的新单提醒，分享主要分为四个部分，第一，阐述商户新单提醒的背景，第二，阐述商户新单具体是怎么实现的，包括在安卓、IOS、电脑客户端，以及我们自己的硬件上，第三，阐述遇到的问题和挑战，以及进行的技术优化，第四，环节提问环节。

新单提醒商务最基础核心功能之一，简单的说需要从三个层面上保证整个流程的正常运行。用户层面，保证用户下单能够得到商户的及时反馈，这是最基本的要求；商户层面，保证用户新单能够得到及时的提醒、触达，商户及时进行处理；平台层面，保证用户下单、商户接单流程的良好体验和服务。餐饮外卖新单提醒，相对于其他业务场景，对于实效性要求很高，比如：用户在百度外卖下一个新单，正常流程是用户下单后在预期时间内得到商户的反馈，如果用户长期得不到商户反馈，用户有可能是离开当前商户进入另外一个商户下单，会造成我们商户或者是平台的顾客流失，对平台造成伤害。

鉴于以上业务背景，当前业界主要有两种主流方案。第一种是轮询，最基本有效的方式，简单的说是客户端以一定的时间间隔向服务端发请求，通过频繁的请求保证数据的同步，它的优点非常明显，可以保证整个订单的及时有效，缺点也是非常明显，需要频繁的请求服务端，造成无所谓的资源消耗，同时客户端上的流量和电量消耗也是我们需要考虑的问题。第二个是推送，简单的说就是客户端和服务端保持长链接的，当服务端上游信息数据发生变化，主动推送变更消息到客户端，它可以降低网络的传输，减少客户端和服务端的交互，只关注发生变化的数据，但是推送对于网络环境、商户设备等，会比较依赖，综合各种因素，对于推送到达率会有一定影响，鉴于餐饮订单对于触达率、实时性的要求，我们需要综合以上两个方案，保证高触达、及时性要求。

最终，我们采用是以轮寻为主、推送配合使用，但是在iOS和安卓它们内部的实现会有所区别，iOS比较依赖于轮寻，安卓强依赖于推送，所以这时候我们针对iOS和安卓进行不同的处理方案。注意：轮询对于时间间隔的选取是比较关键，刚开始间隔的选取是偏依赖于产品拍脑袋决定，但是轮询对于服务端的并发压力大，特别在线商户数超过一定的量级=，会呈现井喷式的服务端压力，所以我们综合用户对于接单的容忍率以及服务端容纳的压力，我们取了一个折衷值，轮询时间隔在30s。

接下来简单介绍下商户新单提醒的基本流程：首先，用户在百度外卖用下单，订单通过我们的NMQ消息中间件推送给商户端（注：NMQ是百度内部公司开发消息中间件，采用消息中间件方便Server处理自己感兴趣的消息，把业务从之前逻辑解偶，方便业务扩展，另外，推送服务也是由百度外卖搭建的），调用推送服务，往相关的设备上发PUSH消息推送，端上收到消息推送并进行相关的声音提醒，同时端上通过轮询，定期从Server服务拉取数据，发现有新单，此时通过另外一个接口拉新单列表，在端上声音提醒和展示。

前面说的是新单提醒的一个基本流程，接下来会按照PC、安卓，IOS分别进行介绍，介绍他们在三个端上的处理方案。

首先，说下PC端，PC是一个壳，有前端相关能力，简单的说后端提供壳，前端提供相关的前端能力，跟现在浏览器有点类似。它会定期的轮询新单服务以及我们的推送，PC不过分依赖推送，优先以轮询接口为主。当推送和轮询同时到达的时候，以轮询的为主。PC方案可能存在的问题：商户网络环境、商户自己对电脑的设置，我们经常从商户收集到的case，发现商户来单不响或者是新单没有提醒有很大一部分原因就是上面所的商户原因。

现在介绍下安卓，安卓是这四种案例里面最复杂的一种，在国内手机生产商众多，安卓又是开源系统，各个厂商对于系统进行系统开发和升级，导致市面上存在系统差异比较大，兼容难度比较大，所以新单不提醒在安卓上的体现会比较严重，总体上来说安卓的新单提醒主要是通过下面几个流程走下来的，

首先，必须保证整个APP是活的，因为现有各种安全软件、手机应用，有可能对常驻后台APP进行清除或者被恶意杀死，我们需要保证APP存活的情况下发送网络请求，请求服务端新单接口，调用系统内部的媒体或者相关声音进行播放，上面就是安卓最基本的流程。由于推送在安卓的达到率相对比较低，所以推送在安卓只起辅助作用，优先以轮寻为主。

从上面讲到的安卓基本流程中，我们可以得出，第一是无法保证APP是活的，这个是非常关键的问题，第二个是无法保证三十秒内定时任务的正常执行，一些系统可能是会限制系统内部的进行执行，第三个是网络方面的，就是在所屏的状态下线索会访问他的网络请求是空的，第四个是无法保证在网络请求的正常情况下能够保证是一个正常播放，如果开启的一些免打扰模式等等系统都会可能先停止播放，由于安卓系统环境复杂性，上面的几个问题一直是困扰在安卓上新单提醒主要难题，后面会有提到安卓在这四个方面如何做，如何尽量解决，但是没有办法做到完全根治，只能是尽量避免问题，或者协助商户尽快发现问题，让商户进行处理。

最后简单说下iOS，因为系统比较稳定，相对安卓复杂的环境来说，相对比较容易实现，主要以推送为主加以轮询辅助。这里简单介绍下百度外卖的推送服务，上面的流程图能反映出整个推送在iOS的运行的流程，首先你的APP在iOS里面注册相关的推送服务。

绑定成功以后你的APP和苹果就建立了服务，业务方，推送消息到百度外卖的推送服务商，然后外卖推送到苹果服务器，苹果服务器将消息推送到APP上，上面就是iOS系统下的基本流程，由于iOS系统的封闭性与其他iOS本身的稳定性，所以推送达到率在iOS市场是非常高的，所以我们在iOS系统里面以推送为主，但是在iOS系统上我们又分为后台和前台逻辑，区别于安卓系统，前台和后台逻辑会有所不一样，后台当一个APP在IOS系统里面处在后台的时候，是不能用定时轮询请求相关的。所以当商户在不知情的情况下 ，收到一个新单推送时，在APP上的反映是只是响铃一声，如果商户此时正在忙碌状态而没有关注，就会导致商户漏单，这个是潜在的风险，当APP在前台情况下一方面接收服务推送的订单提醒，另外一方面也会通过轮询从服务器拉取新单，通过这两种方式来保证整个新单在iOS上的流程。

但是，在iOS上存在几个案例，第一个前面提到的，当APP在iOS后台运行的时候，有新单推送的时候，容易被商户遗漏，我们经常收到商户反馈来单没有提醒，其实订单已经提醒，只不过商户自己没有关注到，这个是一种案例，第二种案例是推送服务本身的延迟，一方面是我们本身的推送服务，另外一方面是苹果的推送服务，我们本身的推送服务可以保证，但是苹果的业务推荐机制，我们干预不到，第三种案例帐户登陆过期，导致商户自动退出登陆。

前面我们重点介绍了PC、安卓（硬件）、iOS三种设备的端上处理策略，现在我们来介绍一下服务端。顾名思义，服务端主要保证两个技术服务，一个是轮询服务，一个是推送服务。轮询对服务端最大的挑战是高并发下的高可用，现在轮询是百度外卖的第一访问量接口，它承载商户端70%左右流量，随着商户数激增，QPS也会成指数级上升，所以我们对于轮询服务，我们做了很多优化的过程，后面会大概介绍一下整个优化的过程。对于推送服务，有两个基本的要求，一个是推送的及时性；另外是推送成功率，在外卖的业务模式下，商户对于漏单基本上是零容忍的状态，我们需要确保服务有效性，后面会有进行相关详细的说明。

前面我们介绍的PC，安卓，IOS，相关的新单基本流程以及服务端的基本工作，伴随商户增加，我们也收到了挑战，首先，没有非常精准数据统计，比如：新单到达商户的比例、新单到达率是多少、线上出现有单不响或者是新单不提醒的商户比例是多少，其次，经常收到商户、BD、商服反馈，抱怨订单没有提醒。每次收到相关类似问题，研发都需要做相关的排查工作，既耗费精力又耗费人力。

针对上面的问题我们也着重对于各个端上的处理逻辑进行相关的优化，首先，PC端最主要的是商户系统设置，我们会定期检测商户的电脑端的系统设置，如果检测到影响到商户新单提醒的错误配置，我们进行相关的提醒，引导商户进行设置，保证商户网络、设备环境属于可运行状态。其次，登陆过期自动退出，我们队帐号系统进行了升级，保证商户帐户在连续登陆的状态下，我们不进行主动退出登陆操作，虽然存在一定的安全隐患，但是在风险可控的情况下保证商户新单到达率是可以接受的；同时，我们提供网络辅助小工具，协助商户进行相关的检测，检测商户的网络环境；最后，我们对商服进行相关培训，由商服协助定位解决一些问题，并定期收集相关的案例，由服务端同学进行相关的统一整理、排查，这上面是属于PC端相关逻辑的优化。从目前收到的案例来看，PC主要问题比较集中于网络原因以及商户本身设置问题，通过上面几个优化方式，解决了在PC端来单不响大部分案例。

接下来针对优化的大头--安卓，从安卓的整个处理机制，我们可以看出安卓在这方面上做了很多优化，黄色标注的是我们着重做的优化，首先针对之前的APP是否活着这种案例，我们最终做了一个白名单策略，通过系统内部进行进程设置，保证我们的APP不被其它的杀死，同时会有定期重启操作，同时我们针对网络也进行了相关的优化，我们将网络错误率从5%降到2.8%左右，同时当APP属于Wifi状态下，安卓APP是不休眠的，同时我们在APP上上线使用的帮助，引导用户可以设置wifi不休眠，另外说到的一个是声音的播放，我们会优先进行铃声的播放，当用户检测到静音模式的时候，会引导用户进行声音的打开，同时引导用户关闭免打扰模式，额外，我们提供自检工具，我们首先是对于APP的存活状态、网络状态、定时状态、声音设置等跟新单提醒密切相关进行定期检测，当检测不符合预期时，引导商户进行相应的设置。虽然，安卓在这方面上做了很多优化的工作，但是由于安卓系统的开源，我们做的相关的优化工作属于一个不断演进的过程。我们当前的方案可能并不适用在新的系统上，我们需要一个不断的迭代升级、优化的过程，所以我们引入了商服，我们针对商服进行了相应的培训，由商服来进行协助，不限于安卓。

现在介绍下iOS系统的优化工作，由于iOS系统的封闭性以及稳定性，优化工作相对简单。首先，前面提到APP后台运行响铃一次，我们采用多次推送，保证新单能够得到多次提醒的机会；另外，推送服务的延迟，我们会通过独立实例保证服务隔离、稳定；另外，我们在iOS和安卓里面支持日志上传功能，iOS和安卓会将相关的本地操作的进行收集存储，当出现相关的问题进行日志上传，由日志收集系统进行收集，方便端上问题定位。

这是我们在iOS上，安卓和PC端上的优化。前面提到的服务端，最主要是保证两个服务的稳定性，一个是轮询服务，另外是推送服务。在这边我不进行扩充讲，我简单说一下服务端的稳定，主要是推送服务的稳定。在这个介绍前，首先普及几个基本的名词，一个是WAF流量接入层，进行相关的流量控制和分发，第二个概念是我们的ODP框架，是百度内部自己开发的一个AP框架，比较类似我们现在开源Yaf框架。前期业务规模比较小，问题不是很突出，后期伴随着商户数的膨胀以及业务的复杂，我们针对于轮询接口进行了拆分，独立的ODP，进行相关的资源隔离。当轮询服务以及业务服务出现问题，他们相互独立、互不影响。同时我们针对轮询业务进行了降级预案。同时，我们针对业务进行了业务缓存，根据二八原则，绝大部分订单是集中在20%~30%的商户上，每天订单量在个位数的商户数会占订单总数的大部分，所以大部分的商户是空轮询状态，我们建立了缓存机制，缓存清除触发的基本方案主动清除（当商户来新单的时候），保证缓存里面的数据都是最新有效的数据。这样避免了请求直接落到服务上，降低了服务端的压力。

虽然我们做了不少优化工作，但是需要考虑一个的兜底方案，确保一些突发状态下服务稳定，所以我们引入了IVR服务，简单的说是语音呼叫服务。接听者可以根据语音呼叫电话上面的提示进行接单或者取消订单的操作，我们会在订单在第三分钟或者是第五分钟仍为被商户接单的情况下，服务端按照商户提供的联系方式进行IVR的语音呼叫通知商户进行接单，这个是我们IVR语音呼叫的基本的服务。通过这个方式我们做到了一些极端异常案例的兜底方案。

这个是目前我们商户对于新单的兜底策略，后面我们针对IVR本身的服务的呼叫系统里我们也进行了相关的优化。以上这些是今天要分享的主要内容，从整个新单业务逻辑，以及是在基本逻辑中遇到的一些问题，我们是怎么优化、解决，并提供相关兜底方案，不知道大家有没有一些问题进行反馈。

最后打个广告，这个是我们百度外卖技术团队里自己的微信公众号，大家可以扫描关注一下，后面有相关的技术的业务场景或者是技术方案，都有在上面进行相关的分享，感谢大家收听，谢谢。