upstream

问题背景 　　我们这边是一个基于Nginx的API网关（以下标记为A），最近两天有调用方反馈，偶尔会出现502错误，我们从Nginx的error日志里看，就会发现有" upstream prematurely closed connection while reading response header from upstream"这么一条错误日志，翻译过来其实就是上游服务过早的关闭了连接，意思很清楚，但是为什么会出现这种情况呢。而且是在业务低峰出现这种情况（也只是小概率的出现），在业务高峰的时候没有出现这种情况，而且上游服务方（以下标记为B）说出问题的请求他们那边没有收到，也就是没有任何记录，这就比较诡异了。测试环境不知道如何去复现，也就不好排查。 排查过程 　　1、在服务器上开启tcpdump抓包 tcpdump -nps0 -iany -w /tmp/20180617.pcap net [ip] and net [ip]，如果不知道tcpdump怎么使用的同学可以百度一下。 　　2、在nginx的error.log中观察到到有两条" upstream prematurely closed connection while reading response header from upstream"错误日志，分别是2018/06/07 20:41:27和2018/06/08

序言 Nginx的代理功能与负载均衡功能是最常被用到的，关于nginx的基本语法常识与配置已在上篇文章中有说明，这篇就开门见山，先描述一些关于代理功能的配置，再说明负载均衡详细。 Nginx代理服务的配置说明 1、上一篇中我们在http模块中有下面的配置，当代理遇到状态码为404时，我们把404页面导向百度。 error_page 404 https://www.baidu.com; #错误页 然而这个配置，细心的朋友可以发现他并没有起作用。 如果我们想让他起作用，我们必须配合着下面的配置一起使用 proxy_intercept_errors on; #如果被代理服务器返回的状态码为400或者大于400，设置的error_page配置起作用。默认为off。 2、如果我们的代理只允许接受get，post请求方法的一种 proxy_method get; #支持客户端的请求方法。post/get； 3、设置支持的http协议版本 proxy_http_version 1.0 ; #Nginx服务器提供代理服务的http协议版本1.0，1.1，默认设置为1.0版本 4、如果你的nginx服务器给2台web服务器做代理，负载均衡算法采用轮询，那么当你的一台机器web程序iis关闭，也就是说web不能访问，那么nginx服务器分发请求还是会给这台不能访问的web服务器

1.nginx负载均衡 　　网站的访问量越来越大，服务器的服务模式也得进行相应的升级，比如分离出数据库服务器、分离出图片作为单独服务，这些是简单的数据的负载均衡，将压力分散到不同的机器上。有时候来自web前端的压力，也能让人十分头痛。怎样将同一个域名的访问分散到两台或更多的机器上呢？这其实就是另一种负载均衡了，nginx自身就可以做到，只需要做个简单的配置就行。 　　nginx不单可以作为强大的web服务器，也可以作为一个反向代理服务器，而且nginx还可以按照调度规则实现动态、静态页面的分离，可以按照轮询、ip哈希、URL哈希、权重等多种方式对后端服务器做负载均衡，同时还支持后端服务器的健康检查。 Nginx负载均衡一些基础知识： nginx 的 upstream目前支持 4 种方式的分配 1)、轮询（默认） 　　每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 2)、weight 　　指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 2)、ip_hash 　　每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。 3)、fair（第三方） 　　按后端服务器的响应时间来分配请求，响应时间短的优先分配。 4)、url_hash（第三方） 2.nginx负载均衡配置

一、背景 　　随着业务量和用户数量的激增，单一的tomcat部署应用已经无法满足性能需求，而且对于每次发布项目期间服务不可用的问题也凸显，既然出现了这个问题，那么我们本文就借助nginx来完美的解决这个问题。 二、基本概念 1.说明：关于Nginx的概念和介绍以及Centos7下安装步骤，请移步： Centos7安装Nginx实战 2.正向代理和反向代理 　假设我们给定客户端A、代理服务器B、以及最终服务器C 　正向代理：代理服务器B来代替客户端A来访问最终服务器C并将最终结果转发给客户端A，站在客户端A的角度上，代理服务器代理的是客户端A，这个过程是正向的，所以叫正向代理。（正向代理需要客户端A设置代理服务器的ip和提供代理服务的端口） 　反向代理：客户端A直接访问代理服务器B，由代理服务器B来决定将请求转发到哪个最终服务器进行真正处理，并将最终服务器的处理结果转发给客户端A，也就是代理服务器代理的是最终服务器C，站在客户端A的角度上，这个过程是反向的，所以叫反向代理。（反向代理不需要客户端A进行任何设置） 　关于正向代理和反向代理，这里有一篇不错的文章： 图解正向代理、反向代理、透明代理 3.负载均衡(Load Balance) 　 所谓负载均衡就是将一批可以提供相同服务的服务器组成一个服务器集合，每台服务器都可以单独向外部提供相同的服务，通过某种负载分担技术

######Nginx配置文件nginx.conf中文详解##### #定义Nginx运行的用户和用户组 user www www; #nginx进程数，建议设置为等于CPU总核心数。 worker_processes 8; #全局错误日志定义类型，[ debug | info | notice | warn | error | crit ] error_log /usr/local/nginx/logs/error.log info; #进程pid文件 pid /usr/local/nginx/logs/nginx.pid; #指定进程可以打开的最大描述符：数目 #工作模式与连接数上限 #这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。 #现在在linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。 #这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。 worker_rlimit_nofile 65535; events { #参考事件模型，use [

