叨絮
相信很多小伙伴的公司都是服务治理，自动化运维了吧，那么我们很多东西都变成我们自己去设置了，比如自己创建一个域名，绑定他的代理机器，它的web负载均衡这些东西。所以今天跟大家一起来看看负载均衡
如果不愿意看文字的话，图也是很清晰的哦
你怎么看负载均衡
负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。
- 相信很多小伙伴，一听到负载均衡四个字，第一个想到就是我们所说的Nginx吧，因为这个是离我们开发比较近的一个组件了。
- 第二个呢？就是我们Springcloud的组件中自带了负载均衡(ribbon)，这个也是离我们开发比较近的
- 第三个？就是其实我们k8s里面的服务也是能做负载均衡的，目前主流容器使用方式
- 第四个就是我们DNS之后的一个负载均衡了SLB（这个之前运费负责的多点）
为啥要负责均衡呢？
大家看下面的图，当我们访问一个网站的时候，如果突然的流量增加，就会导致我们的服务不可用（单点故障）
一个没有负载均衡的 web 架构类似下面这样：
所以为了解决单点问题我们需要负载均衡（也是我们高可用，高性能，高并发的基石）
有负载均衡的架构
web架构
聊聊SLB
相信很多公司都有用到把，
负载均衡的组成
- 负载均衡实例 （Instances）：一个负载均衡实例是一个运行的负载均衡服务，用来接收流量并将其转发给后端服务器，至少添加一个监听(Listeners)和两台ECS实例。
- 监听(Listeners):监听客户端的请求并将其转发给后端服务器，监听也会对后端服务器进行健康检查。
- 后端服务器（Backend Servers）：后端服务器是一组接收前端请求的ECS实例，可以单独添加ECS实例到后端服务器池；
健康检查
Nginx负载均衡
如果你们还没用上容器，那么肯定是用Nginx来做负载均衡的了。
至于搭建这边就不讲了，大家百度下，肯定是能知道的。
SpringCloud负载均衡ribbon
springcloud中提供了一系列的组件，我们使用ribbon实现负载均衡，eureka中也内置了ribbon，所以，引入了eureka其实就可以直接使用ribbon了
ribbon中的负载均衡用在客户端，或者说成消费端也可以，在消费者访问提供者时，就会进行负载均衡算法，然后找到一个最优的提供者提供服务
K8s 服务治理的负载均衡（Ingress）
k8S的负载均衡模式还挺多的，这边我就说一个吧Ingress
Ingress 是 k8s 的一种资源对象， 该对象允许外部访问 k8s 服务， 通过创建规则集合来配置访问权限，这些规则定义了哪些入站连接可以访问哪些服务； Ingress 仅支持 HTTP 和 HTTPS 协议； ingress 可配置用于提供外部可访问的服务 url、负载均衡流量、SSL终端和提供虚拟主机名配置。
ingress 的工作流程如下；
大概的访问路径如下：
用户访问 --> LB --> ingress-nginx-service --> ingressController-ingress-nginx-pod --> ingress字段中调用的后端pod
面试题 nginx四层和七层负载均衡的区别
简单理解四层和七层负载均衡
- 所谓四层就是基于IP+端口的负载均衡；七层就是基于URL等应用层信息的负载均衡；同理，还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换句换说，二层负载均衡会通过一个虚拟MAC地址接收请求，然后再分配到真实的MAC地址；三层负载均衡会通过一个虚拟IP地址接收请求，然后再分配到真实的IP地址；四层通过虚拟IP+端口接收请求，然后再分配到真实的服务器；七层通过虚拟的URL或主机名接收请求，然后再分配到真实的服务器。
- 所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。 比如四层的负载均衡，就是通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。
- 负载均衡器通常称为四层交换机或七层交换机。四层交换机主要分析IP层及TCP/UDP层，实现四层流量负载均衡。七层交换机除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息。
结束
作为一个互联网工具人，你必须知道整一个用户流量的流转过程，这样你才能对流量的每个环节去掌握，也就是先要把一个东西串起来，然后一个个去拆解里面的细节。
总结下上面几个说到的负载均衡的顺序吧
首先流量DNS解析之后肯定我们一般用的是SLB这种，然后如果是物理机部署（Nginx负载均衡+SpringCloud负载均衡） 如果是容器的话，那么就是k8s的负载均衡了，主流的就是这样情况了。
一个系统的完整架构图
