试用Kong的负载均衡功能

业务场景

假设我们在abc.com域名下有两个服务，分别为 Search-Service 和 API-Service。

用户端

Search-Service 提供搜索服务，通过search.abc.com为用户提供服务。 API-Service 提供API服务，通过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.050%http://op.juhe.cn/ 的输出结果Juhe Open Api V3.050%http://v.juhe.cn/ 的输出结果

一个 Target 失效的情况

将聚合数据提供的其中一个服务标记为失效：

用浏览器多次访问：api.abc.com:8000（kong监听8000端口，域名需要本地解析）：

输出结果占比备注Juhe Open Api V1.00%http://op.juhe.cn/ 的输出结果Juhe Open Api V3.0100%http://v.juhe.cn/ 的输出结果

可见，虽然其中一个 Target 失效，对使用 api.abc.com 的用户来说，服务依然是可用的。