首页 > 代码库 > 微站共享公众号的方案设计

微站共享公众号的方案设计

业务模式

由于微信的火爆,出现了很多提供公众号二次开发的平台公司。主要的业务都是为客户的公众号做二次开发,提供诸如微门户,微商城这样的服务。一般都是客户在平台上申请一个唯一的业务ID,然后将自己的公众号绑定到此ID上,所以公众号和微站是一一对应的

但是,申请公众号,特别是认证服务号的门槛比较高。我司由于所处行业的特点,用户基本上很难有资质申请到。所以我们的模式,是由我司提供一个共享的公众号,用户可以使用共享公众号提供的服务;同时如果用户自己能够提供公众号,也支持将专用的公众号接入到平台

URL规划

前面说到,大部分平台公司提供的微站URL类似于这样:www.pt.com/wsite/:ptid/shop,然后根据路径中ptid,就可以再从关联表中查到此ID对应的公众号信息(包括app_id,app_secret等)。因为前面说过,这种模式的平台id和公众号是一一对应的,所以才能这么做

但是混合模式的话,URL需要带上公众号的标识才行,所以URL类似:www.pt.com/wsite/:appId/:ptId/shop,多了一个appId,这样才能区分出,此页面当前是从哪个公众号打开的。如果URL中没有这个标识的话,由于一个页面,既可以从共享公众号打开,也可以从专用公众号打开,那么就没有办法判断当前所在的公众号了

比如以下这个场景,从微信OAuth页面跳转到微站,得到了访问者的code,接下来就需要根据code调用公众平台接口获取open_id,调接口需要app_id作为参数,此时URL中的appId就可以起作用了

数据模型设计

在数据库中保存粉丝的绑定关系时,混合模式也需要多保存app_id字段。比如业务系统里有member_id,那么专用的模式,可能只需要保存member_id和open_id就足够了,因为根据member_id,就足以找到平台唯一id,继而关联找到app_id,所以open_id对应哪个app_id也是唯一的

但是共享公众号和专用公众号混合的模式,上述数据模型也是不行的。因为最终用户可能是从专用公众号绑定的,也可能是从共享公众号绑定的,所以光凭借member_id,无法唯一确定app_id,因此在数据库表里,也需要同时保存app_id,才能唯一标识出粉丝,正确调用接口

比如以下这个场景,当用户到店消费以后,要给他发送一条模板消息。虽然根据member_id找到了open_id,但是还需要app_id才能调用模板消息接口,如果没有保存app_id的话,光凭借member_id,是查不到的

总结

关键是我们的平台不但提供了共享公众号,还支持专用号和共享号的混合模式。所以凡是涉及到用户标识的地方,都需要主动携带app_id信息。而平台id和公众号一一对应的方案,就不需要,因为可以根据平台id关联找到对应的公众号

微站共享公众号的方案设计