Nginx，为什么依旧这么“香”？

发布时间：2020-09-25 21:23:02来源：51CTO技术栈

“

Nginx很好用，几乎每个公司都在用，它的功能主要有反向代理、负载均衡、动静分离等，其中最主要的就是反向代理。

图片来自Pexels

它的主要架构图如下：

客户端是无法直接访问后端的Server的，因为Server资源高高在上，Client并没有权限。

这个时候，就需要有一个Proxy，进行代理，将客户端的请求进行转发，然后把结果返回给Client。

为什么不能直接让Client访问Server呢？这就涉及到资源隔离问题。Server的一些真实意图，是不想要Client知晓的，比如一些受安全保护的敏感资源。

也就是说，通过Proxy，Server想让Client看到啥，Client也只能看到啥。对Client来说，功能总是阉割的！甚至是篡改的！

我们将图中的元素替换一下，奇妙的事情发生了。

我们把Client换成可怜的普通码农，把Server换成牛X的领导，可以看到6条绿色的箭头，带着呼啸的山风，无情的指向了Proxy。

Proxy成为了关键的资源。这个Proxy要求可不简单，需要五弊三缺，上承天命，下召九幽。这么牛X的存在，当之无愧称之为Nginx工程师。

Nginx工程师不需要有自己的想法，但他必须记住领导的每一句话，领会领导的真实意图。

传导领导想法的时候，也知道轻重，知道过滤，能够快狠准的将领导的想法广播出去。不服不行，这还真不是一般人能做的。

哪些人能够成为Nginx工程师呢？在奴隶社会，无论一个奴隶（Slave）工作多么的卖力，能力多么的出众，都没有出头之日。

反而是那些拿着鞭子的监工们，更容易获得主人们的赞赏，喝酒吃肉的时候都能够想到他们。

更加奇妙的是，如果把监工们和奴隶们的工作调换一下。奴隶有可能会胜任监工的工作，而监工绝无可能胜任奴隶的工作。

这是为什么呢？总结下来可以有这么几点：

监工知道更多的内幕资源，更容易投主人所好。

监工的工作属性是管理，可操作空间大。

监工离权利中心更近，耳边风吹的频率要高一些。

你可能会说，这是社会性质使然，现在的社会肯定没这问题。你答对了一半，问题就出在这里。

由于每个公司的进化程度不一，程序员在不同的公司，获得的感受和受到的待遇，也是非常大的。你甚至会产生图中爸爸的心态。

监工一般都不是一线，离生产是比较远的，对于Client的想法，只能领会一点点。这一点点传导到Server那里的，正确性更难以保证。

而且，监工由于领会领导意图和汇总Excel，耗费了大量的精力，花在真正有意义的事上的时间，就少的可怜。那怎么办呢？只好拿Client的成果当作自己的成果。

所以，闷头写代码的程序员，可能会发现自己做了很多工作，经过Proxy的一加工一转达，到了领导那里就是个屁。

Proxy做的没错，996的Client深夜也需要调代码，Proxy只需要在一旁刷TikTok就可以了。工作强度不一样，工时自然就没有衡量对比的价值。

我们可以再看Proxy的3种传导场景。

场景1：

server：要加强员工文化建设。proxy：周六、周末去团建，AAclient:WCNM

场景2：

server：公司要勤俭节约。proxy：从明天开始不提供厕纸和开水client:WCNM

场景3：

server：王xx同学拼搏奋斗，是公司的楷模。proxy：开启狼性文化，明起996client:WCNM

可以看到，这一层的Proxy素质尤其重要。如果你不巧碰见了一个水货Proxy，你的悲惨程度可想而知。

但如果你遇到一个Nice的Proxy，那就珍惜他，因为所有的压力，都需要由他传导。

那一般的Nginx工程师是怎么做的呢？为了让驴拉磨，人们想出四招：蒙眼睛、捂嘴巴、堵耳朵、抽鞭子。

同样，要想Proxy顺利推行，Proxy就可以不让你看到某些事情；你想要发表意见的时候，使用暴力手段堵住你的嘴；当你想要聆听领导真实意图，堵住你的耳朵；当你有所懈怠的时候，使用鞭子督促你完成工作。

很多公司由于人员众多，结构复杂，就存在着多层Proxy的拓扑。这种公司非常的精彩，一个Proxy，可以作为另一个Proxy的Client，很多时候，竟然会发生Server的数量比Client的数量多的情况。

我很可怜这些Proxy们，他们活的太累了。但由于Proxy的工作特性，只需要进行完整的转发即可完成工作，不需要思考--自然有一头乌黑油亮的秀发。

加上Nginx工程师可以很容易打破35岁魔咒，所以这个职业依然让人趋之若鹜。你也想做一枚Nginx工程师么？

如何保证Nginx的高可用？

目前HTTP协议，乃至WebSocket协议，乃至采用了MQTT协议的WebSocket协议，都不可避免的使用了Nginx。

所谓病从口入，祸从口出。作为入口，Nginx承担的责任非常的重要。假如某个时刻不能用了，那可真是灾难。

如何保证Nginx的高可用呢？这是个问题。不论你用什么样的方案，到最后总是要归为单一，很让人苦恼。

所谓的高可用，无非两种方式：

一种方式就是在组件自身上做文章。

