> >

业务容灾

1.业务容灾流程

背景:验证流程涉及客户前端(C端)、客户后端(B端)、极验服务端(G端)三个端的交互,异常场景分为前端请求异常(load)、后端请求异常(validate)和双端异常(load和validate)。

目的:业务容灾主要解决在验证服务异常时不阻塞C端和B端的正常业务流程,保障业务连续性。

以下是业务容灾流程图,异常场景

geetest 4.0 bypass

场景 非容灾模式异常表现 容灾模式表现
前端异常 初始化load失败,验证码无法加载 初始化失败,验证码一键通过
后端异常 validate请求失败,无法返回结果值,登录失败 validate请求失败,默认result成功,登录不受影响

2.业务容灾准备

极验容灾需要使用多域名,目前使用的域名如下所示:

主域名:gcaptcha4.geetest.com 、static.geetest.com
备用域名:gcaptcha4.geevisit.com 、gcaptcha4.gsensebot.com 、static.geevisit.com 、 dn-staticdown.qbox.me

如有域名相关的限制,请将 *.geetest.com、 *.geevisit.com 、*.gsensebot.com、dn-staticdown.qbox.me这些域名加入放行列表中。

前端部署:客户端容灾部署逻辑极验已经全部完成,无需客户主动集成。

服务端部署:服务端容灾部署需要客户在服务端集成时二次校验流程时,注意对二次校验的接口进行异常处理。 当请求极验二次验证接口异常或响应状态非200时做出相应异常处理,保证不会因为接口请求超时或服务未响应而阻碍业务流程,

示例代码如下:

try:
res = requests.post(url, query)
assert res.status_code == 200
gt_msg = json.loads(res.text)
except Exception as e:
gt_msg = {'result': 'success', 'reason': 'request geetest api fail'}

C#
https://github.com/GeeTeam/gt4_csharp_aspnetcoremvc_demo/blob/main/Controllers/IndexController.cs#L60
Java
https://github.com/GeeTeam/gt4-java-demo/blob/master/src/main/java/com/geetest/demo/controller/MainController.java#L60
Node
https://github.com/GeeTeam/gt4_node_express_demo/blob/main/routes/index.js#L65
PHP
https://github.com/GeeTeam/gt4-php-demo/blob/master/LoginController.php#L43
Python
https://github.com/GeeTeam/gt4-python-demo/blob/master/start.py#L53
Golang
https://github.com/GeeTeam/gt4_golang_demo/blob/main/main.go#L76

3.业务容灾测试

在完成所有接入工作后,请一定要进行全面的业务容灾测试,针对不同场景,极验提供推荐测试流程如下:

测试步骤 测试场景 测试接口 测试通过表现
1.提供captcha_id联系小助手开启容灾测试。 客户端异常 load 前端验证直接加载一键通过
2.前端点击验证是否直接一键通过。 服务端异常 validate 服务端返回成功,业务登录成功
3.点击登录/注册等业务接口成功进入业务。 客户端和服务端均异常 load+validate 前端验证直接加载一键通过后,业务登录成功

4.容灾流程相关问题

1、什么场景下会触发容灾模式?
客户端交互请求(load)和服务端交互请求(validate)HTTP Status Code 非200时,默认走极验容灾流程,触发对应场景的容灾模式。
2、已上线但是发现部分请求二次校验失败返回pass_token error。
如客户端异常场景下,直接加载一键通过,此时一键通过的pass_token为本地生成,在服务端交互正常时进行二次校验将验证失败返回pass_token error,防止伪造客户端异常场景而绕过验证。真实的客户端异常多由于网络问题造成,可通过切换/刷新网络等自助手段解决,部分极端场景下极验可开启流量放行保障业务连续。