Rainbond 作为一款云原生应用管理平台，天生带有引导南北向网络流量的分布式网关 rbd-gateway。rbd-gateway 组件，实际上是好雨科技团队开发的一种 Ingress Controller 实现。那么作为集群中部署的服务的网络流量出入口，如何为它设置反向代理呢？这篇文章会做出详细的解读。
实际场景
Rainbond 在企业内部一般会扮演云原生应用管理平台的角色，通过一站式开箱即用的使用体验，可以大幅度降低企业运维人员的管理成本。在网关策略方面，免去了运维人员配置相对复杂的 Service 、Ingress 资源配置文件的麻烦，在图形化界面下， 即可实现 L4 或 L7 的网关策略配置。
Rainbond 的网关组件 rbd-gateway 天生支持分布式部署。这就意味着，我们可以在外部流量和 Rainbond 网关集群之间设立负载均衡，来进行流量的分发，使网关具备容错能力的同时，成倍提升其抗并发的能力。
这种负载均衡可以是物理的，也可以是软件定义的，当然也可以是云服务商提供的。今天重点探讨如何使用 Nginx 实现的全局负载均衡器实现对网关的负载。
负载均衡与VIP的对比
当企业没有负载均衡时，也可以直接将 Rainbond 的网关直接暴露给外部访问流量，在这种情况下，我们一般会为集群部署 VIP 虚拟IP，这个 IP 地址可以在多个网关节点之间漂移，当网关节点发生故障时提供高可用特性。通过将域名解析指向 VIP，网关节点集群拥有了一个统一的访问入口。但是相对于负载均衡而言，VIP 方案还是有些劣势的。
- VIP 方案不提供高并发：由于VIP同时只会绑定在一个网关节点上，所以同一时刻，只会有一个网关节点接受流量。负载均衡方案可以将流量分发到每一个网关节点，故而提供了高并发能力。
- VIP 方案相当于将网关直接暴露向公网，这在安全方面有一定的隐患。负载均衡同时也是一种反向代理，可以将网关节点保护在其身后。
我们可以得出结论：当企业内部存在负载均衡设施的时候，就不再需要为网关节点集群设置 VIP 。
Nginx 负载均衡特性
Nginx 提供了强大的流量转发能力。作为负载均衡时，Nginx 提供的稳定性和性能表现都堪称惊艳，甚至不逊色硬件负载均衡。这些特性，使它成为了大部分企业在软件定义负载均衡领域的第一选择。它可以同时提供 L4 、L7 层负载均衡能力，支持 SSL 证书、多种负载均衡算法等高级特性。
L4负载均衡
L4 负载均衡策略，其目的是在 Nginx 负载均衡的配置中，实现负载均衡的端口，到后端所有网关节点的指定端口的流量转发。一般用于最终业务并非使用 Http 协议工作的场景。比如 Mysql 业务对外暴露 3306 端口的场景。
Rainbond网关配置
在 Rainbond 一侧，需要在网关策略中，为 Mysql 一键开启如下的设置：
对上述配置作出如下解释：
- 端口号: 3306 # Mysql 业务监听的端口
- 端口协议: mysql # 业务端口协议，可选值包括 TCP、UDP、HTTP、MYSQL、Grpc，此处 MYSQL 可以理解为 TCP中的一种
- 对外服务: 开启 # 用户通过开启此开关来将 Mysql 的 3306 端口对外暴露服务
- 访问策略: 0.0.0.0:10001 # 网关的代理策略，这里意味着将 Mysql 的 3306 端口，通过所有网关节点的 10001 端口对外代理
负载均衡配置
在负载均衡一侧，则需要添加一段 Nginx 配置，将所有网关的 10001 端口，通过四层代理，对外暴露。
Nginx 的配置文件，需要在最顶层创建一个 stream{} 块。这一句翻译自 Nginx 官方文档，实际操作时，其意义是不要将 stream 放入到 http 块中去。
继续在 stream{}块中分别创建 upstream{} 和 server{} 块。
stream {
upstream lbserver {
server 192.168.0.1:10001;
server 192.168.0.2:10001;
server 192.168.0.3:10001;
}
server {
listen 10001;
proxy_pass lbserver;
proxy_connect_timeout 1s;
proxy_timeout 3s;
}
}
重新加载配置文件之后，就可以通过 Nginx 对外IP地址的 10001 端口，访问到 Mysql 业务的 3306 端口了。
L7负载均衡
L7负载均衡，一般用于 Http 业务的处理。当我们希望通过一个域名，可以访问到部署在 Rainbond 上的 Http 业务时，这种用法就会派上用场。接下来聊一聊如何在负载均衡上，处理 Http 请求。
实际上，Rainbond 的网关节点也是一种负载均衡，网关节点负载均衡是为了将流量分发到运行于 Rainbond 集群中的业务实例上去。根据网关所使用的负载均衡策略，我们可以在使用 L7负载均衡的情况下，继续细分两种场景：
- 网关使用 L4 负载均衡
- 网关使用 L7 负载均衡
而这两种场景下，我们都希望通过一个解析到 Nginx 负载均衡对外 IP 地址的域名，访问到部署于 Rainbond 集群中的 web 服务。假定这个域名是 index.guox.grapps.cn .
网关使用 L4 负载均衡
网关使用 L4 负载均衡时，Rainbond 一侧的配置是不需要进行调整的。接下来的用例，我使用一个工作于 80 端口的 web 服务作为示例。依然在 tcp 协议下，开启访问策略。
此时，web 服务的 80 端口会通过网关的 10002 端口暴露出来。
而在 Nginx 负载均衡一侧，则需要基于域名配置一个虚拟服务器（Virtual Servers）。并将所有的网关节点的 10002 端口作为这一虚拟服务器的上游。
Nginx 的配置文件，在 http{} 块中进行配置，分别创建 server{} 和 upstream{}。
upstream lbserver {
server 192.168.0.1:10002;
server 192.168.0.2:10002;
server 192.168.0.3:10002;
}
server {
listen 80;
server_name index.guox.grapps.cn;
location / {
proxy_pass http://lbserver;
}
}
重新加载配置文件后，访问 http://index.guox.grapps.cn/ 就可以访问到 web 服务的主页。
网关使用 L7 负载均衡
网关使用 L7 负载均衡时，我们需要为 web 服务的 80 端口绑定目标域名，在端口协议为 http 时，点击添加域名即可添加目标域名。
即使这个域名并没有直接解析到 Rainbond 的网关上，我们依然需要绑定这个域名。因为 Rainbond 网关在 7 层工作时，需要通过域名来决定将流量转发到哪个服务实例上去。
那么如何将这个域名信息传递到 Rainbond 网关上去呢？答案是 proxy_set_header HOST $host。 Nginx 负载均衡在接受到带有指定域名的请求时，可以将域名信息编辑到 header 信息中向后方的 Rainbond 网关传递。
Nginx 的配置文件需要添加这一配置。
upstream lbserver {
server 192.168.0.1:80;
server 192.168.0.2:80;
server 192.168.0.3:80;
}
server {
listen 80;
server_name index.guox.grapps.cn;
location / {
proxy_pass http://lbserver;
proxy_set_header HOST $host # 将域名信息保存在 HOST 传递给下一层代理
}
}
优劣对比
L7 作为更高级的协议，提供了端口复用、TLS加密以及基于HTTP协议实现的各种高级功能。L4 是更通用的协议，所有基于 TCP/IP 协议栈实现的业务都可以使用。对于最外层的 Nginx 负载均衡而言，无论是 L4 还是 L7 都有各自合适的使用场景，所以并没有优劣之分。用户根据自己的需要被访问的业务类型判断：Http 业务使用 L7，其余情况使用 L4 。
但是，在最外层的 Nginx 使用 L7 负载均衡时，对于 Rainbond 网关使用哪一层的负载均衡策略是有区别的。在这里我推荐网关使用 L4 负载均衡。因为在实现同样效果的前提下，L4 比 L7 的开销更小。
一点扩展
当为一个基于 http 协议工作的端口开启对外服务的时候，Rainbond 会默认生成一个可以被直接访问的域名，比如下图中的 http://80.gr6538fd.0c9yg42x.695d35.grapps.cn/ 。但是我们今天并没有探讨直接通过网关分配域名的访问方式，关于这个自动生成域名的实现机制，感兴趣的同学请关注 详解 Rainbond Ingress 泛解析域名机制 。
在 Rainbond 网关策略管理中，对同一个端口，是可以同时绑定多个访问策略的。下图中既有基于域名的 L7 访问策略，也有基于 IP 端口转发的 L4 访问策略。
Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。
