腾讯的负载均衡和自己搭建的有什么不同

腾讯云负载均衡点击即用，但是传统的负载均衡需要搭建，下面我们一起来了解一下传统的负载均衡吧

这个问题其实很难，涉及到 HTTP，TCP，网关，LVS 等一系列相关的概念及工作机制，如果你能掌握到这其中的每个知识点，那将极大地点亮你的技能树,你对于网络是如何运作也会了然于胸，即便不能完全掌握，但知道流量怎么流转的对你排查定位问题会大有帮助，我之前就利用这些知识定位到不少问题，为了弄清楚整个流程，我查阅了很多资料也请教了不少人，相信应该可以把这个问题讲明白，不过写着写着发现篇幅实在太长，所以分为上下两篇来分别介绍一下，本篇先介绍流量在后端的的整体架构图，下一篇会深入剖析细节点，如 LVS 的工作细节，这其中会涉及到交换机，路由器的工作机制等

李大牛创业了，由于前期没啥流量，所以他只部署了一台 tomcat server，让客户端将请求直接打到这台 server 上

这样部署一开始也没啥问题，因为业务量不是很大，单机足以扛住，但后来李大牛的业务踩中了风口，业务迅猛发展，于是单机的性能逐渐遇到了瓶颈，而且由于只部署了一台机器，这台机器挂掉了业务也就跌零了，这可不行，所以为了避免单机性能瓶颈与解决单点故障的隐患，李大牛决定多部署几台机器（假设为三台），这样可以让 client 随机打向其中的一台机器，这样就算其中一台机器挂了，另外的机器还存活，让 client 打向其它没有宕机的机器即可

现在问题来了，client 到底该打向这三台机器的哪一台呢，如果让 client 来选择肯定不合适，因为如果让 client 来选择具体的 server，那么它必须知道有哪几台 server，然后再用轮询等方式随机连接其中一台机器，但如果其中某台 server 宕机了，client 是无法提前感知到的，那么很可能 client 会连接到这台挂掉的 server 上，所以选择哪台机器来连接的工作最好放在 server 中，具体怎么做呢，在架构设计中有个经典的共识：没有什么是加一层解决不了的，如果有那就再加一层，所以我们在 server 端再加一层，将其命名为 LB（Load Balance，负载均衡），由 LB 统一接收 client 的请求，然后再由它来决定具体与哪一个 server 通信，一般业界普遍使用 Nginx 作为 LB

采用这样的架构设计总算支撑了业务的快速增长，但随后不久李大牛发现这样的架构有点问题：所有的流量都能打到 server 上，这显然是有问题的，不太安全，那能不能在流量打到 server 前再做一层鉴权操作呢，鉴权通过了我们才让它打到 server 上，我们把这一层叫做网关（为了避免单点故障，网关也要以集群的形式存在）

作者：码海 链接：https://www.zhihu.com/question/61783920/answer/2023377962 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

这样的话所有的流量在打到 server 前都要经过网关这一层，鉴权通过后才把流量转发到 server 中，否则就向 client 返回报错信息，除了鉴权外，网关还起到风控（防止羊毛党），协议转换（比如将 HTTP 转换成 Dubbo），流量控制等功能，以最大程度地保证转发给 server 的流量是安全的，可控的。

这样的设计持续了很长一段时间，但是后来李大牛发现这样的设计其实还是有问题，不管是动态请求，还是静态资源（如 js，css文件）请求都打到 tomcat 了，这样在流量大时会造成 tomcat 承受极大的压力，其实对于静态资源的处理 tomcat 不如 Nginx，tomcat 每次都要从磁盘加载文件比较影响性能，而 Nginx 有 proxy cache 等功能可以极大提升对静态资源的处理能力。

画外音：所谓的 proxy cache 是指 nginx 从静态资源服务器上获取资源后会缓存在本地的内存+磁盘中，下次请求如果命中缓存就从 Nginx 本机的 Cache 中直接返回了

所以李大牛又作了如下优化：如果是动态请求，则经过 gateway 打到 tomcat，如果是静态请求，则打到静态资源服务器上

这就是我们所说的动静分离，将静态请求与动态请求分开，这样 tomcat 就可以专注于处理其擅长的动态请求，而静态资源由于利用到了 Nginx 的 proxy cache 等功能，后端的处理能力又上了一个台阶。