Nginx非常好用，几乎每家公司都在用。它的功能主要有反向代理、负载均衡、动静分离等，其中最重要的是反向代理。图片来自Pexels，其主要架构图如下：客户端无法直接访问后端服务器，因为服务器资源高在上面，客户端没有权限。这时候就需要一个Proxy来充当代理，转发client的请求，然后将结果返回给Client。为什么Client不能直接访问Server？这就涉及到资源隔离。服务器的一些真实意图是客户端不知道的，比如一些受安全保护的敏感资源。也就是说，通过Proxy，Server想让Client看到的东西，Client只能看到。对于Client，函数总是被阉割的！甚至被篡改！我们替换图中的元素，奇妙的事情发生了。我们把Client换成了一个可怜的普通码农，把Server换成了牛X的教主，呼啸的山风中可以看到6个绿色的箭头毫不留情的指向Proxy。代理成为关键资源。这个代理要求不简单，需要五缺三缺。有这么牛X的存在，不愧是Nginx工程师。一个Nginx工程师不需要有自己的想法，但一定要记住领导的每一句话，明白领导的真实意图。传达领导思想时，也知道轻重和过滤，能快速准确地传达领导思想。不服，真不是一般人能办到的。谁可以成为Nginx工程师？在奴隶社会，无论一个奴隶（Slave）多么努力，能力多么出众，也永远不会成功。相反，那些带鞭子的监工更容易得到主子们的赏识，喝酒吃肉都能想到他们。更神奇的是，如果把监工和奴隶的工作颠倒过来。奴仆可以做监督的工作，监督不可能做奴隶的工作。为什么是这样？总结一下，有几点：主管知道更多的内幕资源，更容易给老板投票。主管的工作属性是管理，有很大的回旋余地。监工离权力中心越近，耳边吹来的风的频率就越高。你可能会说这是社会的本性，现在的社会肯定没有这个问题。你答对了一半，这就是问题所在。由于每个公司的进化程度不同，程序员在不同公司得到的感受和待遇也是非常大的。你甚至可能有照片中爸爸的心态。主管一般不在一线，远离生产。他们只能了解客户的想法。这个一点点传给服务器，正确性比较难保证。而且主管在理解领导意图和总结Excel上花了大量精力，真正有意义的事情花的时间很少。那我们该怎么办呢？我们必须把客户的结果当作我们自己的。所以，代码写得呆板的程序员可能会发现，自己做了很多工作，经过Proxy的处理和传达，到了leader那里就是个屁。Proxy做了正确的事。996的Client也需要深夜调代码，Proxy只需要在一旁刷抖音即可。工作强度不同，工作时间自然没有比较价值。我们可以再看看Proxy的三种传输场景。场景一：服务端：需要加强员工文化建设。proxy：周六周末去团建，AAclient：WCNM场景2：server：公司要节俭。代理人：从明天开始不再提供卫生纸和开水。客户：WCNM场景三：服务端：王xx工作努力，是公司的榜样。Proxy：开启狼性文化。从996client:WCNM可以看出这一层代理的质量尤为重要。如果碰巧遇到并行代理，可想而知会有多惨。但如果你遇到了一个不错的代理人，请好好珍惜他，因为所有的压力都需要他来排泄。普通的Nginx工程师是怎么做的呢？为了让驴子拉磨，人们想出了四招：蒙眼、捂嘴、塞耳朵、鞭子。同样，如果你希望Proxy能够顺利实施，Proxy可以阻止你看到某些东西；当你想发表意见时，用暴力手段堵住你的嘴；耳朵;当你懈怠时，用鞭子督促你完成工作。很多公司由于员工人数多，结构复杂，所以有多层Proxy拓扑。这样的公司非常令人兴奋。一个代理可以作为另一个代理的客户端。在许多情况下，服务器的数量大于客户端的数量。我为这些Proxies感到难过，他们活得太累了。但是由于Proxy的工作特性，它只需要完成转发就可以完成工作，不需要思考——自然是一头乌黑油亮的头发。再加上Nginx工程师可以轻松打破35岁的魔咒，所以这个职业还是趋之若鹜。你也想成为一名Nginx工程师吗？如何保证Nginx的高可用？目前HTTP协议，甚至是WebSocket协议，甚至是使用MQTT协议的WebSocket协议都不可避免地要用到Nginx。所谓病从口入，祸从口出。作为一个入口，Nginx的职责是非常重要的。如果在某个时候它不起作用，那将是一场灾难。如何保证Nginx的高可用？这是个问题。不管你用什么样的plan，最后总是归为一个，很苦恼。所谓高可用无外乎两种方式：一种方式是对组件本身做文章。另一种方法是添加中间层。我们通常希望能够在高可用的同时进行负载均衡。典型的猫狗两样都想要，而且非常贪婪。每当我们解决不了问题的时候，我们就会加一个中间层，然后把希望寄托在这个新生的组件上。如果这个中间层还不能解决问题，我们可以再加一个中间层。这样一层层往下，最后系统的高可用架构就会变得非常复杂。保证DNS高可用的第一个方法当然是在DNS上做文章。可以通过在DNS上绑定多个NginxIP地址来实现高可用。不仅可以实现高可用，还可以顺便实现负载均衡。但是这东西有一个致命的问题，那就是感知失败的时间。我们的浏览器在访问真实的Nginx之前，需要将域名转换为真实的IP地址。DNS负责解析这个动作，每次需要20-20ms。为了加快解析速度，一般会有多级缓存。例如，浏览器有DNS缓存；您使用的PC也有这样的缓存；IPS服务提供商也有缓存；更多的。DNS只有在没有命中所有缓存的情况下才会查询真实的IP地址。所以如果有一个Nginx宕机了，这个故障的感知会特别差。总会有一些用户请求落在这台死机上。硬件保证了我们前面说的高可用。对于无法解决的问题，可以加一个中间层，即使这个中间层是硬件，比如F5。这种结构的企业是吃不起的。只有那些有返利和有利可图的采购的公司才会喜欢这样。网上很少用到，就不过多介绍了。当然F5也有单点问题。虽然硬件肯定比软件稳定一点，但始终是一个隐患。就像Oracle，再强大也是有问题的，备份是必须的。有的厂家卖硬件的时候，建议你一次买3个！为什么？这是有原因的。您的一个硬件正在使用中，并且您有两台备用机器。当你服务的机器出现问题时，你可以选择其中一台备机作为master，另一台仍然是备机，集群仍然是高可用的。原因令人陶醉。按照这个逻辑，我要是遇到傻子，我能卖100台！①主备模式不够硬，需要软。采用主备模式，通过软件完成切换过程。如图所示，使用Keepalived组件和VRRP协议即可完成最简单的高可用配置。我们将DNS地址绑定到VIP。当服务的Nginx出现问题时，VIP就会漂移，转移到另一个Nginx上。可见备份的Nginx在正常情况下无法提供服务。它也被称为影子节点，只有在主Nginx出现问题时才有用。如果你有很多节点，这种模式会有很多浪费。除了浪费，还有一个非常大的问题。也就是说，不管单个Nginx的性能有多好，总有一个上限。当网卡流量达到峰值后，接下来应该怎么办呢？这种模式肯定不符合需求。②简单组合模式这时候我们可以配合DNS解析，在主备模式上做文章。如下图，DNS解析到两个VIP，VIP本身也是高可用的。这样既可以缩短故障时间，又可以保证各个组件的高可用。这种架构模型思路很清晰，但是还是存在影子节点的浪费。③LVS+KeepAlived+NginxLVS是LinuxVirtualServer的缩写，即Linux虚拟服务器。现在LVS已经是Linux标准内核的一部分。从Linux2.4内核开始，已经完全内置了LVS的各种功能模块，可以直接使用LVS提供的各种功能，无需对内核打任何补丁。LVS工作在OSI模型的第四层：传输层，如TCP/UDP，所以无法识别七层网络的HTTP协议。也就是说，我们不能利用HTTP协议的某些内容来控制路由，它的路由切入级别较低。如下图所示，由LVS搭建的服务器集群系统由三部分组成：前端负载均衡层，以LoadBalancer为代表。中间的服务器集群层用ServerArray表示。最底层的数据共享存储层以SharedStorage为代表。DR（DirectRouting）模式可以将响应数据包直接返回给用户浏览器，避免负载均衡服务器的网卡带宽成为瓶颈。是目前使用最广泛的方法（数据不详，Fullnat模式也被广泛使用）。因此，通过DNS负载均衡和LVS负载均衡，可以实现二层负载均衡和高可用。如图所示，DNS可以将请求绑定到VIP上。因为LVSDR模式的效率非常高，网卡需要非常大量的请求才会达到瓶颈（只有入口流量可以走LVS），所以一般通过LVS做Nginx负载均衡就可以了。如果LVS还有瓶颈，那就可以在DNS上做文章了。有哪些挑战？事实上，我们上面提到的大部分解决方案都在同一个机房??。如果有多个机房，如何让用户选择最快的节点，如何保证负载均衡，又是一个大问题。另外可以看到数据包是层层转发协调的，涉及到各种负载均衡算法。如何维持会话也是一个挑战。一般四层会话会通过IP地址来实现，七层会话会通过cookie或header信息来实现。开发者一般接触不到这种入门级的东西，但一旦遇到，可能会手忙脚乱。这篇文章是基于我现有的经验。希望在贵公司需要一些高可用的解决方案时，能对您有所帮助。PS：什么是计划？你只需要哄你的领导，让他觉得他同意就可以了。至于做不做，怎么做，那是后话。君不见，说了半天，很多公司其实一个Nginx就可以跑遍天下。作者：品味小姐姐简介：专注于基础架构和Linux。十年架构，每天百亿流量，与你探讨高并发世界，给你不一样的滋味。编辑：陶佳龙来源：转载自公众号味觉小姐（ID：xjjdog）
