李大牛开始创业。由于前期流量不大，所以他只部署了一台tomcat服务器，让客户端直接向这台服务器发送请求。
这种部署一开始是没有问题的，因为业务量不是很大，单机就可以应付了。但后来李大牛的业务冲击了主流，业务发展很快，所以单机的性能逐渐遇到了瓶颈，而且因为只部署了一台机器，如果这台机器出现故障，业务就会降为零。这是不可接受的。因此，为了避免单机的性能瓶颈，解决单点故障的隐患，李大牛决定多部署几台机器（假设是三台），这样让客户端随机调用其中一台机，这样即使其中一台机器挂了，其他机器还活着。就让客户端调用其他没有宕机的机器就可以了。
现在的问题是，客户端应该调用这三台机器中的哪一台？让客户端选择肯定是不合适的，因为如果允许客户端选择特定的服务器，那么它必须知道有哪些服务器，然后再使用轮询等方法随机连接到其中一台机器。然而，如果其中一台服务器宕机，客户端无法提前检测到。那么很有可能客户端会连接挂掉的服务器，那么选择哪一个呢？最好把连接机器的工作放在服务器上。具体怎么做呢？架构设计中有一个经典共识：没有什么是加一层解决不了的。如果有，则添加一层，所以我们在服务器端再添加一层，命名为LB（Load Balance）。 LB统一接收客户端的请求，然后决定与哪台服务器进行通信。业界普遍使用Nginx作为LB。
采用这样的架构设计最终支撑了业务的快速增长，但很快李大牛就发现这个架构存在一个问题：所有流量都可以发送到服务器。这显然是有问题的，而且不太安全。可以在交通中使用吗？在访问服务器之前，我们需要进行另一层身份验证。认证通过后，我们就让它到达服务器。我们称这一层为网关（为了避免单点故障，网关也必须以集群的形式存在）
这个设计持续了很长一段时间，但后来李大牛发现这个设计仍然存在问题。无论是动态请求还是静态资源（如js、css文件）请求，都会打到tomcat，流量大的时候就会出现问题。这导致tomcat压力很大。事实上，tomcat在处理静态资源方面不如Nginx。 Tomcat每次都要从磁盘加载文件，影响性能。 Nginx具有代理缓存等功能，可以大大提高静态资源的处理能力。
画外音：所谓代理缓存是指nginx从静态资源服务器获取资源后，会缓存在本地内存+磁盘中。如果下一个请求命中缓存，会直接从Nginx本地Cache返回。
因此，李大牛做了如下优化：如果是动态请求，则通过网关发送给tomcat；如果是Nginx，则发送到静态资源服务器。
这就是我们所说的动静分离，将静态请求和动态请求分开，这样tomcat就可以专注于处理自己擅长的动态请求，而静态资源则利用了Nginx的代理缓存等功能，而后面末端处理能力有所增强。一步。
另外，需要注意的是，并不是所有的动态请求都需要经过网关。例如，由于我们的运营中心后端是内部员工使用的，它的认证与网关的API认证不同，所以我们直接部署了两台运营中心的服务器，直接让Nginx将运营中心的请求发送到这两台服务器，绕过网关。
当然，为了避免单点故障，Nginx也需要部署至少两台机器，所以我们的架构就变成了如下。 Nginx部署两台机器，以主备的形式存在。备用Nginx会利用keepalived机制（发送心跳包）来及时感知主Nginx的存活情况，发现宕机了，他就承担起主Nginx的角色。
因此，Nginx的负载能力受到机器I/O、CPU内存等一系列配置的限制。一旦连接数很多（比如达到百万），Nginx的负载阻力就会急剧下降。
那么第4 层负载均衡器是如何工作的呢？
综上所述，我们给Nginx加了一层LVS，让它处理我们所有的流量。当然，为了保证LVS的可用性，我们也采用主备方式部署LVS。另外，如果Nginx采用这种架构的话，如果容量不够的话，我们可以很方便地进行水平扩展，所以我们的架构改进如下：
当然，如果只有一个LVS，就无法处理大流量。我应该怎么办？再添加几个。使用DNS 负载平衡。 DNS服务器解析域名时，可以随机命中其中一个LVS。
这样，交通终于可以稳定畅通了。有一点可能有些朋友会有疑问。我们来看一下。
既然LVS可以部署在多台服务器上，避免单点故障，Nginx也可以做到，而且Nginx在1.9之后也开始支持四层负载均衡，这样看来LVS就没有必要了？
如果不使用LVS，架构图是这样的
在流量没那么大的情况下部署多个Nginx确实是可行的，但是LVS是Linux的一个内核模块，工作在内核态，而Nginx工作在用户态，相对比较重，所以从性能和稳定性上来说Nginx是不如LVS，这也是我们采用LVS+Nginx部署方式的原因。
另外，相信大家都注意到了，如果流量大的话，静态资源应该部署在CDN上。 CDN会自动选择离用户最近的节点返回给用户，所以我们最终的架构改进如下
总结
架构必须根据业务的实际情况进行设计。不谈业务就谈建筑，其实是流氓。可以看到上面每一个架构的演进都和我们的业务发展息息相关。对于没有这么大流量的中小型公司来说，其实使用Nginx作为负载均衡器就足够了。流量快速增长后，可以考虑使用lvs+nginx。 Gbps的流量，几千万的并发连接），lvs已经不行了（虽然在实际测试中，虽然用了lvs，但是还是出现了大量的丢包），所以他们开发了自己的一套四层负载均衡器MGW
好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/7608.html
用户评论
负载均衡一直是让人头疼的事情，尤其是遇到复杂的网络架构的时候。
有14位网友表示赞同！
这篇文章应该能解释清楚负载均衡到底是什么意思和怎么做比较好.
有9位网友表示赞同！
我最近在学习云计算，这个东西好像很有用啊。
有13位网友表示赞同！
看来要搞清楚负载均衡技术，还得花时间去研究一下。
有5位网友表示赞同！
想问问高手们，实际操作中有哪些比较靠谱的负载均衡方案？
有14位网友表示赞同！
如果没了解过，就容易被各种宣传迷惑了，这篇文章应该能把真实情况讲清楚。
有5位网友表示赞同！
以前听别人提起负载均衡的时候总是一头雾水，现在正好看下这篇文章。
有16位网友表示赞同！
学习新技术确实辛苦，希望能通过这篇文好好理解一下。
有6位网友表示赞同！
相信很多开发朋友都会遇到这个问题，希望这篇文章能帮到大家!
有9位网友表示赞同！
感觉负载均衡的技术越来越重要了，未来肯定要成为必须掌握的技能之一。
有7位网友表示赞同！
这标题看起来有点火爆，但确实引发了我对这方面的思考，想了解一下实际应用场景。
有19位网友表示赞同！
我以前以为负载均衡就是简单的分流任务就好了，没想到原理会这么复杂呢。
有12位网友表示赞同！
如果能详细解读不同的负载均衡算法，那将更加实用!
有10位网友表示赞同！
除了技术原理，我还想知道一些常见问题的解决方法，期待作者能分享更多经验。
有16位网友表示赞同！
这篇文章能否提供一些案例分析，让我们更直观地理解负载均衡的意义？
有9位网友表示赞同！
学习计算机网络基础知识对了解负载均衡很关键，所以也要多阅读相关资料!
有17位网友表示赞同！
希望这篇文章能解释清楚各种流行的负载均衡方案，帮助我做进一步的选择!
有13位网友表示赞同！