> >

业务容灾

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

如有域名相关的限制，请将 *.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，防止伪造客户端异常场景而绕过验证。真实的客户端异常多由于网络问题造成，可通过切换/刷新网络等自助手段解决，部分极端场景下极验可开启流量放行保障业务连续。