API网关-负载均衡

外部负载均衡

外部指的是API网关所管辖的微服务，这些微服务如果部署的是单实例，那么如果发生故障了，服务就不可用了。那么如何解决这个问题呢？

做高可用有两种方式：

• HA：主服务和备用服务，只有在主服务挂了的时候备用服务才能顶上。
• LoadBalancer: 负载均衡，多个服务实例按照某种策略被轮着访问。

我们在这里采用负载均衡的方式，说到负载均衡，你可能想到了Nginx、Apache、Haproxy，没错，这些都可以作为负载均衡器，但是我给各位的建议是尽量避免惯性思维。

为什么这么说呢？

就负载均衡本身来说，就是一些选择策略的问题，比如轮询、随机、最小连接数等等。各位完全可以自己实现这些功能，如果你懒得写，网上应该可以找到大把的开源方案。所以实在没有必要为了负载均衡就引入Nginx、Apache、Haproxy这些组件，在引入了这些组件后，还需要给它们做高可用集群，这会增加架构设计的复杂度。

有的RPC框架自带负载均衡功能（比如Dubbo)，有的就没有(比如gRPC)，所以如果你的微服务中全是Dubbo框架的服务，那么你不需要负载均衡，因为Dubbo已经帮你做掉这部分工作了，但是如果你的微服务中有gRPC这种的，你就需要设计自己的负载均衡模块。如下图所示：

内部负载均衡

API网关本身需要做到高可用，怎么做呢？

假如API网关里面的各个模块都是以微服务的形式运行，那么除了接受请求的模块暴露的是RESTful接口，其他模块暴露的都是RPC接口。

要做到高可用，每个模块都需要运行多个副本，这样一个挂了，请求会被打到其他副本上，不影响API网关正常运行。

API网关我们建议用RPC框架+微服务的架构来设计，是为了让大家能更好的学习微服务思想和RPC框架，但是如果你就是想用常用的WEB框架来实现，也是可以的，我们就分几种情况来讨论下。

用WEB框架来实现

API网关对外暴露的是REST方式的接口，内部各个组件是一个整体。为了实现负载均衡，架构如下图，

用RPC框架来实现

由于有的RPC框架自带注册中心和负载均衡功能，而有的没有，所以这里我们就分两种情况来讨论。

使用自带注册中心和负载均衡功能的RPC框架来构建API网关

设计如下图所示，

使用不带注册中心和负载均衡功能的RPC框架来构建API网关

如果负载均衡模块独立出来以单独的微服务运行的话，API网关内部微服务可以和外部微服务的使用同一个负载均衡模块。如下图所示，假如API网关内部微服务的每个组件微服务都允许两个副本，每个微服务所在机器上也部署一个负载均衡模块，那么请求会通过负载均衡发送出去。

从上面的两个架构图中可以很容易的看出，采用自带注册中心和负载均衡功能的RPC框架来构建API网关要容易一些。