业务场景
假设我们在abc.com域名下有两个服务，分别为 Search-Service 和 API-Service。
用户端
Search-Service 提供搜索服务，通过search.abc.com为用户提供服务。 API-Service 提供搜索服务，通过api.abc.com为用户提供服务。
用户看不到这两个服务的实现细节。
服务端
早期，Search-Service 内部使用百度提供的搜索服务。 后来，Search-Service 增加了必应的提供的搜索服务，用户对此增加的过程无感知。 最终，Search-Service 按照一定的权重来使用两者的服务。
API-Service 内部使用聚合数据提供的API服务，为了保证稳定性，聚合数据提供了两套服务，API-Service 按照一定的权重来使用这两套服务。
架构图
在 Konga 中新建 Upstream
新建 search-upstream
有 baidu.com 和 bing.com 两个Target，权重各为100。
新建 api-upstream
有 op.juhe.cn 和 v.juhe.cn 两个Target，权重各为100。
在 Konga 中新建 Service
在 Konga 中新建 Route
测试
正常情况
用浏览器多次访问：search.abc.com:8000（kong监听8000端口，域名需要本地解析），发现跳转到百度和必应的情况各占50%。
| 输出结果 | 占比 |
|---|---|
| 跳转到必应 | 50% |
| 跳转到百度 | 50% |
用浏览器多次访问：api.abc.com:8000（kong监听8000端口，域名需要本地解析）：
| 输出结果 | 占比 | 备注 |
|---|---|---|
| Juhe Open Api V1.0 | 50% | op.juhe.cn/ 的输出结果 |
| Juhe Open Api V3.0 | 50% | v.juhe.cn/ 的输出结果 |
一个 Target 失效的情况
将聚合数据提供的其中一个服务标记为失效：
用浏览器多次访问：api.abc.com:8000（kong监听8000端口，域名需要本地解析）：
| 输出结果 | 占比 | 备注 |
|---|---|---|
| Juhe Open Api V1.0 | 0% | op.juhe.cn/ 的输出结果 |
| Juhe Open Api V3.0 | 100% | v.juhe.cn/ 的输出结果 |
可见，虽然其中一个 Target 失效，对使用 api.abc.com 的用户来说，服务依然是可用的。
SDK社区是一个中立的社区，这里有多样的前端知识，有丰富的api，有爱学习的人工智能开发者，有风趣幽默的开发者带你学python，还有未来火热的鸿蒙，当各种元素组合在一起，让我们一起脑洞大开共同打造专业、好玩、有价值的开发者社区，帮助开发者实现自我价值！