另外一种方式，就是加入一个中间层。

我们通常希望在高可用的时候，同时还能够负载均衡，典型的猫和狗都想要，贪婪的很。

每当解决不了问题的时候，我们都会加入一个中间层，然后把希望寄托在这个新生的组件上。

如果这个中间层解决不了问题，我们就可以加入另外一个中间层。就这样一层套一层，到最后系统高可用架构就会变得非常复杂。

DNS保证高可用

第一种方式当然是要在DNS上做文章了。通过在DNS上，绑定多个Nginx的IP地址，即可完成高可用。不仅能够完成高可用，还能顺便完成负载均衡。

但这玩意有一个致命的问题，那就是故障的感知时间。

我们的浏览器在访问到真正的Nginx之前，需要把域名转化为真正的IP地址，DNS就是干解析这个动作的，每次需要耗费20-20ms不等。

为了加快解析速度，一般都会有多级的缓存。比如浏览器就有DNS的缓存；你使用的PC机上也有这样的缓存；IPS服务提供商，也会有缓存；再加上有的企业为了加速访问所自建的DNS服务器，中间的缓存层就更多了。

只有所有的缓存都不命中的情况下，DNS才会查询真正的IP地址。所以，如果有一台Nginx宕机了，这个故障的感知能力就会特别的差。总有一部分用户的请求，会落在这台已经死亡的机器上。

硬件保证高可用

我们前面说了。解决不了的问题，就可以加中间层，即使这个中间层是硬件，比如F5。

这种架构一般的企业玩不起，只有那些采购有回扣有油水的公司，才会喜欢这个。互联网中用的很少，就不过多介绍了。

当然，F5同样有单点的问题。虽然硬件肯定要比软件稳定上一点，但是总归是一个隐患。

就像Oracle无论再厉害，它还是有出问题的时候，到时候备机是必须的。有的厂商在卖硬件的时候，推荐你一次买3个！为啥呢？这也有理由。

你的一台硬件正在服务，有两台备份机器。当你服务的这台机器出现问题时，就可以选取备份机中的其中一台作为主机，另一台依然是备机，集群还是高可用的。

这理由真让人陶醉。按照这个逻辑，碰到傻子，我可以卖出100台！

硬的不行，就要来软的。采用主备的模式，使用软件来完成切换过程。

如图，使用Keepalived组件，通过VRRP协议，即可完成最简单的高可用配置。

我们把DNS的地址绑定在VIP上，当正在服务的Nginx发生问题，VIP会发生漂移，转移到另外一台Nginx上。

可以看到，备份的Nginx，正常情况下是无法进行服务的，它也叫做影子节点，只有主Nginx发生问题的时候才有用。如果你的节点非常多，这种模式下，会有非常大的浪费。

除了浪费，还有一个非常大的问题。那就是，单台Nginx无论性能多么牛X，总是有上限的。当网卡的流量达到顶峰，接下来何去何从呢？

这种模式肯定是不满足需求的。

这个时候，我们就可以配合DNS解析，以及主备模式做文章了。如下图，DNS解析到两个VIP上，VIP本身也做了高可用。

这样就能够缩短故障时间，同时也能够保证每个组件的高可用。

这种架构模式思路是非常清晰的，但依然存在影子节点的浪费。

LVS是LinuxVirtualServer的简称，也就是Linux虚拟服务器。

现在LVS已经是Linux标准内核的一部分，从Linux2.4内核以后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。

LVS工作在OSI模型的第四层：传输层，比如TCP/UDP，所以像七层网络的HTTP协议，它是识别不出来的。

也就是说，我们不能拿HTTP协议的一些内容来控制路由，它的路由切入层次更低一些。

如下图，LVS架设的服务器集群系统有三个部分组成：

最前端的负载均衡层，用LoadBalancer表示。

中间的服务器集群层，用ServerArray表示。

最底端的数据共享存储层，用SharedStorage表示。

DR（直接路由）模式可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈，是目前采用最为广泛的方式（数据不详，Fullnat模式使用也比较广泛）。

所以，配合DNS的负载均衡，加上LVS的负载均衡，可以实现双层的负载均衡和高可用。

如图，DNS可以将请求绑定在VIP上。由于LVSDR模式的效率非常高，网卡要达到瓶颈也需要非常大的请求量（只有入口流量才走LVS），所以一般通过LVS做Nginx的负载均衡就足够了。

如果LVS还有瓶颈，那么就可以在DNS上再做文章。

另外，你可以看到数据包经过层层的转发和协调，还有多种负载均衡算法参与其中，如何保持会话，也是一个挑战。

一般的，四层会话会通过IP地址去实现，七层会话会通过Cookie或者头信息等去实现。

开发人员一般情况下接触不到这么入口级的东西，但一旦遇到了，可能会受忙脚乱。

本文是我根据一些即有的经验进行整理，希望你在公司需要一些高可用方案的时候，能够助你一臂之力。

PS：什么叫方案？你只需要当时把你的领导哄好，让他感觉很认同的样子就行了。至于要不要做，具体怎么做，那都是后面的事。

君不见，扯了这么半天，很多企业其实一个Nginx，就可以走天下。

作者：小姐姐味道

简介：聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。

编辑：陶家龙

出处：转载自公众号小姐姐味道（ID：xjjdog）

精彩文章推荐：