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

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

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

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

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

场景 1：

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

场景 2：

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

场景 3：

server：王xx同学拼搏奋斗，是公司的楷模。 proxy：开启狼性文化，明起996 client: 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 服务器，中间的缓存层就