webContextUnify的作用

为了更好理解spring.cloud.sentinel.webContextUnify的作用，我直接提供一个详细的场景，包括完整的目录结构和URL路径。

假设我们有两个微服务应用：用户服务（UserService）和商品服务（ProductService）。它们的目录结构和URL路径如下：

1. UserService:

/userapp
├── api
│   ├── users
│   │   ├── list
│   │   └── details
│   └── auth
│       ├── login
│       └── logout
└── internal
    └── health

2. ProductService:

/productapp
├── api
│   ├── products
│   │   ├── list
│   │   └── details
│   └── categories
│       └── list
└── internal
    └── health

现在，让我们看看在不同 webContextUnify 设置下，Sentinel 如何处理这些路径：

当 webContextUnify = true （默认）

在这种情况下，Sentinel 会忽略根路径（/userapp 和 /productapp），但保留其余的路径结构。

UserService 路径:

/userapp/api/users/list -> /api/users/list
/userapp/api/users/details -> /api/users/details
/userapp/api/auth/login -> /api/auth/login
/userapp/internal/health -> /internal/health

ProductService 路径:

/productapp/api/products/list -> /api/products/list
/productapp/api/products/details -> /api/products/details
/productapp/api/categories/list -> /api/categories/list
/productapp/internal/health -> /internal/health

在这种配置下：
"/internal/health" 的规则会应用于两个服务的健康检查端点。

当 webContextUnify = false

此时，Sentinel 会考虑完整的URL路径，包括根路径。

UserService 路径保持不变:

/userapp/api/users/list
/userapp/api/users/details
/userapp/api/auth/login
/userapp/internal/health

ProductService 路径也保持不变:

/productapp/api/products/list
/productapp/api/products/details
/productapp/api/categories/list
/productapp/internal/health

在这种配置下：
健康检查端点 "/userapp/internal/health" 和 "/productapp/internal/health" 需要单独配置。

实际应用场景

1. 使用 webContextUnify = true:

• 适合当你想为多个服务的相似功能设置统一的规则。
• 例如，可以为所有 “/api/*/list” 端点设置通用的限流规则，无论它们属于哪个服务。

2. 使用 webContextUnify = false:

• 适合当你需要精确控制每个服务的每个端点。
• 例如，你可能想对 UserService 的登录接口 (/userapp/api/auth/login)
  设置特定的限流规则，而不影响其他服务。