小程序/小游戏后端获取当前appid、版本号和接口环境控制
发布于 5 年前 作者 gyang 5055 次浏览 来自 分享

写在前面的话

我们的后端架构是基于微服务的平台化架构,提供了一套通用的接口,所有的小程序/小游戏都走这套接口,由负载均衡统一分发,这样就需要区分是哪个应用的哪个版本访问的接口,以便准确的处理数据。

解决方案

一、请求时将 `` appid `` 和版本信息放入参数中提交给后端。  
优点:简单,直接。  
缺点:只能将信息传给后端,而后端无法控制小程序/小游戏端逻辑。
二、使用 <a href="https://developers.weixin.qq.com/miniprogram/dev/api/wx.getAccountInfoSync.html" rel="noopener" target="_blank">wx.getAccountInfoSync</a> 接口获取账号信息。  
优点:官方提供的API。  
缺点:里面只有 `` appid ``,没有版本信息,存在和 `` 方案一 `` 同样的问题且不支持小游戏。
三、后端获取Referer信息,从里面获取信息。  
优点:<a href="https://developers.weixin.qq.com/miniprogram/dev/api/wx.request.html" rel="noopener" target="_blank">wx.request</a> 中 `` header `` 内 `` Referer `` 的值是默认生成不可以设置的且格式固定。  
缺点:无法区分开发版本、体验版本和审核版本, `` 方案一 `` 的问题依然存在。
四、自己维护版本信息,提供一个远程的版本信息同步接口。  
优点:可扩展性高。  
缺点:开发时需要定义版本信息,小程序/小游戏每次打开时都需要同步版本信息。

最佳方案

我们选择了 方案三 配合 方案四 来实现,主要原因是因为 wx.requestheaderReferer 的值是默认生成不可以设置的且格式固定,并且里面包含了 appid版本号 [小程序自己的版本号,并不是我们自己定义的版本号,且只有线上版本的] 的信息。小程序/小游戏端无需增加参数后端即可获取这些信息。

Referer 的格式固定为:

https://servicewechat.com/{ appid }/{ version }/page-frame.html

其中 { appid } 为小程序的 appid{ version } 为小程序的版本号,版本号为 0 表示为开发版本、体验版本以及审核版本,版本号为 devtools 表示为开发者工具,其余为正式版本。

以上描述摘自官方文档 网络 的章节

开发版本、体验版本以及审核版本的 version 都为 0 ,然而在开发过程中后端分为 devtestuatprod 等不同的环境,只使用 方案三 并不能完美的解决问题,这种方式前端并不能获取到当前版本的状态,无法动态的切换访问的环境,如果都去通过负载均衡去分发,反而给负载均衡带来了压力,所有环境都部署在外网也不现实。

于是我们想到了一个解决办法,也就是 方案四,自己维护版本号。通过版本状态来判断当前版本需要请求的环境。

实现思路

小程序/小游戏分为开发版本、体验版本、审核版本和线上版本。

  • 开发版本是由开发者进行上传才可以访问的,开发者工具模拟器、预览和真机调试的不会出现在这里。
  • 体验版本是由管理员选定某个人提交的开发版本作为体验版的。
  • 审核版本也是由管理员选定某个人提交的开发版本进行提交审核的。
  • 线上版本是审核版本审核通过后,管理员进行发布的。

不同角色的人员如何访问对应的版本

角色 环境 版本 小程序/小游戏的访问方式
开发 dev 使用开发者工具模拟器、预览或真机调试进行访问
测试 test 开发版本 使用 小程序助手 小程序,访问不同开发人员上传的版本
验收 uat 体验版本 扫描体验版二维码或使用 小程序助手 小程序进行访问体验版
审核 prod 审核版本 只有审核人员可以访问
用户 prod 线上版本 发布后全网可以访问

小程序/小游戏端定义自己的版本号,新版本开发时,版本号进行升级,同时后端数据库中添加当前开发中的小程序/小游戏版本号,并标识当前这个版本号的状态为 dev 开发阶段,提交测试时将版本号的状态修改为 test 测试阶段,用户验收时将版本号的状态修改为 uat 验收阶段,后续版本的做法以此类推。
后端提供一个接口,小程序/小游戏端打开后,首先调用这个接口进行状态同步,参数为当前的版本号,接口返回版本的状态。小程序/小游戏中通过硬编码的方式,根据状态来判断当前需要访问的环境地址。

需要后端先上线版本号管理的功能。

每个环境中的接口 pathname 是固定不变的,会变动的只有 origin
举例:

生产环境中的一个接口 https://examplp.com/api/login
验收环境中的一个接口 http://10.10.10.10:8080/api/login
测试环境中的一个接口 http://192.168.1.100:8080/api/login
开发环境中的一个接口 http://localhost:8080/api/login

其中 /api/loginpathname 是固定不变的,变动的只有前面的域名也就是 origin,小程序/小游戏端只需要根据版本号的状态去修改 origin 就可以了。

注意:使用这套方案时,一定要防止版本信息同步接口过度依赖而影响主业务的事情发生,请做好兼容处理。

功能扩展

通过这套流程不但可以动态的切换小程序/小游戏端访问不同环境的后端接口,还可以动态的停止线上的某个版本。

接口再扩展一个 openid 的参数,也可以指定某个人的访问环境。比如测试需要使用线上版本将接口转到测试环境等。

2 回复

开发个代理服务,一个域名解决所有环境情况

你们是如何解决不同环境下共用微信Session问题的?譬如同一个小程序,在验收和生产环境都分别进行了登录操作,由于微信没提供测试环境,这样会导致先登录的Session过期

回到顶部