再谈负载均衡

上周发的一篇负载均衡的文章有一个点不少人（统计了下在其他平台及上篇文章留言中大概有 8 人留言不解）有疑问，所以我觉得有必要单独写篇文章解释一下，先看下上篇文章展示的架构图

这里一些朋友的疑问点是 Nginx 是否多此一举，能否能直接从 LVS 打到站点层？即改成下面的架构

答案是不行，为什么？其实我在上文中有提到一些点已经暗示了，只不过不那么明显而已，我再单独把这些点拎出来

LVS 是四层负载均衡器
Nginx 是七层负载均衡器，可以根据 url 来转发流量

首先我们需要明白为什么根据 url 转发请求这么重要，假设现在有「营销」，「运营中心」这两个集群，使用 Nginx 的话很简单，根据 url 来决定到底将请求转发到哪个集群即可

由于 LVS 不能根据 url 转发，那么请问 LVS 收到请求后该转给谁

那么 LVS 为什么不能根据 url 来转发呢，因为它是四层负载均衡器，什么是四层和七层，这里就要简单复习下 ISO 七层参考模型了

由此可知，七层对应着应用层，四层对应着传输层，如果从应用层发起一个请求会在「传输层」,「网络层」,「数据链路层」分别加上各自层的包头，比如现在 A 电脑要发一个「I'm Deepon」数据给 B 电脑，则在各层的转化流程如下图所示

但最终在互联网上要传输的包（数据链路层传输的包叫祯，统称为包）是有大小限制的，如下图所示

在互联网上传输的包不能超过 14 + 20 + 20 + 1460 + 4 = 1518 byte，其中包含的应用层（即 payload）数据一次性不能超过 1460 个 byte,也就是说如果一个 HTTP 请求有 2000 byte，那么它必须分成两个包发送才能在网络上传输，再来看看 HTTP 的格式

如果一个 HTTP POST 请求很大，超过了 1460 byte（一个包 payload 的最大值），那么它必须分成两个包才能传输，也就意味着一个包可能包含 URI，另一个包不包含 URI，既然包都不包含 URI，那么请问 LVS 如何根据 URL 来转发给相应的集群呢，所以理解了 TCP/IP 的工作机制相信你不难理解开头的问题：LVS 是四层负载均衡器，无法根据 URL 来转发请求。

其实最关键的原因是四层以下其实只负责包的转发，只要拿出包头查看一下 ip 地址就可知道该转发哪里，很高效，如果你还要根据 url 来匹配那么需要拿到应用层数据根据正则等做匹配，显然会消耗更多的性能，所以专业的人做专业的事，应该由 LVS 来负责承载所有流量，Nginx 负责根据 url 来转发给对应的集群，因为它是七层负载均衡器，与上下游各建立了一个 TCP 链接

所以如果有多个分包，由于 Nginx 与 client 建立了 TCP 连接，可以在 Nginx 先拿到 client 发出的所有的分包再组装成完整的报文，然后根据 url 选择其中一台 server 与之建立 TCP 连接后将数据分批完整地传给上游 server

另外需要注意的是现在在大厂中如果只将 Nginx 作为转发之用是不够的，一般用的 OpenResty ，什么是 OpenResty 呢

“OpenResty? 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。
OpenResty? 的目标是让你的 Web 服务直接跑在 Nginx 服务内部，充分利用 Nginx 的非阻塞 I/O 模型，不仅仅对 HTTP 客户端请求,甚至于对远程后端诸如 MySQL、PostgreSQL、Memcached 以及 Redis 等都进行一致的高性能响应。”

注意上面一句「提供了与 MySQL ，Redis 等的交互能力」这一点非常关键，我们之前不是说 Nginx 可以根据 url 来决定打向哪个集群吗，假设现在有一个这样的场景：所有包含 operation 的请求都转发到运营中心的集群，则需要写死类似如下的配置

upstream?backend?{
??server?192.168.1.10:8080
??server?192.168.1.11:8080
}

server?{
??location?/operation?{
????proxy_pass?http://backed
??}
}

在我们集团中类似这样的规则非常多，难道要像上面这样把所有的规则都一个个写死在 Nginx 的配置文件里吗？显然不可行，更合理的方式是把这些规则（哪个 url 对应哪些集群）保存在 MySQL 中，然后 Nginx 在启动的时候将这些规则从 MySQL 中取出并保存在 Redis 及本地缓存中，然后 Nginx 要根据 url 匹配的时候从本地缓存（如果没有从 redis 拿，redis 过期从 MySQL 拿）里拿这些规则再根据匹配项转发到相应的集群，Nginx 没有这样的能力，而 OpenResty 由于集成了 Lua，引入了与 MySQL， Redis 等交互的模块，所以用它是可行的，所以最终架构如下（将 Nginx 换成 OpenResty）

关于使用 OpenResty 作为接入层/网关的具体实践，我们之前写了一篇文章，有兴趣的可以看看^_^