架构系列（六）负载均衡器的妙用，结合VPC内网让你服务之间通信无压力

介绍

无论aws的elb（alb）还是阿里云的slb，其实都是一层类似反向代理的服务（集群）。可以直接指定lb对外的端口以及所映射的后面服务器集群的端口，达到访问lb就可以访问后面的服务器

这也是为什么一定要所有机器都用内网IP，如果想单独开放某机器ip，那么选择lb方式进行映射。不用担心性能和网络传输，内网传输底层都是光缆，速度非常客观。通常在2-5毫秒

在博主之前的博客中有介绍到VPC，当我们设定了自己的内网集群，那么严格意义上来说，所有的服务都可以使用此VPC。所以，内网负载均衡器最好也严格按照设定的VPC进行ip划分

优化架构

通常来讲，一个业务集群内，应该是不存在单节点的（除了传统全量服务扩展，这样的架构只需要在最外层挂载负载均衡器即可）。

通用通信架构

微服务崛起后，大部分公司都是搭建一套微服务，以rest方式与服务发现注册结合，来做服务的相互通信。对外要么直接开放ip，要么做一个gateway。这样的情况下，注册发现、gateway、服务的多节点扩充和性能是比较重要的问题

大部分公司因为业务场景，根本不需要高并发。所以只是搭建一套最简单的脚手架，把微服务用起来，服务器和网络没做特殊的切割和要求。但是在一些大公司，对于服务器和网络等安全要求极其高，并且还涉及到合规设计等方面。所以往往服务器网络的设计远远比应用架构大的多（这也是为什么运维成本巨大）

我们来看一下，基于微服务最普通的架构体系：

图上基于注册发现，然后内网直接使用rest交互，如SpringCloud组件的eureka与feign等。那么这样所带来的问题是：

• 服务注册发现动态扩展很困难，虽然支持多ip，但是需要修改配置。动态修改配置又要涉及到配置中心，那么配置中心如何高可用，一层套一层（我只是实现一个简单的查询，至于这么玩么～～～ -。-！！）
• gateway扩展，很多公司将域名或者访问路径直接绑定在gateway，认为万无一失，这样里面的服务就不会对外暴露，但是gateway如何动态扩展？服务统一注册gateway之后，api又如何管控？

所以对于服务注册发现、网关隔离、api对外开放、服务动态扩展等一系列的问题，我们在设计架构需要认真考虑。（小业务场景不用考虑，单服务暴力走起）

使用LB的多节点架构

我们排除部分单节点，使用负载均衡，优化我们的架构：

可能有人会问：那负载均衡万一是单节点呢？ 这点博主非常负责人告诉你：一定是集群。 如果你使用云LB组件，这肯定后面有一整片的反向代理集群。如果公司选择自己搭建整个架构，那么参考云组件，我们是否可以先做一整套的LB组件来使用

负载均衡器的使用，帮助我们解决了单节点的问题，并且负载均衡器（阿里云为例）支持最高5wQPS的量级（还可以更高，需要申请），对于90%的公司都完全没任何问题

负载均衡器LB创建（阿里云为例）

这里博主因为展示原因，按量付费，可以选择多可用区

• 超强型，网络带宽5g，连接数和qps也很高，完全可以支撑90%的公司的业务
• 选择私网 -> 专有网络（VPC） -> 自己设定的交换机

确定即可，这样就完成了一个LB的创建

如果公司自己有自己的infra team， 不实用云资源，可以参考云组件，先将负载均衡这样的共有组件开发和部署。

负载均衡器LB配置（阿里云为例）

查看LB属性

可以看到整个LB属性。这里博主拿自己团队测试的 实时流计算logger服务为例

添加监听

点击添加监听按钮

• 协议：这里是指访问这个负载均衡用什么协议访问，一般情况下都是https，博主这里是TCP
• 监听端口： 这里指访问此负载均衡的端口号，web的话，填写443没什么问题

后端服务器

负载均衡器可以挂载N个服务器

• 虚拟服务器组：这个就是给服务器一个组，这样添加一个服务器直接往这个组里添加即可，然后slb挂载这个服务器组
• 默认服务器组：这个可以指定某个服务器，一个一个的添加，直接关联到服务器
• 主备服务器组： 和虚拟服务器组一个概念，你要单独创建一个服务器组
• 端口：这个就是负载均衡要访问服务器下的某个端口（client -> slb端口 -> 服务器端口）
• 权重：这个是服务器的权重，一个100一个200，那么访问3次，200的被访问两次

健康检查

健康检查还是要开启的

最后

点击确定之后，你可以发现slb已经开始工作。访问slb可以访问到你后面集群的服务。

在设计架构的时候，对于网络划分一定要有非常明确的目标。内网和外网一定要有明确的隔离，才可以保障服务器和网络的安全