
Decision Engine 如何开启 Autopilot 自动调优成功率评分并重置网关分数【免费下载链接】hyperswitchOpen source, composable payments platform | PCI compliant | SaaS and Self-host options | Enables connectivity to multiple payment, payout, fraud, vault and tokenization providers | Uplifts authorization with intelligent routing and revenue recovery | Reduce payment processing costs with cost observability | Reduces payment ops with reconciliation项目地址: https://gitcode.com/GitHub_Trending/hy/hyperswitch如果你的商户已经在用 Hyperswitch 的 Decision Engine 做基于成功率success-rate的网关路由手动调整评分参数会很快过时。Autopilot 是 Decision Engine 的自调优层它持续观察商户的真实流量自动重算成功率评分的两个关键参数——bucket size每个网关的分数用最近多少笔交易做平均和hedging %分流到非领先网关的探索流量比例。本文完成两件事通过 feature-flag API 为一个商户开启 Autopilot以及在需要用干净基线重新跑评分时重置该商户的网关分数。适用前提Decision Engine 服务已在本地或 Docker 环境运行你持有受保护路由所需的 API key 或 dashboard JWT且商户有真实的决策流量自调优任务从 ClickHouse 读取最近 3600s 的交易量。前提条件环境与服务按仓库内文档 Installation快速启动路径是 Docker Compose首次运行会拉取应用、PostgreSQL、Redis、Kafka、ClickHouse 等镜像docker compose --profile postgres-ghcr up -d curl http://localhost:8080/health预期响应{ message: Health is good }然后在 shell 中一次性设置好后续所有示例复用的变量来源为 API Guide 的 Environment setup# Base URL — 本地源码构建或 Docker Compose export BASE_URLhttp://localhost:8080 # 受保护路由接受 dashboard JWT 或 API key二选一 export AUTH_HEADERAuthorization: Bearer jwt_token # export AUTH_HEADERx-api-key: DE_api_key # 仅 analytics 路由、/health/diagnostics 和 /gateway-score/reset 需要。 # 发行配置中只定义了 public 一个租户 export TENANT_HEADERx-tenant-id: public其中jwt_token/api_key替换为你自己签发的凭据。如果走 Hyperswitch 沙箱BASE_URLhttps://sandbox.hyperswitch.io还需追加x-feature: decision-engine请求头。注意一个高频坑x-tenant-id没有回退机制在需要它的路由上漏传会直接报TE_03: x-tenant-id not found in headers即使 API key 有效。大多数路由/decide-gateway、/routing/*、/merchant-account/*等内部自行解析租户、不需要这个头只有本文的 analytics 校验和分数重置路由需要。另一点自调优任务依赖 ClickHouse 中的流量数据。按 Configuration 文档[analytics.kafka]和[analytics.clickhouse]必须都是enabled trueanalytics 才可用Docker Compose 运行方式已预先配置好。以下命令沿用文档示例中的商户 IDmerchant_demo如果你操作的是自己的商户把路径和请求体中的merchant_id统一换成实际值即可。第一步查看当前 feature flag 状态商户级的所有开关多目标路由、A/B 拦截、elimination、Autopilot、SR 自动校准都通过同一个 feature-flag API 读写curl $BASE_URL/merchant-account/merchant_demo/features \ --header $AUTH_HEADER文档示例返回{ merchant_id: merchant_demo, features: [ { feature: gsm-scoring-filter, enabled: false }, { feature: explore-exploit-srv3, enabled: false }, { feature: ab-test-real-payments, enabled: true }, { feature: multi-objective-routing, enabled: true }, { feature: elimination, enabled: true }, { feature: auto-calibration, enabled: true }, { feature: autopilot, enabled: true } ] }先确认auto-calibration与autopilot两项的当前值再决定下一步只改哪一项。第二步同时开启 auto-calibration 与 autopilot这两个 flag 共同控制同一个后台任务没有独立的运行 autopilot端点。分工是来源Merchant Features 文档auto-calibration控制任务是否考虑该商户。关掉时任务对商户完全不做事autopilot写权限开关控制任务能否把结果写回商户的 SR 配置。单独开着它、而auto-calibration关闭时它不产生任何效果。文档把这二者拆开是为了允许先只观察、暂不授权写入确认没问题后再放开写权限。切换命令按 flag 名拼接路径响应形状与列表调用相同——它会在写入后重新读回所有 flag 的当前生效状态所以每次切换后你都能直接确认整体状态curl --location $BASE_URL/merchant-account/merchant_demo/features/auto-calibration \ --header $AUTH_HEADER \ --header Content-Type: application/json \ --data { enabled: true }curl --location $BASE_URL/merchant-account/merchant_demo/features/autopilot \ --header $AUTH_HEADER \ --header Content-Type: application/json \ --data { enabled: true }判断依据两次响应的features数组里auto-calibration与autopilot均为enabled: true自调优才真正生效。开启后任务如何运转两项开启后后台任务按固定轮询周期运行默认 900s可通过config/*.toml中的[sr_auto_calibration]段或SR_AUTO_CALIBRATION_INTERVAL_SECS环境变量调整。每个周期它从 ClickHouse 读取商户最近 3600s 的交易量纯靠观测数据不接受商户输入推导两个 SRv3 参数Bucket size——被钳制在 100 到 2000 之间只有出现有意义的25 步变化时才重写Hedging %——上限 30%移动幅度不足 1.0pp 时不更新把结果写回商户的 SR 配置并打上source: autopilot标记便于区分自动写入值和人工配置。任务每次校准还会发出一条 analytics 事件flow_type: autopilot_calibration这是后面校验的依据。第三步验证自调优确实生效等至少一个校准周期默认 900s过去后用 Routing Events 路由查校准记录。注意 analytics 路由需要TENANT_HEADER来源Analytics Endpointscurl $BASE_URL/analytics/routing-events?range1d \ --header $AUTH_HEADER \ --header $TENANT_HEADER响应中的events数组里event_type为calibration_applied的条目就是一次 Autopilot 重调。该路由返回的事件类型共四种leader_changed、gateway_entered_auth_band、gateway_exited_auth_band、calibration_applied。同时可以读回商户的 SR 配置确认写入值带有source: autopilot标记端点见 Routing Config Endpointscurl $BASE_URL/config/routing-keys \ --header $AUTH_HEADERcurl $BASE_URL/config-sr-dimension/merchant_demo \ --header $AUTH_HEADER两点校验限制要提前知道analytics 写入是异步的刚产生的事件可能需要一小段时间才会出现在查询结果里文档未给出事件出现的具体时延承诺查不到时先确认时间窗口range/start_ms/end_ms覆盖了校准发生的时间且商户在窗口内确实有流量——任务从 ClickHouse 读的是最近 3600s 的交易量。第四步重置网关分数当评分状态需要回到干净基线例如文档提到模拟器 Hard refresh 场景让新一轮模拟从零开始时调用分数重置端点curl --location $BASE_URL/gateway-score/reset \ --header $AUTH_HEADER \ --header $TENANT_HEADER \ --header Content-Type: application/json \ --data { merchant_id: merchant_demo }这个路由和上面的 feature-flag 调用不同除了$AUTH_HEADER还必须带$TENANT_HEADER。文档示例返回{ merchant_id: merchant_demo, deleted_keys: 214, removed_overrides: 3 }以上为文档示例输出deleted_keys与removed_overrides的实际值随商户当前状态变化。该操作从 Redis 中清空该商户所有 SR v2/v3 的分数与队列键移除所有 Autopilot 写入source: autopilot的子级配置覆盖——人工配置的覆盖会被保留不会禁用路由也不会删除配置本身只是清掉在线评分状态让下一次决策从全新基线开始。执行后无单独的校验端点文档给出的判断口径是响应返回了删除键与移除覆盖的数量后续决策即从干净基线计算。限制与边界没有手动触发一次校准的端点只能等待轮询周期默认 900s到来调整周期靠[sr_auto_calibration]配置段或SR_AUTO_CALIBRATION_INTERVAL_SECS环境变量。发行配置只定义了public一个租户TENANT_HEADER传其他租户值不会通过需要多租户时按 Configuration 文档 在[tenant_secrets]中自行添加。关闭 Autopilot 只关掉写权限把autopilot置为{enabled: false}即可命令同第二步此前已写入并打上source: autopilot的覆盖值仍保留在配置中需要时可用分数重置一并清掉。沙箱环境https://sandbox.hyperswitch.io下所有请求需追加x-feature: decision-engine头本地部署不需要。深入端点 schema 时可参考仓库内 OpenAPI ReferenceAutopilot 与 feature flag 的完整说明见 Merchant Features。【免费下载链接】hyperswitchOpen source, composable payments platform | PCI compliant | SaaS and Self-host options | Enables connectivity to multiple payment, payout, fraud, vault and tokenization providers | Uplifts authorization with intelligent routing and revenue recovery | Reduce payment processing costs with cost observability | Reduces payment ops with reconciliation项目地址: https://gitcode.com/GitHub_Trending/hy/hyperswitch创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考