据统计，全球每三个网站里面就有一个使用Nginx服务器，在国内更是排行第一的服务器，阿里、腾讯、头条、拼多多等一线大厂都有广泛使用Nginx。
工作1年以上的同学基本也都知道这个软件，如果不知道这个软件的同学可以不用看下去了，哈哈。
步入主题：
互联网公司基本架构都是如下图所示 (排除其他硬件负载均衡、流量清洗等组件)
整个链路基本都要考虑高可用，避免单点故障，先不说如何架构整个系统，
流量入口是Nginx, 再到业务网关或者公共网关，再到业务服务器，最后到数据库。
广告：关于Nginx的核心点有太多太多了，有专题视频教程，有需要可以看我录制的专题课程。会员可观看全部课程，包括以后新录制的课程都能看，超值的哈，官网xdclass.net
这边剖析几个实际工作中遇到的问题和团队小伙伴在生产环境犯的错误（其他公司里面的P0和P1事故）
先说几个场景：
场景一：由于你的重启部署，测试人员正在测试一个复杂项目，突然服务不可用；再或者应用上线，生产环境启动不成功或者启动耗时久，导致线上接口成功率下降严重。
场景二: 为了解决上述的问题，前端或者后端进行了应用接口探测和请求重试，由于部分接口是新人开发没做好接口幂等性处理，导致业务数据故障。
在敏捷开发和持续交付盛行的时代，作为开发人员，在项目开发尾声或者进入提测阶段的时候，会把项目部署到测试环境，然后由测试人员进行测试。
稍微有点规模的公司都是有多套环境，用于应对不同场景，比如阿里、腾讯等这些大厂，应用开发上线的流程基本都 开发人员在开发环境验证好后，项目部署到测试环境发提测邮件，测试人员在测试环境测试，没问题后进入预发布环境，最后到上线到灰度或者生产环境。
看起来是不是很nice没问题？如果项目周期短，那开发和测试人员肯定会接触特别频繁，谁写的代码敢保证一定没有bug呢？
所以在提测阶段，测试人员发现了bug，反馈给开发人员进行修复，修复后又部署到测试环境；
由于开发人员的重新部署项目到测试环境，测试人员在测试一个重大功能或者复杂流程的时候，突然接口出现不可访问或者5XX错误，出现一两次可以忍受，但是频繁出现，测试人员就会提着40米的大刀来找开发人员，这个肯定是影响项目进度的。
且多数公司包括大厂，在测试环境的服务器配置比较差，且一个项目也不会分配太多服务器资源，所以部署启动又很耗时，复杂项目启动花个几分钟到十多分钟都是存在的，特别是项目周期短且急的情况下。
那怎么解决这个问题呢？
测试环境由测试人员进行部署，但往往应用部署需要有依赖上下文，比如数据库更新，配置文件更新，RPC接口更新，这些交给测试人员进行的话多少会有点难度，所以一般还是开发人员部署。
采用无感知部署和业务重试，这个思想也类似应用优雅上下线，总体流程是这样的:
一个请求到后端服务器，如果接口不可用或者出现特定的错误，比如5XX等，就把请求转发到另外一个应用节点，直到请求成功（也可以设置一定的转发次数）
那上述这个就可以解决由于重启应用导致接口不可用的问题，做到了无感知部署，但是也并非全部都是无感知的，先继续往下看。
那应该怎么做呢，有没啥开源的中间件可以解决我这个问题呢？
Nginx就可以解决你的这个问题，里面有个负载均衡模块upstream，里面最少配置两个后端应用节点
光这样就可以了吗？其实不是的，Nginx怎么知道你说的请求不可用是什么意思呢，认定标准是什么？
比如接口超时、服务不可用、Http状态码404、5XX错误等等，这些都是有问题的请求，肯定是可以指定的，所以你还需要配置下面这个指令 proxy_next_upstream
可定制化才是最厉害的，如果业务认为http状态码404不需要转发，那把这个http_404去除即可。
所以使用了上述配置，如果你重启了某个节点，那测试人员是不是可以依旧正常进行测试了，假如请求分发到你重启的那个应用，请求失败后依旧会被转发到其他节点。
对应生成环境也是，如果某个服务器接口挂了，配置了重试策略，这个就可以做到自动转发请求，接口容灾，除非全部节点都不可用。
一切都是那么如意，采用了上述的配置后，接口成功率也提高了，加入原先的时候是95%, 现在变成98%了。
但是，看问题别想的那么简单，业务故障的坑就来了。
接口重试一定要和业务互相配合，包括远程RPC调用，只要是涉及到数据的新增、修改、删除操作，你是否有考虑幂等性呢？尽管你有考虑，但是你能保证团队里面每个人都一直有重视这个问题不？
虽然有些同学会说 公司会做CodeReview代码审查，但谁能保证每次都可以全部审查完，包括很大厂也是没把这个工作落实好。
故障例子：好比你做了一个话费充值项目或者发送验证码的接口，一般会涉及到第三方接口调用，是很容易报错或者超时的。
由于没做接口幂等性处理，接口重试会造成业务数据重复增加，比如老王充值了50元，由于接口没做幂等性处理，被转发了好几遍，那最终这个就是公司的资损了，如果再经过“羊毛党”规模化，造成的损失就大了。
尽管前端、后端代码 是没做请求重试，但是Nginx那么做了转发重试，最终酿成了业务故障。
所以Nginx这边的重试配置，上述默认只会对GET请求进行重试，其他的POST、PATCH等对数据有修改的请求是不进行重试的。
有兴趣的可以看下官方文档：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream
所以凡事有利也有弊，一定要细心
如果你想提高接口成功率，一定需要Nginx帮你做重试，那你需要做好接口幂等性处理, 然后在Nginx那边增加这个指令参数 non_idempotent
- - - - - -
后面我会经常分享技术文章，有内推资源也会不定期发布
职业规划或者其他技术问题也可以互相探讨，平时白天工作比较忙，有时间基本都会回复的，晚上时间相对充裕点，也欢迎你在下方留言和我交流。
或加入我的极客社群——
知识星球「小D极客圈」
一个好的架构师或者技术负责人，需要日积月累，不是靠简单培训看视频就可以学会的，业务方案+系统架构也是不断更新。
架构域包括：业务架构、数据架构、产品架构、应用架构、技术架构等。
分享内容：工作业务问题解决方案，底层或者前言技术分享，案例练习题，原创技术文章；设计原理思想、业务解决方案。
不保证百分百问题都有完美解决方案，但是肯定物所超值
如果你喜欢，请给我一个三连吧，下篇文章见！