有一次偶然的配置，发现nginx 在配置upstream的时候， 如果名字带有下划线，会导致前端返回 400 错误。 百度之后其他人好像也遇到了这个问题： https://blog.csdn.net/horizon_zy/article/details/80139658 为什么会出现这种问题呢？ 我们项目有很多的upstream配置，有的也是有下滑线的，为什么他们没有报错，就我们这里报错了。 改完之后（upstream为没有下划线的） 是因为 升级了SpringBoot版本导致了该问题 ，又因为是http的头部变化导致的问题，故可以大胆猜测是因为升级了Tomcat版本导致的该问题。 为什么新版的tomcat为什么出现这个问题？ 在SpringBoot项目的issue中搜索了下400问题，发现确实有相关的issue。 https://github.com/spring-projects/spring-boot/issues/13236 虽然看上去跟我们的问题是一样的，都是400问题，但是具体发生的原因是不一样的。这个issue是说，如果domain name .ext 包含数字，比如 “domain.sf1m”，会出现400问题。这个问题也已经在tomcat的新版本中修复了。 带有下划线的Host的http请求，tomcat认为是有问题 那为什么之前版本的tomcat是正常的呢?

目录 通过konga连接kong实现API接口代理 1. ADD NEW SERVICE 2. ADD ROUTE 3. 验证API 代理 浏览器验证 请求kong api kong使用Admin API实现接口代理 通过konga连接kong实现API接口代理 前言 ： 之前已经对Kong的API做了学习理解，从本文开始，我们将学习如何使用KONG实现API接口代理。为此，您首先需要添加服务；即Kong用来指代其管理的上游API和微服务的名称。 本文中，我们将创建一个指向 Mockbin API的服务 进行学习测试。 1. ADD NEW SERVICE [SERVICE] : 抽象层面的服务，他可以直接映射到一个物理服务 (host 指向 ip + port)，也可以指向一个 upstream 来做到负载均衡。通俗说，这个service就是后台访问接口配置。 导航到 SERVICES 页面并添加 ADD NEW SERVICE 字段说明 ： Url 参数是一个简化参数，用于一次性添加protocol，host，port和path。另外不要把 SERVICE 当作后端的具体API，要把它当作一个大的服务，该服务下面有多个API（endpoint or route）。所以创建服务的时候填上该服务的域名就行了。当然也可以是一个带 path 的 Url ，这样每个关联的API (

有问题为什么不问问神奇的 man 呢？ rebase 也算是我比较常用的一个指令了，但是很长时间以来，对这个指令的认识还是不够深刻，于是就找了个时间认真地读了一下 git rebase 的文档。这份文档不需要在网络上查找，在自己的电脑上直接使用 man git-rebase 就可以查看了。在这份文档中，被提到的几个重要的 rebase 参数就是 newbase 、 upstream 、 branch 。除此之外， -i 也是一个能够极大的提升使用体验的选项，允许我们交互式的选取需要操作的提交。 git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] [<upstream> [<branch>]] 三个参数 在执行 git rebase 的之前，如果我们指定了 branch 这个参数，那么 git 会在开始 rebase 操作之前签出到 branch 。 接着，git 会把所有在当前分支但不在 upstream 分支的提交保存到一个临时区域。如果想要在 rebase 开始之前了解哪些提交会被移到临时区域，可以使用 git log <upstream>..<branch> 查看。 然后，如果我们设置了 newbase ，那么 git 会把当前分支重置到 newbase ，否则，就重置到

安装包： npm install koa-body --save 引用： const koaBody = require('koa-body'); app.use(koaBody({ multipart: true, formidable: { maxFileSize: 200*1024*1024 // 设置上传文件大小最大限制，默认2M } })); 使用koa-body中间件后，即可通过ctx.request.files获取上传的文件 提醒： 新版本的koa-body通过ctx.request.files获取上传的文件 旧版本的koa-body通过ctx.request.body.files获取上传的文件 获取到文件之后，通过fs将文件保存到服务器的指定目录 上传文件： const router = require('koa-router')() const fs = require('fs') const path = require("path") router.prefix('/upload') router.post('/uploadfile', async (ctx, next) => { // 上传单个文件 const file = ctx.request.files.file; // 获取上传文件 // 创建可读流 const reader = fs

nginx服务器 日志相关指令主要有两条 ，一条是 log_format ，用来设置日志格式，另外一条是 access_log ，用来指定日志文件的存放路径、格式和缓存大小，一般在nginx的配置文件中日记配置(/usr/local/nginx/conf/nginx.conf)。 nginx的log_format有很多可选的参数用于指示服务器的活动状态，默认的是： log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; 想要记录更详细的信息需要自己设置log_format，具体可设置的参数格式及说明如下： 参数 说明 示例 remote_addr 客户端地址 211.28.65.253 remote_user 客户端用户名称 – time_local 访问时间和时区 18/Jul/2012:17:00:01 +0800 request 请求的URL和HTTP协议 “GET /article-10000.html HTTP/1.1” http_host 请求地址，即浏览器中你输入的地址（IP或域名） 192.168.1