写在前面：本系列文章只讲原理性和概念性相关的知识，目的在于对负载均衡和分布式技术有感性的认知，文中内容大多为我自己的理解，相关术语为自己杜撰，非权威学术术语、水平有限，如有错误 请谅解~
首先通俗的理解下负载均衡，广义上,负载均衡就是把数据从一个机器分发发到多个机器进行处理~
一、 硬件负载均衡和软件负载均衡
我认为其实除了网卡层面能对链路层帧进行发送，根本就不存在硬件负载均衡，所谓硬件负载只是专门的设备附加相应的软件实现的软件层面的负载均衡，比如路由器可看做专门转发IP数据包的设备，转发数据包相应的算法也是其rom中的软件实现的。如果大脑中常有硬件负载均衡概念的话，是不利于我们深刻理解负载均衡的本质的~
二、负载均衡设备(如F5、LVS软路由)和路由器的本质区别
我的观点：他们都属于包转发设备，路由器转发目的IP不属于自己的数据包，但是会收下目的IP是自己的数据包（目的IP是自己就收下,相当于主机功能），自己既有转发功能又有主机功能；F5，LVS软路由等设备，他们的职责是转发目的地址是自己IP的数据包到它所负载的实际机器，对于目的地址不是主机的数据包，可以选择丢弃或者走路由算法自己路由（就和和路由功能一样了）
三、 四层负载均衡和七层负载均衡
1 两者都做的是转发数据的功能,只是转发粒度不同,四层负载均衡的转发单位是IP层数据报、七层负载均衡的转发单位是应用层协议报文
2 四层负载均衡是IP层转发，转发时涉及到IP层和传输层协议的解析，UDP、TCP是基于IP的传输层协议，所以四层负载均衡可以对上层的UDP、TCP连接“透明”，绝大部分的应用服务器都是基于UDP/TCP协议的应用层协议，所以四层负载均衡适应面很广，基本上可以负载所有类型的应用服务器，如HTTP服务器、Redis、MQ、Mysql等等，这里用我自己的一句话概括：四层负载均衡负载的是"连接"
3 七层负载均衡是应用层负载均衡，而应用层都基于UDP、TCP连接,所以七层负载均衡软件转发时必要先建立传输层连接，解析出应用层报文，然后再和后端实际负载的服务器建立传输层连接，再把应用层报文转发给实际负载的服务器。由于七层负载需要建立传输层连接，占用资源比四层负载均衡要大，会受制于操作系统和硬件资源的限制；另外，七层负载均衡软件会涉及到解析应用层协议，所以只能对特定的协议做特定的实现，比如HTTP负载均衡软件只实现了HTTP协议的负载均衡，对于Redis协议就不支持，适应面较窄，通常，我们做自定义应用层协议的服务器的时候，都需要我们自己实现应用层负载均衡来打到分布式的目的~ 一句话概括：七层负载均衡负载的是应用层数据包
4 本质上讲，不管是四层还是七层负载均衡，目的都是把数据转发到不同的服务器处理，只是转发数据的粒度和方式不同~
四、 如何选择几层负载
答案很简单：七层负载能做的四层负载都可以做到，但是
1 四层负载均衡通常是在操作系统内核层协议栈中实现,应用层是办不到的；
2 四层负载均衡的设备或机器通常需要俩网卡, 一般租用的主机都只有一个网卡，如果你的应用只支持在四层做负载均衡，那么就要求所有部署你应用的客户都要有双网卡的专门设备或主机来做负载，除非有自有机房的大企业，个人一般都是租用阿里云等，（阿里云好像自己也带负载均衡）没有条件自己做负载~
3 有时为了架构上的分层（比如现在流行的微服务），即使使用了四层负载均衡，在应用层也会实现七层数据转发~例如IM软件架构中，连接器通常和业务服务器分离，连接器实现七层转发来转发应用层协议报文~
五、 负载均衡的通性分析以及MQ存在的意义（纯属个人推理类比和分析o(╯□╰)o）
1 不管四层还是七层负载均衡都需要依赖一个中心节点做为负载分发节点,比如四层负载均衡的分发节点是运行LVS软件设备,七层负载均衡的分发节点可以是Nginx、Apache HTTP服务器
2 上面说到，由于应用层协议的多样性，七层负载均衡通常需要区分协议单独开发，那么有没有好的通用性的七层负载均衡解决方案呢？MQ就可以胜任！客户端按照MQ提供的标准协议格式封装应用层数据包交给MQ中心节点服务器，MQ作为数据包存储和分发节点，分发给订阅了相关Queue或者Topic的后端负载节点，不仅达到了负载均衡，灵活性、数据安全性、稳定性都得到了提升~