Nginx

nginx mac上常用命令启动命令： sudo nginx疾速进行命令 sudo nginx -s stop安稳退出命令：sudo nginx -s quit从新加载配置文件命令：sudo nginx -s reload (当配置文件批改后，可执行此命令)文件批改后记得保留 source {批改文件的绝对路径}

1. 创立文件夹        docker容器运行期间的文件在容器终止时会被清空，所以须要对一些目录进行映射到宿主机，以此保留运行期间的数据到宿主机，也不便依据产生的数据进行环境还原。须要映射的文件夹如下：1. nginx文件配置目录：E:\docker\www\centos\nginx\conf:/usr/local/nginx/conf2. nginx日志目录：E:\docker\www\centos\nginx\logs:/usr/local/nginx/logs2. 创立centos7.6容器docker run -itd -v E:\docker\www\centos\nginx\conf:/usr/local/nginx/conf -v E:\docker\www\centos\nginx\logs:/usr/local/nginx/logs --name centos7_6 --network php_env --network-alias centos7_6 -p 80:80 centos:centos7.6.1810 /bin/bash3. 进入centos7.6容器装置nginx1. 进入容器：docker exec -it centos7_6 /bin/bash2. 进入用户目录：cd /usr/local3. 装置nginx依赖 yum install -y gcc yum install -y pcre pcre-devel yum install -y zlib zlib-devel yum install -y openssl openssl-devel 4. 装置wget yum install -y wget 5. 下载nginx1.9.9版本的压缩包 wget http://nginx.org/download/nginx-1.9.9.tar.gz 6. 解压nginx1.9.9的压缩包 tar -zxvf nginx-1.9.9.tar.gz 7. 进入解压文件夹 cd nginx-1.9.9 8. 查看依赖并且编译装置 ./configure && make && make install 4. 搭建多我的项目环境1. 创立/usr/local/nginx/conf/vhosts文件夹 mkdir /usr/local/nginx/conf/vhosts 2. 批改nginx.cong配置文件,减少多我的项目配置读取，编辑/usr/local/nginx/conf/nginx.conf文件，在http块的底部减少语句： include /usr/local/nginx/conf/vhosts/*.conf; 5. 启动ngnix1. 启动nginx /usr/local/nginx/sbin/nginx 2. 浏览器拜访http://127.0.0.1 显示nginx页面示意启动胜利

=====实现并行处理申请的三种形式=====1、多过程形式（apache）服务器接管到一个客户端，主过程生成一个子过程和客户端建设连贯，进行交互。连贯断开，子过程完结 长处：设计实现简略，子过程之间互相独立，解决申请过程中彼此不受烦扰。某个子过程产生问题时，不容易影响到其余过程，保障了服务的稳定性。退出时，占用资源会被零碎回收，也不会留下任何垃圾。 毛病：操作系统产生一个子过程，须要进行内存复制等操作，资源和工夫上会产生额定开销。web服务器接管到大量申请时，会对系统资源造成压力，导致系统性能降落 2、多线程形式（IIS）服务器接管到一个客户端时，会由服务器主过程派生一个线程进去和该客户端进行交互 长处：操作系统产生线程的开销远远小于产生一个过程的开销，很大水平上加重了Web服务器对系统资源的要求。应用线程进行任务调度，开发方面遵行肯定规范，相对来说比拟标准和有利于合作 毛病：多个线程位于同一个过程，能够拜访同样的内存空间，彼此之间相互影响。同时，开发过程中不可避免的要由开发者本人对内存进行治理，减少了出错的危险，积小成多，可能最终对整个服务器产生重大影响。 3、异步形式（Nginx：异步非阻塞）同步和异步时形容通信模式的概念同步 ：发送方发送申请后，须要期待接管方发回响应后，才接着发送下个申请异步 ：发送方发送申请后，不期待接管方发回响应，持续发送下个申请阻塞和非阻塞时形容过程解决调用的形式，网络通信中，次要指网络套接字Socket的阻塞和非阻塞形式，而Socket的理论就是I/O操作阻塞 ：调用后果返回前，之前线程从运行状态被挂起，等到调用后果返回后，才进入就绪状态，获取CPU继续执行（接管方）非阻塞 ：调用后果不能立即返回，以后线程也不会被挂起，立刻返回执行下一个调用。（接管方） =====nginx如何解决申请===== worker_process(异步非阻塞)master process worker_process(异步非阻塞) worker_process(异步非阻塞)工作过程接管到客户端申请后，调用I/O进行解决，如果不能立刻失去后果，就去解决其余申请。客户端在此期间也无需期待响应，能够去解决其余事件。当I/O调用返回后果时，就会告诉此工作过程。该工作过程失去告诉，临时挂起以后解决的事务，去响应客户端的申请。 =====nginx事件处理机制=====I/O调用把本人的状态告诉给工作过程的两种形式：1、工作过程在进行其余工作的过程中隔一段时间就去检查一下I/O运行状态，如果实现就去响应客户端，如果未实现，就持续正在进行的工作2、I/O调用在实现后被动告诉工作过程。select/poll/epoll/kqueque等这样的零碎调用就是用来反对这种形式。这些零碎调用，也常被称为事件驱动模型。 =====nginx事件驱动模型=====Nginx服务器响应和解决Web申请的过程，就是基于事件驱动模型的，蕴含事件收集器，事件发送器，事件处理器等三局部根本单元。重点介绍一下事件处理器，咱们在编写服务器解决模型程序时，基于事件驱动模型，指标对象中的事件处理器能够有以下几种实现办法：1、事件发送器每传递过去一个申请，指标对象就创立一个新的过程，调用事件处理器来解决该申请。－－实现起来简略，但创立新的过程开销比拟大，导致服务器性能差2、事件发送器每传递过去一个申请，指标对象就创立一个新的线程，调用事件处理器来解决该申请。－－波及到线程同步，可能会面临死锁、同步等一系列问题，编码比较复杂3、事件发送器每传递过去一个申请，指标对象就将其放入一个待处理事件列表，应用非阻塞I/O形式调用事件处理器来解决该申请－－编码和逻辑都比后面两种简单，但大多网络服务器都采纳此形式，逐步造成了所谓的“事件驱动解决库”。事件驱动解决库又被称为多路IO复用办法，最常见是以下三种：select模型，poll模型，epoll模型。另外，还反对其余模型。 select 库 Linux和Windows平台都反对的根本事件驱动模型库。创立关注事件的描述符汇合。对一个描述符关注读事件、写事件以及异样事件，要创立三类事件描述符汇合。调用底层提供的select()函数，等待时间产生（select的阻塞与是否设置非阻塞I/O没有关系），轮询所有事件描述符汇合中的每一个事件描述符，查看是否有相应事件产生，如果有，就进行解决 poll库 Linux平台的根本事件驱动模型，Windows不反对。与select库根本工作形式雷同，都是创立一个关注事件的描述符汇合，再去期待这些事件产生，如何再轮询描述符汇合，查看有没有工夫产生，有就解决。 区别在于，select库创立了3个描述符汇合，须要别离轮询这3个汇合。poll库只须要创立一个汇合，每个描述符对应的构造上别离设置读、写、异样事件。最初轮询的时候，能够同时查看这3种事件是否产生，是select库的优化实现 epoll库 Nginx服务器反对的高性能事件驱动库之一，公认的十分优良事件驱动模型，和poll，select有很大的不同。 以上的两个库，在描述符表多的利用中，效率显得比拟低下。好的做法是，把描述符列表的治理交给内核负责，一旦有某种事件产生，内核把产生事件的描述符列表告诉给过程，防止轮询整个描述符列表，epoll库就是这种模型。 epoll库通过相干调用告诉内核创立一个有N个描述符的事件列表；而后，给这些描述符设置所关注的事件，并把它增加到内核事件列表中去，在具体的编码过程中也能够通过相干调用对事件列表中的描述符进行批改和删除。实现设置后，epoll库就开始期待内核告诉事件产生。某一事件产生后，内核将产生事件的描述符列表上报给epoll库。失去事件列表的epoll库，就能够进行事件处理了。 =====nginx服务器架构===== nginx服务器的构造大抵分为主过程、工作过程、后端服务器和缓存等局部。 nginx服务器的三大类过程：主过程、工作过程、缓存索引重建及治理过程 服务启动后，产生一个master process，主过程执行一系列工作后产生一个或者多个worker processes。 主过程次要进行nginx配置文件解析、数据结构初始化、模块配置和注册、信号处理、网络监听生成、工作过程生成和治理等工作。 工作过程次要进行过程初始化、模块调用和申请解决等工作，是nginx服务器提供服务的主体

Nginx 相干介绍(Nginx是什么?能干嘛?)Nginx的产生　没有听过Nginx？那么肯定听过它的"同行"Apache吧！Nginx同Apache一样都是一种WEB服务器。基于REST架构格调，以对立资源描述符(Uniform Resources Identifier)URI或者对立资源定位符(Uniform Resources Locator)URL作为沟通根据，通过HTTP协定提供各种网络服务。 然而，这些服务器在设计之初受到过后环境的局限，例如过后的用户规模，网络带宽，产品特点等局限并且各自的定位和倒退都不尽相同。这也使得各个WEB服务器有着各自显明的特点。 Apache的倒退期间很长，而且是毫无争议的世界第一大服务器。它有着很多长处：稳固、开源、跨平台等等。它呈现的工夫太长了，它衰亡的年代，互联网产业远远比不上当初。所以它被设计为一个重量级的。它是不反对高并发的服务器。在Apache上运行数以万计的并发拜访，会导致服务器耗费大量内存。操作系统对其进行过程或线程间的切换也耗费了大量的CPU资源，导致HTTP申请的均匀响应速度升高。 这些都决定了Apache不可能成为高性能WEB服务器，轻量级高并发服务器Nginx就应运而生了。 俄罗斯的工程师Igor Sysoev，他在为Rambler Media工作期间，应用C语言开发了Nginx。Nginx作为WEB服务器始终为Rambler Media提供杰出而又稳固的服务。 而后呢，Igor Sysoev将Nginx代码开源，并且赋予自由软件许可证。 因为： Nginx应用基于事件驱动架构，使得其能够反对数以百万级别的TCP连贯高度的模块化和自由软件许可证使得第三方模块层出不穷（这是个开源的时代啊~）Nginx是一个跨平台服务器，能够运行在Linux，Windows，FreeBSD，Solaris，AIX，Mac OS等操作系统上这些优良的设计带来的是极大的稳定性　所以，Nginx火了！ Nginx的用武之地　Nginx是一款自在的、开源的、高性能的HTTP服务器和反向代理服务器；同时也是一个IMAP、POP3、SMTP代理服务器；Nginx能够作为一个HTTP服务器进行网站的公布解决，另外Nginx能够作为反向代理进行负载平衡的实现。 对于代理　说到代理，首先咱们要明确一个概念，所谓代理就是一个代表、一个渠道； 此时就波及到两个角色，一个是被代理角色，一个是指标角色，被代理角色通过这个代理拜访指标角色实现一些工作的过程称为代理操作过程；如同生存中的专卖店~客人到adidas专卖店买了一双鞋，这个专卖店就是代理，被代理角色就是adidas厂家，指标角色就是用户。 正向代理　说反向代理之前，咱们先看看正向代理，正向代理也是大家最常接触的到的代理模式，咱们会从两个方面来说对于正向代理的解决模式，别离从软件方面和生存方面来解释一下什么叫正向代理。 在现在的网络环境下，咱们如果因为技术须要要去拜访国外的某些网站，此时你会发现位于国外的某网站咱们通过浏览器是没有方法拜访的，此时大家可能都会用一个操作FQ进行拜访，FQ的形式次要是找到一个能够拜访国外网站的代理服务器，咱们将申请发送给代理服务器，代理服务器去拜访国外的网站，而后将拜访到的数据传递给咱们！ 上述这样的代理模式称为正向代理，正向代理最大的特点是客户端十分明确要拜访的服务器地址；服务器只分明申请来自哪个代理服务器，而不分明来自哪个具体的客户端；正向代理模式屏蔽或者暗藏了实在客户端信息。来看个示意图（我把客户端和正向代理框在一块，同属于一个环境，前面我有介绍）： 客户端必须设置正向代理服务器，当然前提是要晓得正向代理服务器的IP地址，还有代理程序的端口。如图。 总结来说：正向代理，"它代理的是客户端，代客户端发出请求"，是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器获得内容，客户端向代理发送一个申请并指定指标(原始服务器)，而后代理向原始服务器转交申请并将取得的内容返回给客户端。客户端必须要进行一些特地的设置能力应用正向代理。 正向代理的用处：（1）拜访原来无法访问的资源，如Google（2）能够做缓存，减速拜访资源（3）对客户端拜访受权，上网进行认证（4）代理能够记录用户拜访记录（上网行为治理），对外暗藏用户信息 反向代理　明确了什么是正向代理，咱们持续看对于反向代理的解决形式，举例如我大天朝的某宝网站，每天同时连贯到网站的拜访人数曾经爆表，单个服务器远远不能满足人民日益增长的购买欲望了，此时就呈现了一个大家耳熟能详的名词：分布式部署；也就是通过部署多台服务器来解决拜访人数限度的问题；某宝网站中大部分性能也是间接应用Nginx进行反向代理实现的，并且通过封装Nginx和其余的组件之后起了个高大上的名字：Tengine，有趣味的童鞋能够拜访Tengine的官网查看具体的信息：http://tengine.taobao.org/。那么反向代理具体是通过什么样的形式实现的分布式的集群操作呢，咱们先看一个示意图（我把服务器和反向代理框在一块，同属于一个环境，前面我有介绍）： 通过上述的图解大家就可以看分明了，多个客户端给服务器发送的申请，Nginx服务器接管到之后，依照肯定的规定分发给了后端的业务解决服务器进行解决了。此时~申请的起源也就是客户端是明确的，然而申请具体由哪台服务器解决的并不明确了，Nginx表演的就是一个反向代理角色。 客户端是无感知代理的存在的，反向代理对外都是通明的，访问者并不知道本人拜访的是一个代理。因为客户端不须要任何配置就能够拜访。 反向代理，"它代理的是服务端，代服务端接管申请"，次要用于服务器集群分布式部署的状况下，反向代理暗藏了服务器的信息。 反向代理的作用：（1）保障内网的平安，通常将反向代理作为公网拜访地址，Web服务器是内网（2）负载平衡，通过反向代理服务器来优化网站的负载 我的项目场景　通常状况下，咱们在理论我的项目操作时，正向代理和反向代理很有可能会存在在一个利用场景中，正向代理代理客户端的申请去拜访指标服务器，指标服务器是一个反向单利服务器，反向代理了多台实在的业务解决服务器。具体的拓扑图如下： 二者区别　截了一张图来阐明正向代理和反向代理二者之间的区别，如图。 图解： 在正向代理中，Proxy和Client同属于一个LAN（图中方框内），暗藏了客户端信息； 在反向代理中，Proxy和Server同属于一个LAN（图中方框内），暗藏了服务端信息； 实际上，Proxy在两种代理中做的事件都是替服务器代为收发申请和响应，不过从构造上看正好左右调换了一下，所以把后呈现的那种代理形式称为反向代理了。 负载平衡　咱们曾经明确了所谓代理服务器的概念，那么接下来，Nginx表演了反向代理服务器的角色，它是以根据什么样的规定进行申请散发的呢？不必的我的项目利用场景，散发的规定是否能够管制呢？ ...

NEXUS 介绍nexus 是java开发中maven组件的公有库，对于团队开发是必不可少的撑持服务 NEXUS装置咱们先上NEXUS 官网查找最新的NEXUS安装包。nexus-repository-oss下载 [thinktik@host nexus3]$ wget https://sonatype-download.global.ssl.fastly.net/repository/repositoryManager/3/nexus-3.16.1-02-unix.tar.gz[thinktik@host nexus3]$ tar -zxvf nexus-3.16.1-02-unix.tar.gz [thinktik@host nexus3]$ lsnexus-3.16.1-02 nexus-3.16.1-02-unix.tar.gz sonatype-work# nexus 须要java环境，倡议JDK1.8[thinktik@host nexus3]$ java -versionjava version "1.8.0_201"Java(TM) SE Runtime Environment (build 1.8.0_201-b09)Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)[thinktik@host nexus3]$ cd /home/thinktik/nexus3/nexus-3.16.1-02/bin[thinktik@host bin]$ lscontrib nexus nexus.rc nexus.vmoptions# 第一次启动，倡议这样看启动过程，及时发现问题[thinktik@host bin]$ ./nexus run# 没有问题的话，应用这个启动nexus服务，这样nexus会在后盾启动服务[thinktik@host bin]$ ./nexus startNEXUS配置批改nexus升高内存占用 个别nexus默认的配置对机器的内存要求比拟高，对于集体开发者学习用的高价云服务器来讲是没有必要给这么多资源的，要么造成无谓的节约要么因为机器内存无限导致nexus无奈启动。我倡议个别集体开发和学习依照我这个配置来，尽量升高机器硬件要求。 -Xms100M-Xmx330M-XX:MaxDirectMemorySize=220M-XX:+UnlockDiagnosticVMOptions-XX:+UnsyncloadClass-XX:+LogVMOutput-XX:LogFile=../sonatype-work/nexus3/log/jvm.log-XX:-OmitStackTraceInFastThrow-Djava.net.preferIPv4Stack=true-Dkaraf.home=.-Dkaraf.base=.-Dkaraf.etc=etc/karaf-Djava.util.logging.config.file=etc/karaf/java.util.logging.properties-Dkaraf.data=../sonatype-work/nexus3-Djava.io.tmpdir=../sonatype-work/nexus3/tmp-Dkaraf.startLocalConsole=falseNGINX代理neuxs 启动后默认监听的是计算机的8081端口，你能够应用ip:端口的形式间接拜访neuxs。不过不倡议大家在服务器上裸露过多的端口，免得引起平安问题。应用nginx代理转发neuxs服务的形式会更平安也更不便一些。这里我应用域名转发的形式实现对nexus的服务代理。 server { listen 80; server_name nexus.missioncenter.online; rewrite ^(.*)$ https://$host$1 permanent; } server { listen 443; server_name nexus.missioncenter.online; ssl on; root html; index index.html index.htm; ssl_certificate /home/thinktik/env/nginx/cert/nexus_cert.pem; ssl_certificate_key /home/thinktik/env/nginx/cert/nexus_cert.key; ssl_session_timeout 5m; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; location / { proxy_pass http://127.0.0.1:8081; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto "https"; } } 本文原创链接: Linux Nexus 装置 ...

总结：拜访不了用正向，拜访不到用反向！Nginx正向代理与反向代理

Nginx 禁止IP拜访 咱们在应用的时候会遇到很多的歹意IP攻打，这个时候就要用到Nginx 禁止IP拜访了。上面咱们就先看看Nginx的默认虚拟主机在用户通过IP拜访，或者通过未设置的域名拜访（比方有人把他本人的域名指向了你的ip）的时候失效最要害的一点是，在server的设置外面增加这一行： listen 80 default; 前面的default参数示意这个是默认虚拟主机。 Nginx 禁止IP拜访这个设置十分有用。 比方他人通过ip或者未知域名拜访你的网站的时候，你心愿禁止显示任何无效内容，能够给他返回500.目前国内很多机房都要求网站主敞开空主机头，避免未备案的域名指向过去造成麻烦。就能够这样设置： server { listen 80 default; return 500; } 也能够把这些流量收集起来，导入到本人的网站，只有做以下跳转设置就能够： server { listen 80 default; rewrite ^(.*) http://www.mydomain.com permanent; } 依照如上设置后，的确不能通过IP拜访服务器了，然而在应该用中呈现当server_name后跟多个域名时，其中一个域名怎么都无法访问，设置如下： server { listen 80; server_name www.abc.com abc.com } 没更改之前，通过server_name 中的www.abc.com abc.com均可拜访服务器，退出Nginx 禁止IP拜访的设置后，通过abc.com无法访问服务器了，www.abc.com能够拜访，用 Nginx -t 检测配置文件会提醒warning： 最初站长博客通过在listen 80 default;后再加server_name _;解决，模式如下： #禁止IP拜访 server { listen 80 default; server_name _; server_name www.abc.com abc.com return 500; } 这样，通过abc.com就能拜访服务器了。 感激浏览，心愿能帮忙到大家，谢谢大家对本站的反对！

原创：杂谈_浅谈nginx,gunicorn,flask差别比对 角色划分flask(django):Python的Web应用程序（如Flask,django） nginx:web服务器，用户角度间接对接应用,申请响应的request-response出入口 WSGI（Web Server Gateway Interface），翻译为Python web服务器网关接口，即Python的Web应用程序（如Flask）和Web服务器(如Nginx)之间的一种通信协议。也就是说，如果让你的Web利用在任何服务器上运行，就必须遵循这个协定。 几种部署形式差别Flask 内置 WebServer + Flask App = 弱鸡版本的 Server, 单过程（单 worker) / 失败挂掉 / 不易 Scale Gunicorn + Flask App = 多过程（多 worker) / 多线程 / 失败主动帮你重启 Worker / 可简略Scale 多 Nginx + 多 Gunicorn + Flask App = 小型多实例 Web 利用，个别也会给 gunicorn 挂 supervisor 为何gunicorn简略来说flask自带server太弱了 （几个申请就打满了）。 2大缺点 『单 Worker』只有一个过程在跑所有的申请，而因为实现的简陋性，内置 webserver 很容易卡死。并且只有一个 Worker 在跑申请。在多核 CPU 下，仅仅占用一核。当然，其实也能够多起几个过程。『不足 Worker 的治理』接上，退出负载量上来了，Gunicorn 能够调节 Worker 的数量。而这个货色，内置的 Webserver 是不适宜做这种事件的。Gunicorn 作为 Server 相对而言的晋升。 ...

在做网站的时候，网站的某些url地址个别都会因为某些起因进行变动，这时候如果网站曾经做了很多外链，就须要利用301重定向进行转发. 先大略总结一下网站url地址变动的起因 更好更直观的url地址更利用SEO(我就是因为这个起因)网站目录发生变化旧地址存在问题，比方过滤词之类http转https那么何时才适宜应用301呢？ 永恒更改网页的URL永恒迁徙到新域名从HTTP切换到HTTPShttp转https为什么要应用https? Google 已调整搜索引擎算法，让采纳 HTTPS 的网站在搜寻中排名更靠前从 2017 年开始，Chrome 浏览器已把采纳 HTTP 协定的网站标记为不平安网站新一代的 HTTP/2 协定的反对需以 HTTPS 为根底更平安，而且是趋势nginx配置 server { listen 80; server_name example.com www.example.com; return 301 https://www.example.com$request_uri;}一般url地址变动举个例子， 地址由/abc改成/qwe , nginx只须要这么配置 location ^~ /abc { rewrite ^/abc(.*)$ /qwe/$1 permanent;}我的网站 https://www.jsonformatting.com/

Nginx启动会占用80端口,如果启动不胜利则查看80是否被占用，找到服务过程号结束任务:PID=4

IDEA启动多个我的项目批改我的项目application.yml中的端口配置server.port=''批改 idea 启动配置，勾选Allow parallel run，容许并行启动 别离测试启动的两个我的项目，均拜访胜利 至此，Spring Boot我的项目启动完结。 Nginx 装置部署本地环境为Windows，解压即可 批改装置目录下 conf 目录下的配置文件 nginx.conf，只须批改两处： 新增集群配置新增代理门路#user nobody;worker_processes 1;#error_log logs/error.log;#error_log logs/error.log notice;#error_log logs/error.log info;#pid logs/nginx.pid;events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; #---------------1.新增集群配置------------------------------- upstream soul { # 能够通过批改weight=10的值来设置权重 server 127.0.0.1:9195 weight=10; server 127.0.0.1:9196 weight=10; } server { listen 80; #Nginx的监听端口，默认为80 server_name localhost; #Nginx的监听的主机名 #charset koi8-r; #access_log logs/host.access.log main; location / { #---------------2.新增代理门路------------------------------- #代理门路和集群名称(upstream soul{})须要保持一致 proxy_pass http://soul; proxy_redirect default; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } 省略... }}在Nginx装置的目录下，启动Nginx ...

利用场景在 LNMP （linux、nginx，mysql、php）中的作用或角色：Nginx 是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 在 LNMP 中的作用或角色：nginx 自身不能解决 PHP，它只是个 web 服务器，当接管到申请后，如果是 php 申请，则发给 php 解释器解决，并把后果返回给客户端。php-fpm 是一个守护过程（FastCGI 过程管理器）用于替换 PHP FastCGI 的大部分附加性能，对于高负载网站是十分有用的。sudo apt-get install -y php7.0-fpm 装置sudo apt-get updatesudo apt-get install -y nginx启动所有的启动配置文件都在 /etc/init.d/nginx 这个目录下，所以相干操作都能够在这个文件夹启动命令，这其实就是一个启动脚本。sudo /etc/init.d/nginx startsudo service nginx start原理Nginx 是以多过程的形式来工作的，当然 Nginx 也是反对多线程的形式的。 Nginx 启动后，在 unix 零碎中会以 daemon （守护过程）的形式在后盾运行，后盾过程蕴含一个 master 过程和多个 worker 过程（你能够了解为工人和管理员）。 worker 过程之间是平等的，每个过程，解决申请的机会也是一样的。当咱们提供 80 端口的 http 服务时，一个连贯申请过去，每个过程都有可能解决这个连贯。那么问题来了，到底最初怎么解决，是由什么决定的呢？咱们来看一看一个残缺的申请是怎么通过相互的合作来实现的： （1）首先，每个 worker 过程都是从 master 过程 fork 过去，在 master 过程外面，先建设好须要 listen 的 socket（listenfd）之后，而后再 fork 出多个 worker 过程。 ...

微前端作为解决巨石利用和升高技术框架变动危险的神器，我感觉是当下前端倒退的一大方向，能够在将来5-10内放弃生命力。 作者从2019年12月第一次应用qiankun框架落地微服务一来一级过来了一年多的工夫，期间也产出了两篇入门文章：qiankun微前端实战看这篇就够了 - Vue我的项目篇 和 vue3.0&qiankun2.0极速尝鲜，微前端进阶实战！，有趣味或者刚接触微前端的同学能够去看下。 通过拆分之后，一个巨石利用变成了几个甚至几十个子利用，那么这么多应该该如何敌对又难受的部署呢，上面就来具体的说说几种不同的应用姿态。 [x] 脚本部署 [x] docker部署 [ ] CICD 脚本部署作者在理论我的项目中编写了两种部署脚本，一种是前端开发人员应用的，一种是无需理解代码的施行人员应用的，咱们之间一步到位讲无需代码常识的部署脚本设计。 先说下大抵思路： 应用node+inquirer编写交互式命令行脚本，以伪可视化的模式创立指标服务器列表。应用node+inquirer+ssh2-sftp-client，以伪可视化的模式将代码公布至服务器将脚本放在测试服务器（win），施行人员能够登录测试服务器将测试通过的前端动态文件上传至任意linux服务器。将脚本启动命令文件改成.bat文件，能够实现在win零碎上双击运行。成果如下： 增加指标服务器信息一键部署具体原理就不细说了，node读写，inquirer交互插件的应用inquirer+ssh2-sftp-client将文件推送到服务器指定地址，都是很成熟的插件，脚本部署这块就间接上代码：Github，此外还能够持续优化，将拉取代码、打包、部署做到一起去，更适宜非程序人员。 这种计划长处是对外简略易操作，毛病是须要源码或者至多打包好后的代码，以及须要记录服务器的登录名及明码。 docker 部署作者只花了半天工夫从意识docker到产出可用工程，如有不对之处，欢送斧正。 docker-compose既然是多个微利用，那间接来docker-compose吧。官网简介是这么介绍compose的：负责实现对 Docker 容器集群的疾速编排。 装置。win版的docker自带有docker-compose，咱们间接下载安装docker；其余版本见docker，docker-compose在我的项目根目录增加docker-compose.yml文件。services: # 主利用配置 master: # docker-compose内的容器名 container_name: master # 容器名 restart: always # 重启策略: 容器退出时总是重启容器 build: context: ./master # 服务指定上下文目录 dockerfile: Dockerfile # 绝对于context的dockerfile文件门路 environment: NODE_ENV: 'production' ports: - '2750:2750' # 端口映射，宿主机端口：容器端口 # subapp-login配置 login: container_name: subapp-login restart: always build: context: ./subapp-login dockerfile: Dockerfile environment: NODE_ENV: 'production' ports: - '2753:2753' depends_on: # 依赖容器名，会在此容器启动之后启动 - master # ...其余子利用配置办法如上在根目录增加.dockerignore文件，外面写入node_modules依据docker-compose.yml的设置，在每个子利用文件夹下增加Dockerfile和对应的nginx配置文件yourname.conf。Dockerfile文件，留神外面门路即可# 从官网拉取nginx镜像FROM nginx # 复制dist文件夹到镜像空间，留神docker-compose.yml中指定master的build从./master文件夹开始COPY dist/ /usr/local/web/master/ # 复制master.conf到镜像空间COPY master.conf /etc/nginx/conf.d/master.confmaster.conf文件，这里nginx配置和一般无二，主利用比子利用多了接口代理，少了容许跨域头信息，其余统一。 server { listen 2750; server_name 127.0.0.1; #charset koi8-r; #access_log logs/host.access.log main; location / { root /usr/local/future/web/master; index index.html index.htm; try_files $uri $uri/ /index.html; # 一般模块接口地址 location ^~ /Api/ { proxy_pass $host:3700/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; #因为服务器端源码(倡议大家做好大小写匹配)只匹配了"Upgrade"字符串,所以如果这里填"upgrade"服务器端会将这条http申请当成一般的申请,导致websocket握手失败 proxy_set_header Connection "Upgrade"; proxy_set_header Remote_addr $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 600s; } # 解决 nginx 禁止post申请问题，须要后盾配置跨域 error_page 405 =200 http://$host$request_uri; } error_page 502 503 504 /50x.html; location = /50x.html { root /usr/local/future/web/master; } }启动配置好的docker容器集群疾速编排docker-compose up -d终端会顺次显示步骤的打印信息，期待即可，胜利后如果是win零碎，能够关上docker可视化客户端查看 ...

先说区别last，重写后的规定，会持续用重写后的值去匹配上面的location。break，重写后的规定，不会去匹配上面的location。应用新的规定，间接发动一次http申请了。Nginx 配置文件server { listen 88; server_name _; location /break { # location 1 rewrite ^/break/(.*)$ /bak/$1 break; } location /last { # location 2 rewrite ^/last/(.*)$ /bak/$1 last; } location /bak { # location 3 default_type text/html; return 200 $uri; }}拜访 http://rumenz.com:88/break/one命中location1,浏览器地址栏没有变,间接去找/nginx/html/bak/one文件,因为没有这个文件所以返回404。浏览器 Nginx谬误(error.log)日志/nginx/html/bak/one failed (2: No such file or directory)break示意重写后进行不再匹配location块。拜访 http://rumenz.com:88/last/one命中location2,浏览器地址栏没有变,从新匹配到location3last示意重写后跳到location块再次用重写后的地址匹配break和last的应用场景break文件下载,暗藏爱护实在文件服务器。location /down { rewrite ^/down/(.*)$ https://rumenz.com/file/$1 break;}last接口地址改写,将https://rumenz.com/api/list改写成https://rumenz.com/newapi/listlocation /api { rewrite ^/api/(.*)$ /newapi/$1 last;}location /newapi { default_type Application/json; return 200 '{"code":200,"msg":"ok","data":["JSON.IM","json格式化"]}';}关注微信公众号:【入门小站】,解锁更多知识点 ...

开发框架Spring Boot 应用Spring Boot能够轻松地创立独立的，基于生产级别的基于Spring的应用程序，您能够“运行”它们。 咱们对Spring平台和第三方库持回心转意的观点，因而您能够以最小的麻烦开始应用。大多数Spring Boot应用程序只须要很少的Spring配置。 特色 创立独立的Spring应用程序间接嵌入Tomcat，Jetty或Undertow（无需部署WAR文件）提供自以为是的“入门”依赖项，以简化构建配置尽可能主动配置Spring和3rd Party库提供生产就绪的性能，例如指标，运行状况检查和内部配置齐全没有代码生成，也不须要XML配置Spring CloudSpring Cloud为开发人员提供了工具，以疾速构建分布式系统中的某些常见模式（例如，配置管理，服务发现，断路器，智能路由，微代理，管制总线，一次性令牌，全局锁，领导选举，分布式会话，群集状态）。分布式系统的协调导致样板式样，并且应用Spring Cloud开发人员能够疾速站起来实现这些样板的服务和应用程序。它们能够在任何分布式环境中失常工作，包含开发人员本人的笔记本电脑，裸机数据中心以及Cloud Foundry等托管平台。 Spring Cloud致力于为典型的用例和扩大机制提供良好的开箱即用体验，以涵盖其余用例。 分布式/版本化配置服务注册和发现路由服务到服务的通话负载平衡断路器全局锁领导选举和集群状态分布式消息传递Mybatis plus MyBatis是一流的持久性框架，反对自定义SQL，存储过程和高级映射。MyBatis打消了简直所有的JDBC代码以及参数的手动设置和后果检索。MyBatis能够应用简略的XML或正文进行配置，并将图元，映射接口和Java POJO（一般的旧Java对象）映射到数据库记录。 MyBatis-Plus（简称 MP）是一个 MyBatis 的加强工具，在 MyBatis 的根底上只做加强不做扭转，为简化开发、提高效率而生。 个性 无侵入：只做加强不做扭转，引入它不会对现有工程产生影响，如丝般顺滑损耗小：启动即会主动注入根本 CURD，性能根本无损耗，间接面向对象操作弱小的 CRUD 操作：内置通用 Mapper、通用 Service，仅仅通过大量配置即可实现单表大部分 CRUD 操作，更有弱小的条件结构器，满足各类应用需要反对 Lambda 模式调用：通过 Lambda 表达式，不便的编写各类查问条件，无需再放心字段写错反对主键主动生成：反对多达 4 种主键策略（内含分布式惟一 ID 生成器 - Sequence），可自在配置，完满解决主键问题反对 ActiveRecord 模式：反对 ActiveRecord 模式调用，实体类只需继承 Model 类即可进行弱小的 CRUD 操作反对自定义全局通用操作：反对全局通用办法注入（ Write once, use anywhere ）内置代码生成器：采纳代码或者 Maven 插件可疾速生成 Mapper 、 Model 、 Service 、 Controller 层代码，反对模板引擎，更有超多自定义配置等您来应用内置分页插件：基于 MyBatis 物理分页，开发者无需关怀具体操作，配置好插件之后，写分页等同于一般 List 查问分页插件反对多种数据库：反对 MySQL、MariaDB、Oracle、DB2、H2、HSQL、SQLite、Postgre、SQLServer 等多种数据库内置性能剖析插件：可输入 Sql 语句以及其执行工夫，倡议开发测试时启用该性能，能疾速揪出慢查问内置全局拦挡插件：提供全表 delete 、 update 操作智能剖析阻断，也可自定义拦挡规定，预防误操作反对数据库 ...

什么是NginxNginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协定下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中体现较好，中国大陆应用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等Nginx的次要作用又是什么1. 负载平衡负载平衡是高可用网络基础架构的要害组件，通常用于将工作负载散布到多个服务器来进步网站、利用、数据库或其余服务的性能和可靠性上图来解释一下吧 比方我本人创立了一个网站，分享一些学习心得之类的货色，一开始的时候拜访数量少，那么一台服务器就能够撑持，然而起初有一天我忽然成为大明星，那么这时候有很多人想要拜访我的网站，慢慢的一台服务器不足以解决大量的申请，这时候就须要减少服务器来减缓压力，如果我减少了两台服务器，我不能让拜访的人须要记住3个域名吧，就比方百度，他也有很多台服务器，然而咱们只须要记住百度就能够了，那么这是怎末做到的呢？ 这个时候呢我就能够在搭建一台新的Nginx服务器，让所有的申请都先来拜访Nginx服务器，而后在由Nginx派发解决申请到其余服务器上Nginx是不解决申请的，他只是依据不同的策略来派发到不同的服务器上，这样是不是就解决了问题，用户只须要记住一个域名，而且申请量增大的时候也不会导致服务器宕机 1.1 负载平衡策略从下面咱们晓得了Nginx是能够依据不同的策略来派发解决申请的，那么都有什么策略呢？ 轮询（默认） 每个申请按工夫程序逐个调配到不同的后端服务器，如果后端服务器宕机，能主动剔除指定权重 指定轮询几率，weight和拜访比率成正比，用于后端服务器性能不均的状况ip_hash 指定负载均衡器依照基于客户端IP的调配形式，这个办法确保了雷同的客户端的申请始终发送到雷同的服务器，以保障session会话。这样每个访客都固定拜访一个后端服务器，能够解决session不能跨服务器的问题least_conn(最小连接数) 把申请转发给连接数较少的后端服务器。轮询算法是把申请均匀的转发给各个后端，使它们的负载大致相同；然而，有些申请占用的工夫很长，会导致其所在的后端负载较高。这种状况下，least_conn这种形式就能够达到更好的负载平衡成果第三方策略 第三方的负载平衡策略的实现须要装置第三方插件 fair 依照服务器端的响应工夫来调配申请，响应工夫短的优先调配url_hash 拜访url的hash后果来调配申请，使每个url定向到同一个后端服务器，要配合缓存命中来应用。同一个资源屡次申请，可能会达到不同的服务器上，导致不必要的屡次下载，缓存命中率不高，以及一些资源工夫的节约。而应用url_hash，能够使得同一个url（也就是同一个资源申请）会达到同一台服务器，一旦缓存住了资源，再此收到申请，就能够从缓存中读取 1.2 负载平衡策略的配置文件 - 轮询 这个的作用就是服务器的一个汇合，所有会被Nginx派发工作的服务器在这里配置 upstream是固定值 nodes 这个是随便的名字然而要跟上面的server.ocation.proxy_pass 中http后的名字统一 upstream nodes { server 192.168.1.11; server 192.168.1.12; } server { listen 80; //监听的端口号 server_name 127.0.0.1; //Nginx 服务器地址 location / { // / 示意所有的申请 proxy_pass http://nodes; //被转发的服务器地址 } - 权重 upstream nodes { server 192.168.1.11 weight=3； //weight 默认值是1数值越大，代表被被拜访的次数也会越多 server 192.168.1.12 weight=10； } server { listen 80; //监听的端口号 server_name 127.0.0.1; //Nginx 服务器地址 location / { // / 示意所有的申请 proxy_pass http://nodes; //被转发的服务器地址 } - least_conn(最小连接数) upstream nodes { least_conn; //请连接数较少的后端服务器 server 192.168.1.11； //weight 默认值是1数值越大，代表被被拜访的次数也会越多 server 192.168.1.12； } server { listen 80; //监听的端口号 server_name 127.0.0.1; //Nginx 服务器地址 location / { // / 示意所有的申请 proxy_pass http://nodes; //被转发的服务器地址 } - ip_hash upstream nodes { ip_hash; //申请按拜访ip的hash后果调配 server 192.168.1.11； //weight 默认值是1数值越大，代表被被拜访的次数也会越多 server 192.168.1.12； } server { listen 80; //监听的端口号 server_name 127.0.0.1; //Nginx 服务器地址 location / { // / 示意所有的申请 proxy_pass http://nodes; //被转发的服务器地址 } - fair upstream nodes { server 192.168.1.11； //weight 默认值是1数值越大，代表被被拜访的次数也会越多 server 192.168.1.12； fair;//后端服务器的响应工夫来调配申请，响应工夫短的优先调配 } server { listen 80; //监听的端口号 server_name 127.0.0.1; //Nginx 服务器地址 location / { // / 示意所有的申请 proxy_pass http://nodes; //被转发的服务器地址 } - url_hash upstream nodes { server 192.168.1.11； //weight 默认值是1数值越大，代表被被拜访的次数也会越多 server 192.168.1.12； hash $request_uri; hash_method crc32;//按拜访url的hash后果来调配申请，使每个url定向到同一个后端服务器 } server { listen 80; //监听的端口号 server_name 127.0.0.1; //Nginx 服务器地址 location / { // / 示意所有的申请 proxy_pass http://nodes; //被转发的服务器地址 } 以上文件都是在nginx.conf外面配置 ...

在宝塔面板上配置nginx的反向代理时,遇到404的问题,经查资料,找到解决方案,这个问题个别是没有正确配置proxy_pass.集体比拟懒,间接引知乎上的答复吧: 在nginx中配置proxy_pass反向代理时，当在前面的url加上了/，相当于是相对根门路，则nginx不会把location中匹配的门路局部给代理走;如果没有/，则会把匹配的门路局部也给代理走。 例： 拜访门路:/pss/bill.html1.当nginx配置文件proxy_pass后边的url带"/"时:location /pss/ { proxy_pass http://127.0.0.1:18081/;} 代理到后端的门路为：http://127.0.0.1:18081/bill.html，省略了匹配到的/pss/门路； 2. 当nginx配置文件proxy_pass后边的url不带"/"时：location /pss/ { proxy_pass http://127.0.0.1:18081;}代理到后端的门路为：http://127.0.0.1:18081/pss/bill.html，连同匹配到的/pss/门路，一起进行反向代理； 作者：韩玲链接：https://www.zhihu.com/questio...起源：知乎著作权归作者所有。商业转载请分割作者取得受权，非商业转载请注明出处。

引子最近常常用到 Nginx ，每次开机要手动启动一下，想设置为开机主动执行 start nginx ，找了下材料尝试后总结一下。 零碎：Windows 10 家庭中文版版本号：20H2操作系统版本：19042.685nginx：版本 1.18.0 ，只配置了端口和 root 字段。OriginMy GitHub解决形式Windows 能够通过手动批改注册表设置启动项，感觉有些麻烦，还是找个工具。找到工具 WinSW ，它能够将任何利用包裹并作为一个 Windows 服务治理。在这里能够下载编译好的可执行文件。本次应用的版本是 WinSW v3.0.0-alpha.7 。 WinSW 作为一个全局工具应用： 下载 WinSW.exe 或 WinSW.zip 。新建 myapp.xml （更具体阐明见文档和示例）。运行 winsw install myapp.xml [options] 装置服务。运行 winsw start myapp.xml 开启服务。运行 winsw status myapp.xml 查看服务是否启动和运行。在实际操作过程中发现了其它留神点： 输出命令时参数 myapp.xml 并不是必须，想要省略，让配置文件名称跟 WinSW.exe 文件的名称统一即可，否则不带配置文件名称参数会报错。WinSW.exe 文件须要搁置在 nginx 装置目录下，否则执行指令的时候会提醒找不到 nginx 的配置文件。出谬误的时候，会输入日志，看日志有助于排查问题。上面是集体配置步骤示例。 第 1 步将下载的 exe 文件挪动到 nginx 目录下，重命名为 winsw.exe ,新建配置文件 winsw.xml ，写入上面的配置： <service> <id>nginx service</id> <name>Nginx</name> <description>This service runs Nginx.</description> <env name="NGINX_COMIC" value="%BASE%" /> <prestart>start D:\nginx-1.18.0\nginx.exe</prestart> <executable>D:\nginx-1.18.0\nginx.exe</executable> <prestop>D:\nginx-1.18.0\nginx.exe -s stop</prestop> <log mode="roll" /> <onfailure action="none" /></service> ...

景象通过首页进入拜访页面失常，刷新之后出404页面 起因起因是因为web单页面开发模式，只有一个index.html入口，其余门路是前端路由去跳转的，nginx没有对应这个门路，当然就是404了。 解决方案location / { root /usr/nginx/app/dist/; index index.html; try_files $uri $uri/ /index.html;}总结在配置中加上try_files，意思跟翻译差不多，“尝试读取文件”。u r i 这 个 是 n g i n x 的 一 个 变 量 ， 存 放 着 用 户 访 问 的 地 址 , 例 如 h t t p : / / l o c a l h o s t : 8200 / c h o o s e S i z e 那 么 uri 这个是nginx的一个变量，寄存着用户拜访的地址,例如http://localhost:8200/chooseSize 那么uri这个是nginx的一个变量，寄存着用户拜访的地址,例如http://localhost:8200/chooseSize那么uri就是/chooseSize；u r i / 代 表 访 问 的 是 一 个 目 录 例 如 h t t p : / / l o c a l h o s t : 8200 / c h o o s e S i z e / 那 么 uri/ 代表拜访的是一个目录 例如http://localhost:8200/chooseSize/ 那么uri/代表拜访的是一个目录例如http://localhost:8200/chooseSize/那么uri/就是/chooseSize/；最初/index.html就是咱们首页的地址。最终下面的意思是如果第一个存在，间接返回；不存在的话读取第二个，如果存在，读取返回；如果还是不存在，就会fall back到 try_files 的最初一个选项 /index.html,发动一个外部 “子申请”，也就是相当于 nginx 发动一个 HTTP 申请http://localhost:8200/index.html，再通过前端路由到/chooseSize ...

nginx未应用80，443端口，曾经做了nginx飞80，443端口映射到外网ip的80，443端口 通过指定port_in_redirect off;告知nginx在redirect的时候不要带上port，如果没有配置，默认该值为true如果url结尾是/也不会呈现问题，二层代理时，主动增加斜杠带端口，只须要把 port_in_redirect 设置成 off 就能够解决了

作者：落阳 日期：2020-12-23 在一次我的项目开发中，决定应用docker+nginx+flask+mysql的技术栈来开发，用此系列文章记录开发的过程。 系列文章，以后为第一篇，记录一次python分布式web开发过程。 一、docker的装置作为学生，想找到适合数量的计算机部署分布式系统是一个令人头疼的问题。所以打算在虚拟机上利用docker来部署伪分布式的零碎，不便环境搭建、开发和二次部署。 docker定义如下(摘自百度百科)： Docker 是一个开源的利用容器引擎，让开发者能够打包他们的利用以及依赖包到一个可移植的镜像中，而后公布到任何风行的 Linux或Windows 机器上，也能够实现虚拟化。容器是齐全应用沙箱机制，相互之间不会有任何接口。docker的装置可参见官网:docker官网装置教程 装置实现后，运行上面的命令验证是否装置胜利： docker version# 或者docker infodocker装置实现之后，每一次应用docker命令都须要sudo权限，能够思考把以后用户退出docker用户组或者进入sudo su模式，这里采纳第二种办法。 二、拉取所需的镜像依据采纳的技术栈，目前确定须要拉取的镜像有nginx、python、mysql。 含flask框架的镜像能够在python镜像的根底上制作。 拉取镜像的命令如下: docker pull mysql# 拉取比较稳定的3.8版本的python即可docker pull python:3.8docker pull nginx之后输出命令 docker images即可查看拉取下来的镜像。 三、启动容器因为这个分布式的我的项目须要启动多个容器，所以这里应用了docker-compose来配置和启动多个容器，docker-compose解释如下(摘自菜鸟教程): Compose 是用于定义和运行多容器 Docker 应用程序的工具。通过 Compose，您能够应用 YML 文件来配置应用程序须要的所有服务。而后，应用一个命令，就能够从 YML 文件配置中创立并启动所有服务。windows和mac上在装置docker的同时会一起装置了docker-compose，linux须要额定装置。如果你电脑上有pip的话能够利用pip很容易的装置: pip install docker-compose之后docker-compose命令会默认处于环境变量之下，能够输出 docker-compose --help查看是否装置胜利。 之后就是配置docker-compose.yml文件，对于docker-compose的应用和配置文件的配置教程能够参考https://vuepress.mirror.docker-practice.com/compose/ 目前配置如下: version: "3.2"services: flask1: image: python:3.8 container_name: flask1 restart: always volumes: - /root/myflask/estateProject:/estateProject - /root/myflask/uwsgi1:/uwsgi working_dir: /uwsgi command: /bin/bash -c "pip install -r /estateProject/requirements.txt -i https://pypi.douban.com/simple && uwsgi --ini uwsgi.ini" flask2: image: python:3.8 container_name: flask2 restart: always volumes: - /root/myflask/estateProject:/estateProject - /root/myflask/uwsgi2:/uwsgi working_dir: /uwsgi command: /bin/bash -c "pip install -r /estateProject/requirements.txt -i https://pypi.douban.com/simple && uwsgi --ini uwsgi.ini" nginx: image: nginx container_name: nginx restart: always ports: - "127.0.0.1:8080:80" - "127.0.0.1:8081:443" volumes: - /root/mynginx/html:/usr/share/nginx/html - /root/mynginx/conf:/etc/nginx depends_on: - flask1 - flask2 mysql: image: mysql container_name: mysql restart: always command: --default-authentication-plugin=mysql_native_password networks: my-net: ipv4_address: 172.21.0.2 volumes: - /root/mymysql:/docker-entrypoint-initdb.d environment: - MYSQL_DATABASE=estate_db - MYSQL_ROOT_PASSWORD=123456 networks: my-net: driver: bridge name: my-net ipam: driver: default config: - subnet: 172.21.0.0/16 gateway: 172.21.0.1目前创立了四个容器一个网络。 ...

ingress-nginx设置tcp/udp转发第一步，更改ingress-nginx的deployment启动参数，增加--tcp-services-configmap和--udp-services-configmap参数，开启tcp与udp的反对 containers:- args: - /nginx-ingress-controller - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services - --udp-services-configmap=$(POD_NAMESPACE)/udp-services第二步，更改ingress-nginx的service，申明tcp和udp用的端口号 ports: - name: proxied-tcp nodePort: 30090 port: 9000 protocol: TCP targetPort: 9000 - name: proxied-udp nodePort: 30091 port: 9001 protocol: UDP targetPort: 9001 - name: nginx port: 9005 protocol: TCP targetPort: 9005 第三步，定义configmap，格局为<ingress-controller-svc-port>:"<namespace>/<service-name>:<port>",例如上面配置的data第一行示意将default命名空间下的example-go服务的8080端口映射到ingress-controller service的9000端口，即可通过ingress-controller的service ip加9000端口拜访到example-go服务 apiVersion: v1kind: ConfigMapmetadata: name: tcp-services namespace: ingress-nginxdata: 9000: "default/example-go:8080" 9005: "default/nginx:80"

前言在 Windows 下载安装了 Nginx，配置了环境变量全局应用 Nginx。然而 Nginx 在应用时 conf-path 是依据相对路径来找的（能够依据 nginx -V 命令看进去）。这样的话，你进入 cmd 后，要想启动 Nginx（或者其余管制 Nginx 的命令选项），就必须切换到 Nginx 所在目录，或者在启动时指定 conf-path 的绝对路径，亦或是从新编译 Nginx 来指定 conf-path（Linux 下挺不便，Win也能够），不然 cmd 会报错而无奈启动 Nginx。这样应用起来并不难受，毕竟你要打一大串门路字符：( 。因为不想重编译，于是想了另一种形式——应用 bat 文件。 留神点： 你须要先配置环境变量来全局应用 nginx 这个命令nginx 的命令选项中，除了须要用到配置文件的 start stop reload 等管制命令在非装置门路下应用时会报错外（前言讲到了），其余都可间接应用。比方 nginx -v 查看版本解决方案创立一个 bat 文件（我的是 nginxd.bat），应用 bat 来运行 nginx 命令。创立了之后，就能够应用如下命令： `nginxd [-h,help] [-v,version] [start] [stop] [stop -a] [reload] [reopen] [find]`* 1具体应用 nginxd -h 查看，当然 nginxd 命令依据 bat 文件名来定的。文件地位随便，然而要能全局应用（即指定环境变量）。代码如下： ...

网校研发部--施洪宝 一. 背景介绍1.1 业务背景网校服务正在向K8S迁徙，咱们有两个服务之前是绑定到一台机器上部署的，二者之间通过IP间接拜访，如下图所示， 调用关系非常简单，服务A调用了服务B，这里简略阐明下服务A和服务B， 服务A基于Golang的Gin框架开发，应用Http长连贯拜访服务B服务B基于C++的BRPC开发咱们想把两个服务进行拆分，通过域名拜访。拆分后，拜访链路变成了下图， 在拆分之后，咱们发现服务A呈现了大量的connection reset by peer的谬误，而且这些谬误根本都是集中呈现，呈现的工夫点也没有什么法则，本文是对排查过程的简略总结。 1.2 Tcp Reset简介Tcp发送Reset包有很多种状况，比如说：服务端的全连贯队列已满，无奈承受新的连贯申请；服务端曾经敞开连贯，客户端依然向其发送数据；服务端没有解决完客户端发送的所有数据。还有很多其余的状况，咱们这里就不再一一列举。本文次要介绍其中的2种。 服务端曾经敞开连贯，客户端依然发送数据，这种状况比拟容易模仿，也比拟容易了解。咱们这里介绍下，服务端没有解决完客户端数据的状况。对于客户端发送的数据, 服务端应用层没有读取完, 就敞开了连贯, 服务端会发送Reset。这里是为什么呢？思考之后，不难发现， 这是Tcp可靠性的保障, Tcp须要保障客户端发送的数据, 服务端应用层都能收到，如果服务端应用层没有读取数据，就应该告诉客户端，怎么告诉呢，就是通过Tcp Reset包。上面给出一个简略的示例程序，#include <sys/time.h>#include <stdlib.h>#include <stdio.h>#include <string.h>#include <unistd.h>#include <sys/types.h>#include <sys/socket.h>#include <netinet/in.h>#include <arpa/inet.h>#define PORT 8211int main(int argc, char** argv){ int send_sk = socket(AF_INET, SOCK_STREAM, 0); if(send_sk == -1) { perror("socket failed "); return -1; } struct sockaddr_in s_addr; socklen_t len = sizeof(s_addr); bzero(&s_addr, sizeof(s_addr)); s_addr.sin_family = AF_INET; inet_pton(AF_INET, "127.0.0.1", &s_addr.sin_addr); s_addr.sin_port = htons(PORT); if(connect(send_sk, (struct sockaddr*)&s_addr, len) == -1) { perror("connect fail "); return -1; } char pcContent[1028]={0}; write(send_sk, pcContent, 1028); sleep(1); close(send_sk); return 0;}编译gcc client.c -o client以上是客户端程序, 客户端发送了1028个字节给服务端，期待1s之后，敞开连贯。#include <sys/time.h>#include <stdlib.h>#include <stdio.h>#include <string.h>#include <unistd.h>#include <sys/types.h>#include <sys/socket.h>#include <netinet/in.h>#include <arpa/inet.h>#define PORT 8211#define BACKLOG 10#define MAXRECVLEN 1024int main(int argc, char *argv[]){ char buf[MAXRECVLEN]; int listenfd, connectfd; /* socket descriptors */ struct sockaddr_in server; /* server's address information */ struct sockaddr_in client; /* client's address information */ socklen_t addrlen; if ((listenfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) { perror("socket() error. Failed to initiate a socket"); exit(1); } /* set socket option */ int opt = SO_REUSEADDR; setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); bzero(&server, sizeof(server)); server.sin_family = AF_INET; server.sin_port = htons(PORT); server.sin_addr.s_addr = htonl(INADDR_ANY); if(bind(listenfd, (struct sockaddr *)&server, sizeof(server)) == -1) { perror("Bind() error."); exit(1); } if(listen(listenfd, BACKLOG) == -1) { perror("listen() error. \n"); exit(1); } addrlen = sizeof(client); printf("wait connect\n"); if((connectfd=accept(listenfd,(struct sockaddr *)&client, &addrlen))==-1) { perror("accept() error. \n"); exit(1); } printf("connectfd is %d\n", connectfd); int ans = recv(connectfd, buf, MAXRECVLEN, 0); printf("read data size: %d\n", ans); close(listenfd); /* close listenfd */ return 0;}编译gcc server.c -o server服务端启动后, 期待客户端的连贯。客户端连贯之后，服务端只接管了1024个字节, 就敞开了连贯。1.3 Nginx长连贯的一些设置参数这里给出网关Nginx的一些配置，网关Nginx是1.15.8版本，这里只列了其中一部分配置， ...

Nginx 是最风行的 Web 服务器，能够只占用 2.5 MB 的内存，却能够轻松解决 1w 的 http 申请。 做为网站的入口，Nginx 的平安设置重要性显而易见。 上面带你一起去认识一下这些平安配置吧！ nginx.conf是 Nginx 最次要的配置文件，大部分的平安配置都在这个文件上进行。 禁用不须要的 Nginx 模块主动装置的 Nginx 会内置很多模块，并不是所有的模块都须要，对于非必须的模块能够禁用，如 autoindex module ，上面展现如何禁用 # ./configure --without-http_autoindex_module# make# make install不展现 server tokens默认状况下，Nginx 的 server tokens 会在谬误页面显示 Nginx 的版本号，这可能会导致信息泄露，未经受权的用户可能会理解你应用的nginx版本。 应该在 nginx.conf 通过设置 server_tokens off 来禁用 管制资源和限度为了避免对 Nginx 进行潜在的 DOS 攻打，能够为所有客户端设置缓冲区大小限度，配置如下： client_body_buffer_size 指定客户端申请主体缓冲区的大小。默认值为8k或16k，但倡议将此值设置为低至1k：client_body_buffer_size 1kclient_header_buffer_size 为客户端申请标头指定标头缓冲区大小。 设置为 1k 足以应酬大多数申请。client_max_body_size 为客户端申请指定可承受的最大注释大小。 设置为 1k 应该足够了，然而如果通过 POST办法接管文件上传，则须要减少它。large_client_header_buffers 指定用于读取大型客户端申请标头的缓冲区的最大数量和大小。将最大缓冲区数设置为 2，每个缓冲区的最大大小为 1k。该指令将承受 2 kB 数据， large_client_header_buffers 2 1k禁用所有不须要的 HTTP 办法禁用所有不须要的 HTTP 办法，上面设置意思是只容许 GET、HEAD、POST 办法，过滤掉 DELETE 和 TRACE 等办法。 ...

centos基于nginx制作文档服务器装置须要的根底环境 yum install gcc-c++yum install -y pcre pcre-develyum install -y zlib zlib-develyum install -y openssl openssl-devel官网找到nginx稳固的最新版本 https://nginx.org/en/download.html稳固版本：https://nginx.org/download/nginx-1.18.0.tar.gzcd /homewget -c https://nginx.org/download/nginx-1.18.0.tar.gz解压压缩包数据 tar -zxvf nginx-1.18.0.tar.gzcd nginx-1.18.0配置服务并编译装置 ./configuremakemake install查找nginx配置地位whereis nginx启动进行nginx cd /usr/local/nginx/sbin/./nginx ./nginx -s stop./nginx -s quit./nginx -s reload测试nginx配置是否谬误./nginx -t 查问nginx过程：ps aux|grep nginx设置开机自启动 vi /etc/rc.local#减少一行代码 /usr/local/nginx/sbin/nginx#设置执行权限chmod 755 /etc/rc.local配置文档服务 server { listen 80; server_name localhost; root /home/www/; #charset koi8-r; #access_log logs/host.access.log main; location / { autoindex on; #开启索引性能 autoindex_exact_size off; # 敞开计算文件确切大小（单位bytes），只显示大略大小（单位kb、mb、gb） autoindex_localtime on; # 显示本机工夫而非 GMT 工夫 charset utf-8; # 防止中文乱码 #root html; #index index.html index.htm; }｝重启防火墙设置并凋谢端口限度 ...

handler模块作为第三方开发者咱们最有可能开发的三种类型的模块别离是：handler、filter和load-balancer。配置文件应用location指令能够配置content handler模块，每个handler都有一次机会把本人关联到对应的location上。 模块根本构造大家都晓得Nginx 的配置信息分成了几个作用域(scope,有时也称作上下文)，这就是 main, server, 以及location。同样的每个模块提供的配置指令也能够呈现在这几个作用域里。那对于这三个作用域的配置信息，每个模块就须要定义三个不同的数据结构去进行存储。 typedef struct { int count; //count struct in_addr addr; //ip} ngx_pv_table;模块配置指令 一个模块的配置指令是定义在一个动态数组中的。 struct ngx_command_s { ngx_str_t name; //名称 ngx_uint_t type; //类型例如是main配置还是location配置以及有无参数 char *(*set)(ngx_conf_t *cf, ngx_command_t *cmd, void *conf); //回调函数，解析到该命令之后，执行该函数 ngx_uint_t conf;//是不是http module ngx_uint_t offset;//指定该配置项值的准确寄存地位，个别指定为某一个构造体变量的字段便宜。 void *post;};模块上下文构造 这是一个 ngx_http_module_t 类型的动态变量。这个变量实际上是提供一组回调函数指针，这些函数有在创立存储配置信息的对象的函数，也有在创立前和创立后会调用的函数。这些函数都将被 nginx 在适合的工夫进行调用。 typedef struct { ngx_int_t (*preconfiguration)(ngx_conf_t *cf);//在创立和读取该模块的配置信息之前被调用 ngx_int_t (*postconfiguration)(ngx_conf_t *cf);//在创立和读取该模块的配置信息之后被调用 void *(*create_main_conf)(ngx_conf_t *cf);//调用该函数创立本模块位于 http block 的配置信息存储构造。该函数胜利的时候，返回创立的配置对象。失败的u话，返回 NULL char *(*init_main_conf)(ngx_conf_t *cf, void *conf);//调用该函数初始化本模块位于 http block 的配置信息存储构造。该函数胜利的时候，返回 NGX_CONF_OK。失败的话，返回 NGX_CONF_ERROR 或谬误字符串。 void *(*create_srv_conf)(ngx_conf_t *cf);//调用该函数创立本模块位于 http server block 的配置信息存储构造，每个 server block 会创立一个。该函数胜利的时候，返回创立的配置对象。失败的话，返回 NULL。 char *(*merge_srv_conf)(ngx_conf_t *cf, void *prev, void *conf);//因为有些配置指令既能够呈现在 http block，也能够呈现在 http server block 中。那么遇到这种状况，每个 server都会有本人存储构造来存储该 server 的配置，然而在这种状况下 http block 中的配置与 server block 中的配置信息发生冲突的时候，就须要调用此函数进行合并，该函数并非必须提供，当预计到相对不会产生须要合并的状况的时候，就无需提供。当然为了平安起见还是倡议提供。该函数执行胜利的时候，返回 NGX_CONF_OK。失败的话，返回 NGX_CONF_ERROR 或谬误字符串 void *(*create_loc_conf)(ngx_conf_t *cf);//调用该函数创立本模块位于 location block 的配置信息存储构造。每个在配置中指明的 location 创立一个。该函数执行胜利，返回创立的配置对象。失败的话，返回 NULL。 char *(*merge_loc_conf)(ngx_conf_t *cf, void *prev, void *conf);} ngx_http_module_t;模块定义 ...

nginx架构nginx在启动之后，会有一个master过程和多个worker过程。master过程次要用来治理worker过程，master过程的作用次要在于：承受来着内部的信号（例如reload、quit等信号命令），向各worker过程发送信号，监控各个worker过程的运行状态。 由worker过程来真正解决相应的申请业务。 过程模型： 那么，worker过程又是如何解决申请的呢？每个过程解决申请的机会是相等的，当咱们提供80端口的http服务时，一个连贯申请过去，每个过程都有可能解决这个连贯，这是因为每个worker都是由master fork过去的，并且在fork之前都进行了listen的动作，所以每个worker都领有listenfd，所有的worker过程的listenfd会在新连贯到来的时候变得可读，然而为了保障只有一个过程解决该连贯，所有worker过程会在注册listenfd的读事件的时候抢夺accept_mutex。 采纳这种形式的益处：1. 过程独立，不须要加锁，省掉了锁带来的开销。 2. 绝对于多线程来讲好调试。等等 事件模型: nginx采纳了异步非阻塞的形式来解决申请，这是为什么呢？看看一个残缺的申请过程。首先，申请过去，要建设连贯，而后才是接收数据，再发送数据。具体到零碎底层就是读写事件，而当读写事件没有筹备好时，必然无奈操作，这个时候cpu会阻塞期待，阻塞调用会进入内核期待，cpu就会给他人用了，然而对于单线程的worker来说就不适合了，当网络事件越来越多的时候，大家都在期待io实现，cpu无人应用，这个时候cpu使用率就低下。所以，才会有了异步非阻塞的事件处理机制，具体到零碎调用就是像 select/poll/epoll/kqueue 这样的零碎调用。它们提供了一种机制，让你能够同时监控多个事件，调用他们是阻塞的，但能够设置超时工夫，在超时工夫之内，如果有事件筹备好了，就返回。这种机制正好解决了咱们下面的两个问题，拿 epoll 为例(在前面的例子中，咱们多以 epoll 为例子，以代表这一类函数)，当事件没筹备好时，放到 epoll外面，事件筹备好了，咱们就去读写，当读写返回 EAGAIN 时，咱们将它再次退出到 epoll外面。这样，只有有事件筹备好了，咱们就去解决它，只有当所有事件都没筹备好时，才在epoll 外面等着。这样，咱们就能够并发解决大量的并发了，当然，这里的并发申请，是指未解决完的申请，线程只有一个，所以同时能解决的申请当然只有一个了，只是在申请间进行一直地切换而已，切换也是因为异步事件未筹备好，而被动让出的。这里的切换是没有任何代价，你能够了解为循环解决多个筹备好的事件，事实上就是这样的。与多线程相比，这种事件处理形式是有很大的劣势的，不须要创立线程，每个申请占用的内存也很少，没有上下文切换，事件处理十分的轻量级。并发数再多也不会导致无谓的资源节约（上下文切换）。更多的并发数，只是会占用更多的内存而已。 我之前有对连接数进行过测试，在 24G 内存的机器上，解决的并发申请数达到过 200 万。当初的网络服务器根本都采纳这种形式，这也是 nginx 性能高效的次要起因 nginx基本概念在 nginx 中，每个过程会有一个连接数的最大下限，这个下限与系统对 fd 的限度不一样。在操作系统中，通过 ulimit -n，咱们能够失去一个过程所可能关上的 fd 的最大数，即nofile，因为每个 socket 连贯会占用掉一个 fd，所以这也会限度咱们过程的最大连接数，当然也会间接影响到咱们程序所能反对的最大并发数，当 fd 用完后，再创立 socket 时，就会失败。 nginx 通过设置 worker_connectons 来设置每个过程反对的最大连接数。如果该值大于nofile，那么理论的最大连接数是 nofile， nginx 会有正告。 nginx 在实现时，是通过一个连接池来治理的，每个worker过程都有一个独立的连接池，连接池的大小是worker_connections。这里的连接池外面保留的其实不是实在的连贯，它只是一个 worker_connections 大小的一个ngx_connection_t 构造的数组。并且， nginx 会通过一个链表 free_connections 来保留所有的闲暇 ngx_connection_t，每次获取一个连贯时，就从闲暇连贯链表中获取一个，用完后，再放回闲暇连贯链表外面 。 ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n; if (ngx_use_accept_mutex) { if (ngx_accept_disabled > 0) { ngx_accept_disabled--; } else { if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) { return; } if (ngx_accept_mutex_held) { flags |= NGX_POST_EVENTS; } else { if (timer == NGX_TIMER_INFINITE || timer > ngx_accept_mutex_delay) { timer = ngx_accept_mutex_delay; } } } }那么，咱们后面有说过一个客户端连贯过去后，多个闲暇的过程，会竞争这个连贯，很 容易看到，这种竞争会导致不偏心，如果某个过程失去 accept 的机会比拟多，它的闲暇连贯很快就用完了，如果不提前做一些管制，当 accept 到一个新的 tcp 连贯后，因为无奈失去闲暇连贯，而且无奈将此连贯转交给其它过程，最终会导致此 tcp 连贯得不到解决，就停止掉了。很显然，这是不偏心的，有的过程有空余连贯，却没有解决机会，有的过程因为没有空余连贯，却人为地抛弃连贯。那么，如何解决这个问题呢？首先， nginx 的解决得先关上accept_mutex 选项，此时，只有取得了 accept_mutex 的过程才会去增加 accept 事件，也就是说， nginx 会管制过程是否增加 accept 事件。 nginx 应用一个叫 ngx_accept_disabled 的变量来管制是否去竞争 accept_mutex 锁。在第一段代码中，计算 ngx_accept_disabled 的值，这个值是 nginx 单过程的所有连贯总数的八分之一，减去剩下的闲暇连贯数量，失去的这个ngx_accept_disabled 有一个法则，当残余连接数小于总连接数的八分之一时，其值才大于 0，而且残余的连接数越小，这个值越大。再看第二段代码，当 ngx_accept_disabled 大于 0 时，不会去尝试获取 accept_mutex 锁，并且将 ngx_accept_disabled 减 1，于是，每次执行到此处时，都会去减 1，直到小于 0。不去获取 accept_mutex 锁，就是等于让出获取连贯的机会，很显然能够看出，当空余连贯越少时， ngx_accept_disable 越大，于是让出的机会就越多，这样其它过程获取锁的机会也就越大。不去 accept，本人的连贯就管制下来了，其它过程的连接池就会失去利用，这样， nginx 就管制了多过程间连接的均衡了。 ...

当初有局部用户在建站的时候，根目录下曾经运行了一份程序代码，并且设置了伪动态。为了减少网站的收录量，还会给网站减少站内站的性能。个别没有开发能力的用户，会抉择在一级目录下再依照一个WordPress来作为站内站发一些不太紧要的文章。这里说说如何给装置在一级目录下的WordPress程序设置nginx伪动态规定问题。如果伪动态设置不当的话，会导致网站不能失常关上。要么就是影响到了原来的网站，导致原来网站内页打不开，要么就是影响到了WordPress站点，导致站内站内页打不开，或者设置不当导致内页能关上了，后盾却有打不开了的状况。 这里的配置办法适宜应用nginx作为服务器环境的用户配置，如果你应用的宝塔面板，那么配置起来将更不便。上面以应用宝塔面板来阐明一级目录下装置WordPress的nginx伪动态规定配置办法。没有应用宝塔面板，间接配置nginx.conf也是一样的配置内容，只是操作方法略有不同，须要手动关上nginx.conf，并在批改结束后，手动重启或重载nginx。 WordPress原来的伪动态规定location /{ try_files $uri $uri/ /index.php?$args;}rewrite /wp-admin$ $scheme://$host$uri/ permanent;下面是WordPress装置在根目录下的nginx伪动态配置，然而，如果间接将它当做装置在一级目录下的WordPress应用的话，它是不行的。咱们当初假如曾经装置在根目录下的伪动态是： location /{ try_files $uri $uri/ /index.php?$args;}失常状况下，咱们给源站减少一个站内站，是不能影响网站的失常拜访的，要不然，这么减少就没有意义了。 当初假如咱们的WordPress装置的一级目录为blog，并且曾经装置结束，那么，咱们当初来开始给它配置新的伪动态规定。 一级目录下的WordPress伪动态规定：location /blog { set $need 0; if (!-f $request_filename){ set $need 1; } if ($request_uri ~* admin){ set $need 0; } if ($need = 1) { rewrite (.*) /blog/index.php; } rewrite /blog/wp-admin$ $scheme://$host$uri/ permanent;}为什么要这么写呢？因为如果咱们这里再应用 try_files $uri $uri/ /index.php?$args;，它就会让装置在根目录下的站点无奈失常拜访。而如果咱们间接应用if (!-f $request_filename){ rewrite (.*) /index.php; }，则又会导致装置的一级目录下的后盾无奈失常拜访，因为后盾wp-admin是一个实在存在的目录，是不须要伪动态规定的。因而这里咱们引入了$need 变量，先判断文件是否存在，如果不存在，咱们先标记为$need = 1，再判断门路是不是wp-admin，如果是，则$need = 0，保障rewrite (.*) /blog/index.php;伪动态不会影响到后盾，否则就半途而废了。 ...

定义灰度公布就是已一种平滑过渡的形式来公布，通过切换线上新旧版本之间的路由权重，逐渐从旧版本切换到新版本；比方要上线新性能，首先只是更新大量的服务节点，通过路由权重，让少部分用户体验新版本，如果没有什么问题，再更新所有服务节点；这样能够在呈现问题把影响面降到最低，保障了零碎的稳定性。 灰度公布一个零碎往往有接入层比方nginx(Openresty)，网关层比方zuul，以及服务层比方各种rpc框架；在这几层都有路由性能，也就是说这几层都能够做灰度；接入层能够应用nginx+lua来实现灰度，网关层zuul能够联合ribbon来实现灰度，rpc框架如dubbo自身提供了路由性能能够间接做灰度解决；上面看看具体如何去实现； 接入层灰度接入层咱们这里应用性能更弱小的Openresty，而后应用lua进行路由转发，相干的路由策略能够配置在分布式缓存redis外面，当然也能够长久化到数据库外面； 筹备筹备一台Openresty，两台web服务器tomcat(端口别离是8081，8082)，以及redis；为了不便模仿在redis外面配置白名单，如果在白名单外面就走8082，不在则走8081； Openresty配置须要在Openresty中配置反对lua，以及相干路由的lua脚本，nginx.conf配置如下： http { ... lua_package_path "/lualib/?.lua;;"; #lua 模块 lua_package_cpath "/lualib/?.so;;"; #c模块 upstream tomcat1 { server 127.0.0.1:8081; } upstream tomcat2 { server 127.0.0.1:8082; } server { listen 80; server_name localhost; location / { content_by_lua_file lua/gray.lua; } location @tomcat1 { proxy_pass http://tomcat1; } location @tomcat2 { proxy_pass http://tomcat2; } } ...}配置了所有申请都会通过lua目录下的gray.lua脚本，如下所示： local redis = require "resty.redis";local redis_obj = redis:new();redis_obj:set_timeout(2000);local ok,err = redis_obj:connect("127.0.0.1", 6379);if not ok then ngx.say("failed to connect redis ",err); return;end--获取申请iplocal_ip = ngx.var.remote_addr;--redis中获取白名单local whitelist = redis_obj:get("whitelist");--判断是否在白名单而后转到对应服务if string.find(whitelist,local_ip) == nil then ngx.exec("@tomcat1");else ngx.exec("@tomcat2");endlocal ok,err = redis_obj:close();Openresty内置的功能模块能够间接连贯redis，而后从redis外面取出白名单，看以后的申请ip是否在白名单内，而后做简略的路由性能；能够动静批改redis外面的白名单，实时更新。 ...

计划背景零碎版本：debian9环境搭配：python3 虚拟环境 + fastapi + uvicorn + gunicorn我的项目根目录： /data/wwwroot/domian.com 官网文档中是以 IP:PORT 模式启动 fastapi，但每次都要进虚拟环境通过命令启动 gunicorn，贼麻烦。起初改成 systemd + gunicorn 的形式后，开机主动启动 gunicorn 而且不占用端口。 具体部署 fastapi 另外写文章阐明，本文章只说 nginx + systemd + gunicorn 的配置形式。 大略计划新建以下文件： /etc/systemd/system/gunicorn.service/etc/systemd/system/gunicorn.socketnginx 的 conf 文件中 不必代理 ip:prot 模式，而是代理sock 文件。 具体步骤/etc/systemd/system/gunicorn.service ： [Unit]Description=gunicorn daemonRequires=gunicorn.socketAfter=network.target[Service]Type=notify# the specific user that our service will run asUser=gunicornGroup=www# another option for an even more restricted service is# DynamicUser=yes# see http://0pointer.net/blog/dynamic-users-with-systemd.htmlRuntimeDirectory=gunicorn# WorkingDirectory 是我的项目门路目录WorkingDirectory=/data/wwwroot/domian.com# 代替手动执行的命令，# 本来在虚拟环境中要执行的 gunicorn -c gconfig.py main:app -k uvicorn.workers.UvicornWorker# 其中 gunicorn 和 gconfig.py 要写残缺的门路名称ExecStart=/data/wwwroot/luejiao.com/venv/bin/gunicorn -c /data/wwwroot/luejiao.com/gconfig.py main:app -k uvicorn.workers.UvicornWorkerExecReload=/bin/kill -s HUP $MAINPIDKillMode=mixedTimeoutStopSec=5PrivateTmp=true[Install]WantedBy=multi-user.target/etc/systemd/system/gunicorn.socket ： ...

nginx介绍Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协定下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中体现较好，中国大陆应用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。 特点：1）占用内存少2M左右，咱们的tomcat启动200M左右. 2）并发能力强5万/秒理论2-4万/秒.Nginx装置应用1）启动Nginx nginx启动会生成2个过程项1.主过程次要的作用是提供反向代理服务的.在敞开主过程内存大的.2.守护过程：避免主过程意外敞开的.敞开的时候先敞开守护过程. 2）Nginx命令1.启动命令：windows start nginx Linux ./nginx2.重启命令： nginx -s reload ./nginx -s reload3.敞开命令： nginx -s stop ./nginx -s stop Nginx反向代理原理及配置*注：只能有一个http协定和只能实用于http协定，能够配置多个服务（server）默认的监听端口:80 图片的回显原理： 模仿本地服务器存储图片配置：这个是软件进行HOSTS文件批改： 实现域名代理要求：用户通过http://manage.jt.com拜访local...:8091的服务器.实现形式：利用反向代理机制实现 1）配置nginx confing文件 Nginx实现tomcat集群部署1）集群搭建原理 2）动静展示端口号：在.yml文件中须要提供好端口配置 3）我的项目打包：阐明:因为须要筹备3台tomcat服务器. 所以端口号顺次8081/8082/8083复制war三个文件到同一个文件夹，别离启动拜访.windmove执行的指令： java -jar xxx.war Nginx负载平衡1）轮询策略性能实现：依据文件的配置，顺次拜访服务器.批改配置.conf文件 2）权重策略性能实现：让性能更优的服务器解决更多的用户申请 3）IPHASH策略（不常常用）性能实现：须要将用户与某台服务器进行绑定原理：相似取摸分配机制毛病：1.容易造成负载不均景象.2.如果IP地址与用户绑定在一起，如果tomcat服务器宕机，则间接影响用户. 常利用：IPhash实用场景：个别进行压力测试时实用. Nginx高级属性1）down属性阐明：如果服务器宕机，则能够通过down属性进行标识，被标识的服务器则不会再为用户提供反对. 2）backup属性性能形容：备用机的设定.个别条件下备用机不干活的，然而当主时机忙时，或者主机宕机时，才会拜访备用机. 3）tomcat服务器高可用性能形容：如果人为的增加down属性效率不高，是否主动的检测服务器是否宕机，如果宕机，是否主动的标识为down.

反向代理概念：反向代理服务器位于用户与指标服务器之间，然而对于用户而言，反向代理服务器就相当于指标服务器，即用户间接拜访反向代理服务器就能够取得指标服务器的资源。同时，用户不须要晓得指标服务器的地址，也毋庸在用户端作任何设定。反向代理服务器通常可用来作为Web减速，即应用反向代理作为Web服务器的前置机来升高网络和服务器的负载，进步拜访效率。 特点：1.反向代理服务器是位于用户和指标服务器之间的.2.用户认为反向代理服务器就是实在的服务器.用户不晓得实在服务器到底是谁.3.反向代理服务器爱护服务端信息，称为服务器端代理.为什么须要代理服务器？用户因为某种原因无奈间接拜访指标服务器，实现指定的性能. 正向代理概念：正向代理，意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器获得内容，客户端向代理发送一个申请并指定指标(原始服务器)，而后代理向原始服务器转交申请并将取得的内容返回给客户端。客户端能力应用正向代理。 特点：1.代理服务器位于用户与服务器之间.2.用户申请时，十分明确指标服务器到底是谁.服务器不分明到底是谁拜访的我.认为是代理服务器间接发动的申请.3.正向代理服务器爱护了用户的信息，所以称之为客户端代理. 总结：1）反向代理是服务器端代理，只有用户拜访服务器，其实都是反向代理机制，实现业务调用.2）正向代理是客户端代理，次要用户上网就应用正向代理实现的是网络通信头.

▣ 博主主站地址：微笑涛声 【www.cztcms.cn】▣ 博主其余平台： CSDN 简书 开源中国 思否 华为云博客华为云鲲鹏云服务器搭载的是华为鲲鹏处理器（916/920）,华为鲲鹏处理器是基于ARM架构的处理器，不同于传统的X86架构的处理器。不过Nginx能够间接用yum命令进行装置。 1、间接应用 yum命令进行装置。yum install nginx -y 2、启动Nginx，查看运行状态。systemctl start nginxsystemctl status nginx 3、在浏览器拜访公网IP，呈现此页面证实Nginx装置胜利。 4、进入Nginx的配置文件目录。cd /etc/nginx 5、查看nginx.conf文件。vim nginx.conf

1、Nginx配置：nginx.conf 在配置文件中减少配置： 2、Docker启动时设置端口映射 将宿主机上的8000端口映射到docker上的8001端口 docker run -d -p 8000:8001 -it docker-registry.company.virtual/username/test:0.1 /bin/bash3、查看docker服务映射的端口 netstat -ltunp | grep docker 查看宿主机端口与docker端口映射状况（图片能够看到，宿主机的8001端口映射到了docker8000端口） docker ps

一、nginx缓存的长处 如图所示，nginx缓存，能够在肯定水平上，缩小源服务器的解决申请压力。 因为动态文件（比方css，js， 图片）中，很多都是不常常更新的。 nginx应用proxy_cache将用户的申请缓存到本地一个目录。下一个雷同申请能够间接调取缓存文件，就不必去申请服务器了。 毕竟，IO密集型服务的解决是nginx的强项。 二、如何进行设置先上个栗子： http{ proxy_connect_timeout 10; proxy_read_timeout 180; proxy_send_timeout 5; proxy_buffer_size 16k; proxy_buffers 4 32k; proxy_busy_buffers_size 96k; proxy_temp_file_write_size 96k; proxy_temp_path /tmp/temp_dir; proxy_cache_path /tmp/cache levels=1:2 keys_zone=cache_one:100m inactive=1d max_size=10g; server { listen 80 default_server; server_name localhost; root /mnt/blog/; location / { } #要缓存文件的后缀，能够在以下设置。 location ~ .*.(gif|jpg|png|css|js)(.*) { proxy_pass http://ip地址:90; proxy_redirect off; proxy_set_header Host $host; proxy_cache cache_one; proxy_cache_valid 200 302 24h; proxy_cache_valid 301 30d; proxy_cache_valid any 5m; expires 90d; add_header wall "hey!guys!give me a star."; } } # 无nginx缓存的blog端口 server { listen 90; server_name localhost; root /mnt/blog/; location / { } }}复制代码因为我是在一台服务器上做试验(敲重点，做试验)，所以用了两个端口80和90进行模仿两台服务器之间的交互。 ...

参考网上泛滥文档： https://www.cnblogs.com/kaid/p/7640723.html nginx下载地址：https://nginx.org/en/download.html 查看环境：一. gcc 装置装置 nginx 须要先将官网下载的源码进行编译，编译依赖 gcc 环境，如果没有 gcc 环境，则须要装置： yum install gcc-c++二. PCRE pcre-devel 装置PCRE(Perl Compatible Regular Expressions) 是一个Perl库，包含 perl 兼容的正则表达式库。nginx 的 http 模块应用 pcre 来解析正则表达式，所以须要在 linux 上装置 pcre 库，pcre-devel 是应用 pcre 开发的一个二次开发库。nginx也须要此库。命令： yum install -y pcre pcre-devel三. zlib 装置zlib 库提供了很多种压缩和解压缩的形式， nginx 应用 zlib 对 http 包的内容进行 gzip ，所以须要在 Centos 上装置 zlib 库。 yum install -y zlib zlib-devel四. OpenSSL 装置OpenSSL 是一个弱小的安全套接字层明码库，囊括次要的明码算法、罕用的密钥和证书封装治理性能及 SSL 协定，并提供丰盛的应用程序供测试或其它目标应用。 ...

反向代理反向代理服务器位于用户与指标服务器之间，然而对于用户而言，反向代理服务器就相当于指标服务器，即用户间接拜访反向代理服务器就能够取得指标服务器的资源。同时，用户不须要晓得指标服务器的地址，也毋庸在用户端作任何设定。反向代理服务器通常可用来作为Web减速，即应用反向代理作为Web服务器的前置机来升高网络和服务器的负载，进步拜访效率。 特点:1.反向代理服务器位于用户与指标服务器之间2.对于用户而言,认为代理服务器就是实在的服务器.3.反向代理机制爱护了实在的服务器信息.4. 反向代理个别称之为服务端代理. 步骤:1.当用户发动申请时,该申请被代理服务器拦挡.2.代理服务器查问本人的配置文件,依据url地址获取实在的服务器信息.3.由代理服务器依据实在的服务器信息,获取数据.4.实在的服务器接管申请之后,将数据返回给代理服务器.5.代理服务器接管到服务器数据之后,将数据回传给用户,本次代理完结. 正向代理正向代理阐明正向代理，意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器获得内容，客户端向代理发送一个申请并指定指标(原始服务器)，而后代理向原始服务器转交申请并将取得的内容返回给客户端。客户端能力应用正向代理。 特点:1.代理服务器位于用户与实在服务器之间的2.客户十分分明本人拜访的服务到底是谁?3.服务器不分明拜访本人的服务器到底是谁,认为只是代理服务器拜访.4.正向代理称之为客户端代理.爱护了客户的信息 NginxNginx服务器介绍Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点（俄文：）开发的，第一个公开版本0.1.0公布于2004年10月4日。其将源代码以类BSD许可证的模式公布，因它的稳定性、丰盛的功能集、示例配置文件和低系统资源的耗费而闻名。2011年6月1日，nginx 1.0.4公布。 Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协定下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中体现较好，中国大陆应用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。 特点:1.占用内存少 不超过2M2.并发能力强 5万/秒 tomcat 150-220个/秒3.开发语言 C语言 Nginx下载 nginx装置启动: 首先右键以管理员身份运行,之后程序闪退示意服务器启动失常. 查看Nginx服务启动项nginx启动时,会启动2个过程项,其中一个1.主过程 次要为用户提供反向代理服务 占用内存大2.守护过程 避免主过程意外敞开的. 占用内存小的 启动失常测试 NGINX入门案例阐明配置文件阐明http{ #必须在http协定之内进行配置 server{ listen 80; server_name "监听域名地址"; location / { root "反向代理的是一个目录"; } } server{.....}}NGINX实现图片回显编辑Nginx.conf文件#配置图片代理服务器 http://image.jt.com:80 server { listen 80; server_name image.jt.com; location / { root D:/JT-SOFT/images; } }nginx命令目录: 在nginx的根目录中执行 命令: 1.启动命令 start nginx2.重启命令 nginx -s reload3.进行命令 nginx -s stop编辑hosts文件（能够应用SwitchHosts）介绍: HOSTS文件是操作系统为了不便开发,在本地造成的一个域名与IP的映射的文件. 然而该文件只对本机无效.地位: C:WindowsSystem32driversetchosts ...

Ubuntu18.04配置nginx呈现的各种谬误短少pcre库编译nginx 呈现谬误 装置pcre库，呈现谬误 手动编译装置pcre库 （1）下载并解压pcre库 wget https://ftp.pcre.org/pub/pcre/pcre-8.43.tar.gztar -xvf pcre-8.43.tar.gz （2）编译装置pcre库 cd pcre-8.43sudo ./configuresudo makesudo make install从新编译nginx #在nginx-1.12.2目录下sudo ./configure --with-stream命令执行胜利 呈现"struct crypt_data"没有名为"current_salt"成员的谬误 执行make命令 sudo make && make install呈现"struct crypt_data"没有名为"current_salt"成员的谬误 解决方案：进入相应门路，将源码的第36行正文 sudo vi src/os/unix/ngx_user.c 从新执行sudo make && make install命令 呈现-Werror=cast-function-type谬误 解决方案 #进入nginx-1.12.2目录下的objs目录cd objs#批改Makefile文件sudo vi Makefile 从新回到nginx-1.12.2目录下执行sudo make && make install命令 make命令呈现权限不够谬误 进入root模式执行命令 sudo su #进入root模式make && make installnginx启动呈现无奈连贯pcre库谬误 查看依赖库 到/usr/local/lib目录下查看 ...

很早之前就有看nginx的激动，然而始终被一些事耽误着，最近在忙碌之中，抽出点工夫，看了下Nginx代码，发现整体上并不是很难看懂，而且刚好想学习nginx+lua开发。 nginx 在互联网公司应用很广，最重要的性能当属反向代理和负载平衡了吧，当然还有缓存。所以有必要对 nginx 相熟应用和深刻理解。 记得我之前在很多文章有提到，后盾组件框架次要有三种：redis单过程单线程，memcache单过程多线程，nginx多过程；等看了nginx之后，我也算集齐了。 nginx以模块化形式开发，比方外围模块，event模块，http模块，而后为了反对多平台，event模块下又有对各大平台的封装反对，例如linux平台epoll，mac平台kqueue等等；而后http模块也被拆分成了很多子模块。 这篇文章算是我本人做的笔记吧，把之前钻研的货色记录下。 兴许是之前看过redis 和 golang 以及 python的 http 框架，nginx整体框架比拟容易就看懂了，当然很多细节还需前面缓缓看。 这篇文章次要介绍 nginx 是如何开启，以及申请是怎么执行的，所以这篇文章次要就是以下两点： nginx开启流程;重要回调函数设置；nginx解决http申请；总结1. nginx开启流程nginx体量很大，想要在较短时间内看完所有代码很难，而且我看得工夫也不是很多，所以，这里次要站在宏观角度，对nginx做个整体分析。 其实如果间接从main函数间接开始看，其实也是能够看懂大部分，然而 nginx 回调函数太多了，看着看着，忽然跑出一个回调函数，常常就懵逼了。 因而，就须要用gdb来定点调试； 要应用gdb，首先须要在gcc编译时，退出-g选项，能够如下操作： 关上nginx目录/auto/cc/conf文件，而后更改ngx_compile_opt=”-c”选项，增加-g，即为ngx_compile_opt=”-c -g”;而后运行./configure和make即可编译生成可执行文件，在文件objs目录下;生成可执行文件nginx之后，间接在终端运行即可，nginx会加载默认配置文件，以daemon模式运行; nginx运行之后，即可通过gdb来调试;  按如下命令开启gdb 而后，通过pidof命令获取nginx过程号，即可attach，如下： nginx默认开启一个master过程和一个worker过程，因而上述命令会返回两个过程号，在我主机上8125和8126，较小是master过程，较大的是worker过程；接下来，先看下master过程， 这样就能够间接调试nginx的worker过程，用命令bt能够查看master过程的函数栈 nginx开启之后，首先启动的就是master过程，从main函数开始， main函数次要是做一些初始化操作，初始化启动参数，开启daemon，新建pid文件等等，而后调用ngx_master_process_cycle函数；在ngx_master_process_cycle函数中最重要就是开启子过程，而后调用sigsuspend函数，master过程则阻塞在在信号中；因而，master过程工作就是开启子过程，而后治理子过程；怎么治理了？ 信号，对，就是信号；当master过程收到一个信号之后，就把这个信号传递给worker过程，worker过程进而依据不同信号别离解决。 那么问题又来了，master过程是如何把信号传递给worker过程的？ 管道，对，就是管道。原理和memcache的master线程和worker线程通信机制一样，即每个worker过程有两个文件描述符fd[0]和fd[1]，一个读端，一个写端； worker过程将读端退出epoll事件监听，当master过程收到一个信号后，在每个worker过程写端写入一个flag，而后worker过程触发读事件，读取flag，并依据flag做相应操作。 因而nginx接管客户端申请以及解决客户端申请，次要是在worker过程，咱们来看下，worker过程函数栈 因为 worker 过程是由 master 过程 fork 进去，因而 worker 过程蕴含 master 过程的函数栈；咱们间接从#5函数开始看， ngx_start_worker_processes 函数调用ngx_spawn_process开启子过程，并且设置master过程和worker过程通信的管道；ngx_spawn_process函数次要是设置master过程和worker过程间通信管道，例如非阻塞等等，而后通过fork函数正式开启子过程；子过程调用通过参数传递进来的回调函数ngx_worker_process_cycle正式切入子过程局部，父过程则接着设置worker过程相干属性； ngx_worker_process_cycle 一开始调用 ngx_worker_process_init 函数对worker 过程做些初始化设置，包含设置过程优先级，worker过程容许关上的最大文件描述符，对阻塞信号的设置，初始化所有模块，将master过程和worker过程间通信管道增加到监听可读事件等等；而后在一个有限循环中，函数ngx_worker_process_cycle接着调用ngx_process_events_and_timers，开启事件监听循环； 在ngx_process_events_and_timers 函数中，先是获取锁，如果获取到锁，listenfd 即可接管客户端，否则 listenfd 不可接管客户端事件；而后调用ngx_process_events函数，这个函数也就是ngx_epoll_process_events函数，开启开启事件监听； ...

作者：学而思网校-黄桃 http1.1与http1.0最大的区别是什么？答案是http1.1协定是默认开启keep-alive的，如图http1.1的申请头： 那什么是keepalive？作用是什么？keepalive是在TCP中一个能够检测死连贯的机制，能够放弃tcp长连贯不被断开，属于tcp层性能。http协定应用keepalive放弃长连贯，次要作用是进步对tcp连贯的复用率，缩小创立连贯过程给零碎带来的性能损耗。 TCP层怎么做到放弃长连贯的呢？先看keepalive的用法：有三个参数，凋谢给应用层应用： 1. sk->keepalive_probes：探测重试次数，超过次数则close连贯；2. sk->keepalive_time 探测的心跳距离，TCP连贯在距离多少秒之后未进行数据传输,则启动探测报文；3. sk->keepalive_intvl 探测距离，发送探活报文，未收到回复时，重试的工夫距离；linux系统对这三个参数有默认配置，查看：[***@*** ~]$ $ cat/proc/sys/net/ipv4/tcp_keepalive_time300[***@*** ~]$ cat /proc/sys/net/ipv4/tcp_keepalive_intvl75[***@*** ~]$ cat /proc/sys/net/ipv4/tcp_keepalive_probes9应用层应用示例：int keepalive = 1; // 开启keepalive属性int keepidle = 60; // 如该连贯在60秒内没有任何数据往来,则进行探测int keepinterval = 5; // 探测时发包的工夫距离为5 秒int keepcount = 3; // 探测尝试的次数。如果第1次探测包就收到响应了,则后2次的不再发。并且清零该计数setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepalive , sizeof(keepalive ));setsockopt(rs, SOL_TCP, TCP_KEEPIDLE, (void*)&keepidle , sizeof(keepidle ));setsockopt(rs, SOL_TCP, TCP_KEEPINTVL, (void *)&keepinterval , sizeof(keepinterval ));setsockopt(rs, SOL_TCP, TCP_KEEPCNT, (void *)&keepcount , sizeof(keepcount ));应用层这么设置后，会把Linux默认配置笼罩，走手动设置的配置。 ...

上手下载http://nginx.org/en/download.html 而后解压到某个门路下 启动cmd进入nginx目录下例如我是解压到E盘，那么我的nginx的路劲是 E:\nginx-1.19.0window 下启动nginx start nginx 或者双击nginx.exe 拜访localhost:80 如果无法访问，查看80端口是否被占用 敞开nginxnginx目录下 ./nginx.exe -s stop罕用apiroot默认依据路是html文件夹下拜访locahost/a/index.html时，查找的就是html目录下a/index.html location /a { root html; index index.html index.htm;~~~~ }将根目录批改为html/helpcenter拜访localhost/a/index.html时，查找的就是html/helpcenter/a/index.html location /a { root html/helpcenter/; index index.html index.htm; }alias同样的配置，拜访localhost/a/index.html时，寻找的是html/helpcenter/index.html location /a { alias html/helpcenter/; index index.html index.htm; }listen监听多个端口，对应同样的逻辑 server { listen 8000; listen 8080; location / { root html; index index.html index.htm;}监听多个端口，对应不同的逻辑 server { listen 8000; location / { root html; index index.html index.htm;}server { listen 8001; location / { root html/a/; index index.html index.htm;}try_files语法： ...

李乐 引子 咱们为什么须要学习Nginx呢？高性能，高稳固，优雅的模块化编程等就不提了，就说一个理由：Nginx是目前最受欢迎的web服务器，据统计，寰球均匀每3个网站，就有一个应用Nginx。如果你不懂Nginx，日常很多工作可能都无奈发展。 比方，最近看到过这么一句话："Nginx master过程接管到客户端申请，转发给worker过程解决"。如果你不懂Nginx，就有可能也闹出相似的笑话。 比方，当你须要搭建一套webserver时，可能根本的一些配置都一头雾水。location匹配规定你分明吗，正则匹配、最大前缀匹配和准确匹配的程序以及优先级你能记得住吗？反向代理proxy_pass以及fastcgi_pass你晓得怎么配置吗？限流负载平衡等基本功能又怎么配置呢？一大堆配置有时真的让人脑仁疼。 比方，线上环境Nginx曾呈现"no live upstreams"。顾名思义，Nginx认为所有上游节点都挂掉了，此时Nginx间接向客户端返回502，而不会申请上游节点。这时候你该想想，Nginx是根据什么判断上游节点都挂掉了？呈现这种谬误后，Nginx又是怎么复原的呢？ 再比方，线上环境高峰期Nginx还呈现过这种谬误："Resource temporarily unavailable"，对应的错误码是EAGAIN。非阻塞读写socket遇到EAGAIN不是通常稍等再尝试吗？其实通过源码里的一句正文就能霎时明确了："Linux returns EAGAIN instead of ECONNREFUSED for unix sockets if listen queue is full"。原来如此，Nginx和FPM之间是通过域套接字建设连贯的，监听队列满了，零碎间接返回的是EAGAIN，而不是咱们平时理解的ECONNREFUSED；而Nginx在发动连贯connect时，如果返回EAGAIN间接完结申请返回502。 本篇文章旨在让你对Nginx可能有个零碎的意识，理解其外围性能的实现思路，以及如何切入Nginx源码的学习。在遇到问题时，至多让你直到能够去哪寻找你想要的答案。次要波及以下几个方面: 如何开始Nginx源码的学习；模块化编程；master与worker过程模型；Nginx事件驱动模型；HTTP解决流程之11个阶段；location匹配规定；upstream与负载平衡；proxy_pass;fastcgi_pass与FPM；限流；案例剖析：502问题剖析。如何开始Nginx源码的学习 作为一名初学者，如何去上手浏览Nginx源码呢？这还不简略，从main办法动手，一行一行看呗。如何你这么做了，也保持了一段时间，我给你点个赞，至多我是做不到的。不过，我置信大部分人是保持不了几天的。数十万行Nginx源码，岂是短时间就能钻研透的？如果长时间都没有获得显著功效，大多数人都会抉择放弃吧。 我个别是怎么浏览源码的呢？ 1）入手GDB，入手GDB，入手GDB；重要的话说三遍； 逻辑比拟艰涩，各种判断分支太简单，回调handler不晓得是什么。GDB调试其实真的很简略，b打断点，p命令看变量名称，bt命令看调用栈，c继续执行至下一个断点，n执行到下一行。笔者个别罕用的也就这几个命令。 2）带着问题去浏览，最好能带着答案去浏览。 带着问题去浏览，就有了一条主线，只须要关注你须要关注的。比方Nginx是一个事件驱动程序，那么第一个问题就是去摸索他的事件循环，事件循环中无非就是通过epoll_wait()期待事件的产生，而后执行事件回调handler。其余逻辑都可不用过多关注。 有了答案，你就能更容易的切入到源码中，去摸索他的实现思路。去哪里寻找答案呢？官网的开发者指南就比拟具体的介绍了Nginx诸多性能的实现细节 ，包含代码布局介绍，根本数据结构介绍，事件驱动模型介绍，HTTP解决流程基本概念介绍等等。通过这些介绍咱们就能失去一些问题的答案。比方，事件循环的切入点是ngx_process_events_and_timers()函数，那你是不是就能在这个函数打断点，跟踪事件循环执行链路（http://nginx.org/en/docs/dev/...）。 配置不明确，也能够查看官网文档 ，留神配置是依照模块分类的。咱们以配置"keepalive_timeout"为例，官网文档有很分明的介绍，http://nginx.org/en/docs/http... 。 英文难以浏览怎么办？还是尽量浏览官网文档吧，更新及时，准确性高。或者，Nginx作为目前应用最宽泛的web服务器，网络上相干博客文档也是十分多的，搜寻"Nginx 事件循环"，立即就能失去你想要的答案。不过须要留神的是，网络上找到的答案，无奈保障正确性，最好本人验证下。 3）从点，到线，再到面，再到点 同样的以事件循环为例，你从官网文档或者博客失去切入点是函数ngx_process_events_and_timers()，只有这一点信息怎么办？全局搜寻代码，查看该函数的调用链路，比方我通过understand能够很容易得出其调用链，如下图： 从一个切入点，你就能失去一条执行链路；一直的去摸索新的问题，逐渐你就能把握了整个零碎。 待你对整个零碎有了肯定理解，还须要再度回归到具体的点上。毕竟，第一阶段浏览源码时，因为整体的把握度不够，跳过了很多实现细节。 比方，事件构造体ngx_event_s包含数十个标识类字段，当初都没有深究具体含意；比方，当我配置了N多个location匹配规定时，Nginx是从头到尾一个个遍历匹配吗？效率是不是长处低呢？比方，Nginx的多过程模型，master过程是如何治理以及监控work过程的，Nginx的平滑降级又是怎么实现的？过程间通信以及信号处理你理解吗？再比方，Nginx通过锁来解决多个worker的惊群效应，那么锁的实现原理是什么呢？ 模块化编程 在学习Nginx源码之前，最好理解一下其模块块编程思维。一个模块实现一个小小的性能，所有模块组合成了弱小的Nginx。比方下表几个功能模块： 模称性能ngx_epoll_module基于epoll的事件处理模块ngx_http_limit_req_module按申请qps限流ngx_http_proxy_module按HTTP协定转发申请到上游ngx_http_fastcgi_module按fastcgi协定转发申请到上游ngx_http_upstream_ip_hash_moduleiphsh负载平衡………… Nginx模块被划分为几大类，比方外围模块NGX_CORE_MODULE，事件模块NGX_EVENT_MODULE，HTTP模块NGX_HTTP_MODULE。构造体ngx_module_s定义了Nginx模块，咱们重点须要关注这几个（类）字段： ...

nginx指定多个域名跨域申请配置什么是跨域 假如咱们页面或者利用已在 http://www.test1.com 上了，而咱们打算从 http://www.test2.com 申请提取数据。个别状况下，如果咱们间接应用 AJAX 来申请将会失败，浏览器也会返回“源不匹配”的谬误，"跨域"也就以此由来。跨域的呈现次要起因还是平安的限度(同源策略，也就是JavaScript或者Cookie只可能拜访同域下的内容)，因而在日常的我的项目开发中会不可避免的呈现跨域操作。 和打少数跨域的解决方案一样，JSONP是大多数前端共事的抉择，然而JSONP只反对GET申请。然而如果我的项目性能须要改成反对POST申请,那么因为这种状况下传输的数据量较大，GET模式是搞不定的。此时JSONP并不是一个很好的抉择。此时就须要应用CORS(跨域资源共享，Cross-Origin Resource Sharing). 个别跨域会呈现的问题 一般来说，跨域会呈现如下的问题： 理论我的项目中呈现的问题 先前配置中有如下的域名： browser.in.meizu.com是向客户端或者是H5提供接口拜访的后盾域名，browser-res.in.meizu.com,v-res.in.meizu.com都是提供给h5端的入口拜访域名。 先前在nginx中有如下的配置： 如果设置了这个配置，那么如果前端的入口是browser-res.in.meizu.com,那么它是能够拜访到browser.in.meizu.com提供的接口的。 前端同学用了v-res.in.meizu.com这个域名作为h5端拜访入口，拜访browser.in.meizu.com，因为此时nginx并没有相干的配置，因而呈现了如下的问题： 很显著,这个问题并不是说原程序没有设置"add_header Access-Control-Allow-Origin:"。 咱们看后面的nginx中的 配置，曾经设置了 browser-res.in.meizu.com 能够拜访 browser.in.meizu.com。然而当初的一个问题是前端的同 学应用了 "v-res.in.meizu.com" 这个域名作为前端的入口,所以就呈现了以上的问题：browser-res.in.meizu.com是 能够拜访browser.in.meizu.com。然而v-res.in.meizu.com不能够拜访browser.in.meizu.com.然而过后思考问题只是 认为是简略的跨域问题,没有思考到在nginx中的配置,所以就简略的应用了过滤器来进行解决. /** 跨域拜访时容许对服务端提交申请过滤器@author liguo@date 2017-12-31* */ public class CrossDomainFilter implements Filter { @Override public void init(FilterConfig filterConfig) throws ServletException { } @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { //跨域拜访转换 ...

问题将Springboot利用部署到服务器上 通过域名拜访swagger-ui（通过了Nginx代理） 进行前后端联调 然而理论点击执行的时候 提醒： TypeError: Failed to fetch 如 swagger-ui拜访地址是： https://foo.com/test/api/insurance/swagger-ui/index.html点击执行 调用后端接口的地址 变成了 http://foo.com:80/solvStaInfos因为通过Nginx代理 理论后端地址应该是 https://foo.com/test/api/insurance/solvStaInfos解决swagger-ui页面上地址取自接口：/v3/api-docs中的返回 servers: [ { url: "http://foo.com:80", description: "Inferred Url" }],批改此地址为https://foo.com/test/api/insurance即可 办法一Nginx动静批改接口返回内容 location /test/api/insurance/v3/api-docs { sub_filter 'http://foo.com:80' 'https://foo.com/test/api/insurance/'; sub_filter_types application/json; proxy_pass ...;}注： 须要Nginx反对 即蕴含对应的module 办法二代码层面批改 @Componentpublic class SpringfoxSwaggerHostResolver implements WebMvcOpenApiTransformationFilter { @Override public OpenAPI transform(OpenApiTransformationContext<HttpServletRequest> context) { OpenAPI swagger = context.getSpecification(); Server server = new Server(); server.setUrl("https://foo.com/test/api/insurance/"); swagger.setServers(Arrays.asList(server)); return swagger; } @Override public boolean supports(DocumentationType delimiter) { return DocumentationType.OAS_30.equals(delimiter); }}

前言事实证明，读过Linux内核源码的确有很大的益处，尤其在解决问题的时刻。当你看到报错的那一瞬间，就能把景象/起因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的景象都能很快的反馈过去是为何。笔者读过一些Linux TCP协定栈的源码，就在解决上面这个问题的时候有一种十分晦涩的感觉。 Bug现场首先，这个问题其实并不难解决，然而这个问题引发的景象倒是挺有意思。先形容一下景象吧， 笔者要对自研的dubbo协定隧道网关进行压测(这个网关的设计也挺有意思，筹备放到前面的博客外面)。先看下压测的拓扑吧: 为了压测笔者gateway的单机性能，两端仅仅各保留一台网关，即gateway1和gateway2。压到肯定水平就开始报错，导致压测进行。很天然的就想到，网关扛不住了。 网关的状况去Gateway2的机器上看了一下，没有任何报错。而Gateway1则有大量的502报错。502是Bad Gateway，Nginx的经典报错，首先想到的就是Gateway2不堪重负被Nginx在Upstream中踢掉。 那么，就先看看Gateway2的负载状况把，查了下监控，发现Gateway2在4核8G的机器上只用了一个核，齐全看不出来有瓶颈的样子，难道是IO有问题？看了下小的可怜的网卡流量打消了这个猜测。 Nginx所在机器CPU利用率靠近100%这时候，发现一个有意思的景象,Nginx确用满了CPU! 再次压测，去Nginx所在机器上top了一下，发现Nginx的4个Worker别离占了一个核把CPU吃满-_-! 什么，号称性能强悍的Nginx居然这么弱，说好的事件驱动epoll边际触发纯C打造的呢？肯定是用的姿态不对！ 去掉Nginx间接通信毫无压力既然猜想是Nginx的瓶颈,就把Nginx去掉吧。Gateway1和Gateway2直连，压测TPS外面就飙升了，而且Gateway2的CPU最多也就吃了2个核，毫无压力。 去Nginx上看下日志因为Nginx机器权限并不在笔者手上，所以一开始没有关注其日志，当初就分割一下对应的运维去看一下吧。在accesslog外面发现了大量的502报错，的确是Nginx的。又看了下谬误日志，发现有大量的 Cannot assign requested address 因为笔者读过TCP源码，一瞬间就反馈过去，是端口号耗尽了！因为Nginx upstream和后端Backend默认是短连贯，所以在大量申请流量进来的时候回产生大量TIME_WAIT的连贯。 而这些TIME_WAIT是占据端口号的，而且根本要1分钟左右能力被Kernel回收。 cat /proc/sys/net/ipv4/ip_local_port_range32768 61000 也就是说，只有一分钟之内产生28232(61000-32768)个TIME_WAIT的socket就会造成端口号耗尽，也即470.5TPS(28232/60),只是一个很容易达到的压测值。事实上这个限度是Client端的,Server端没有这样的限度，因为Server端口号只有一个8080这样的有名端口号。而在 upstream中Nginx表演的就是Client,而Gateway2就表演的是Nginx 为什么Nginx的CPU是100%而笔者也很快想明确了Nginx为什么吃满了机器的CPU,问题就进去端口号的搜寻过程。 让咱们看下最耗性能的一段函数: int __inet_hash_connect(...){ // 留神，这边是static变量 static u32 hint; // hint有助于不从0开始搜寻，而是从下一个待调配的端口号搜寻 u32 offset = hint + port_offset; ..... inet_get_local_port_range(&low, &high); // 这边remaining就是61000 - 32768 remaining = (high - low) + 1 ...... for (i = 1; i <= remaining; i++) { port = low + (i + offset) % remaining; /* port是否占用check */ .... goto ok; } .......ok: hint += i; ......} 看下面那段代码，如果始终没有端口号可用的话，则须要循环remaining次能力宣告端口号耗尽，也就是28232次。而如果依照失常的状况，因为有hint的存在，所以每次搜寻从下一个待调配的端口号开始计算，以个位数的搜寻就能找到端口号。如下图所示: 所以当端口号耗尽后，Nginx的Worker过程就沉迷在上述for循环中不可自拔，把CPU吃满。 ...

Nginx 以其高性能，稳定性，丰盛的性能，简略的配置和低资源耗费而闻名。本文从底层原理剖析 Nginx 为什么这么快！ Nginx 的过程模型 Nginx 服务器，失常运行过程中： 多过程：一个 Master 过程、多个 Worker 过程。 Master 过程：治理 Worker 过程。对外接口：接管内部的操作（信号）；对内转发：依据内部的操作的不同，通过信号治理 Worker；监控：监控 Worker 过程的运行状态，Worker 过程异样终止后，主动重启 Worker 过程。 Worker 过程：所有 Worker 过程都是平等的。理论解决：网络申请，由 Worker 过程解决。Worker 过程数量：在 nginx.conf 中配置，个别设置为外围数，充分利用 CPU 资源，同时，防止过程数量过多，防止过程竞争 CPU 资源，减少上下文切换的损耗。 思考： 申请是连贯到 Nginx，Master 过程负责解决和转发？ 如何选定哪个 Worker 过程解决申请？申请的处理结果，是否还要通过 Master 过程？ HTTP 连贯建设和申请处理过程 HTTP 连贯建设和申请处理过程如下： Nginx 启动时，Master 过程，加载配置文件。 Master 过程，初始化监听的 Socket。 Master 过程，Fork 出多个 Worker 过程。 Worker 过程，竞争新的连贯，获胜方通过三次握手，建设 Socket 连贯，并解决申请。 ...

Nginx是Apache服务不错的替代品。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中体现较好，因而国内出名大厂例如：淘宝，京东，百度，新浪，网易，腾讯等等都在应用Nginx网站。 在咱们的日常工作学习中，咱们会该如何去优化本人的Nginx服务器？遇到以下问题咱们该如何解决呢？ 一、如何自定义返回给客户端的404谬误页面1）优化前，客户端应用浏览器拜访不存在的页面，会提醒404文件未找到 [root@client ~]# firefox http://192.168.4.5/xxxxx        //拜访一个不存在的页面2）批改Nginx配置文件，自定义报错页面 [root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf.. ..    charset utf-8;               //仅在须要中文时批改该选项error_page   404  /404.html;    //自定义谬误页面.. ..[root@proxy ~]# vim /usr/local/nginx/html/404.html      //生成谬误页面Oops,No NO no page …[root@proxy ~]# nginx -s reload#请先确保nginx是启动状态，否则运行该命令会报错,报错信息如下：#[error] open() "/usr/local/nginx/logs/nginx.pid" failed (2: No such file or directory)3）优化后，客户端应用浏览器拜访不存在的页面，会提醒本人定义的40x.html页面 [root@client ~]# firefox http://192.168.4.5/xxxxx    //拜访一个不存在的页面常见的http状态码可用参考表所示 二、如何查看服务器状态信息（十分重要的性能）1）编译装置时应用--with-http_stub_status_module开启状态页面模块 [root@proxy ~]# tar  -zxvf   nginx-1.12.2.tar.gz[root@proxy ~]# cd  nginx-1.12.2[root@proxy nginx-1.12.2]# ./configure   > --with-http_ssl_module                        //开启SSL加密性能> --with-stream                                //开启TCP/UDP代理模块> --with-http_stub_status_module                //开启status状态页面[root@proxy nginx-1.12.2]# make && make install    //编译并装置2）启用Nginx服务并查看监听端口状态 ss命令能够查看零碎中启动的端口信息，该命令罕用选项如下： -a显示所有端口的信息-n以数字格局显示端口号-t显示TCP连贯的端口-u显示UDP连贯的端口-l显示服务正在监听的端口信息，如httpd启动后，会始终监听80端口-p显示监听端口的服务名称是什么（也就是程序名称）留神：在RHEL7零碎中能够应用ss命令代替netstat命令，性能一样，选项一样。 [root@proxy ~]# /usr/local/nginx/sbin/nginx[root@proxy ~]# netstat  -anptu  |  grep nginxtcp        0        0 0.0.0.0:80        0.0.0.0:*        LISTEN        10441/nginx[root@proxy ~]# ss  -anptu  |  grep nginx3）批改Nginx配置文件，定义状态页面 [root@proxy ~]# cat /usr/local/nginx/conf/nginx.conf… …location /status {                stub_status on;                 #allow IP地址;                 #deny IP地址;        }… …[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload4）优化后，查看状态页面信息 [root@proxy ~]# curl  http://192.168.4.5/statusActive connections: 1 server accepts handled requests 10 10 3 Reading: 0 Writing: 1 Waiting: 0Active connections：以后流动的连贯数量。Accepts：曾经承受客户端的连贯总数量。Handled：曾经解决客户端的连贯总数量。（个别与accepts统一，除非服务器限度了连贯数量）。Requests：客户端发送的申请数量。Reading：以后服务器正在读取客户端申请头的数量。Writing：以后服务器正在写响应信息的数量。Waiting：以后多少客户端在期待服务器的响应。三、优化Nginx并发量1）优化前应用ab高并发测试 [root@proxy ~]# ab -n 2000 -c 2000 http://192.168.4.5/Benchmarking 192.168.4.5 (be patient)socket: Too many open files (24)                //提醒关上文件数量过多2）批改Nginx配置文件，减少并发量 [root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf.. ..worker_processes  2;                    //与CPU外围数量统一events {worker_connections 65535;        //每个worker最大并发连接数}.. ..[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload3）优化Linux内核参数（最大文件数量） [root@proxy ~]# ulimit -a                        //查看所有属性值[root@proxy ~]# ulimit -Hn 100000                //设置硬限度（长期规定）[root@proxy ~]# ulimit -Sn 100000                //设置软限度（长期规定）[root@proxy ~]# vim /etc/security/limits.conf    .. ..*               soft    nofile            100000*               hard    nofile            100000#该配置文件分4列，别离如下：#用户或组    硬限度或软限度    须要限度的我的项目   限度的值4）优化后测试服务器并发量（因为客户端没调内核参数，所以在proxy测试） [root@proxy ~]# ab -n 2000 -c 2000 http://192.168.4.5/四、优化Nginx数据包头缓存1）优化前，应用脚本测试长头部申请是否能取得响应 [root@proxy ~]# cat lnmp_soft/buffer.sh #!/bin/bashURL=http://192.168.4.5/index.html?for i in {1..5000}do    URL=${URL}v$i=$idonecurl $URL                                //通过5000次循环后，生成一个长的URL地址栏[root@proxy ~]# ./buffer.sh.. ..<center><h1>414 Request-URI Too Large</h1></center>        //提醒头部信息过大2）批改Nginx配置文件，减少数据包头部缓存大小 [root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf.. ..http {client_header_buffer_size    1k;        //默认申请包头信息的缓存    large_client_header_buffers  4 4k;        //大申请包头部信息的缓存个数与容量.. ..}[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload3）优化后，应用脚本测试长头部申请是否能取得响应 [root@proxy ~]# cat buffer.sh #!/bin/bashURL=http://192.168.4.5/index.html?for i in {1..5000}do    URL=${URL}v$i=$idonecurl $URL[root@proxy ~]# ./buffer.sh五、浏览器本地缓存静态数据1）应用Firefox浏览器查看缓存 以Firefox浏览器为例，在Firefox地址栏内输出about:cache将显示Firefox浏览器的缓存信息，如图所示，点击List Cache Entries能够查看详细信息。2）清空firefox本地缓存数据，如图所示。3）改Nginx配置文件，定义对动态页面的缓存工夫 [root@proxy ~]# vim /usr/local/nginx/conf/nginx.confserver {        listen       80;        server_name  localhost;        location / {            root   html;            index  index.html index.htm;        }location ~* .(jpg|jpeg|gif|png|css|js|ico|xml)$ {expires        30d;            //定义客户端缓存工夫为30天}}[root@proxy ~]# cp /usr/share/backgrounds/day.jpg /usr/local/nginx/html[root@proxy ~]# /usr/local/nginx/sbin/nginx -s reload#请先确保nginx是启动状态，否则运行该命令会报错,报错信息如下：#[error] open() "/usr/local/nginx/logs/nginx.pid" failed (2: No such file or directory)4）优化后，应用Firefox浏览器拜访图片，再次查看缓存信息 [root@client ~]# firefox http://192.168.4.5/day.jpg在firefox地址栏内输出about:cache，查看本地缓存数据，查看是否有图片以及过期工夫是否正确。 起源：https://blog.csdn.net/mage_li...

什么是IO？简略来说就是输入输出网络IO经验步骤用户在获取网络资源是在进入网卡，通过网络七层模型将申请交给nginx用户过程用户过程无奈间接获取磁盘上的资源，会将申请获取什么资源翻译并转发给内核，内核驱动磁盘寻道找到文件（最耗时间的环节）文件同样也不能间接交给用户过程，首先磁盘将文件放至内核缓冲区，而后内核告知用户过程申请的资源后果已筹备好（耗时比拟短）内核缓冲区将文件拷贝一份至用户过程缓冲区，用户过程拿到文件 构建响应报文，通过http回传给用户 总结： IO总共要经验两个阶段 1.磁盘读取数据，将数据拷贝至内核缓冲区 2.将内核缓冲区数据拷贝至用户过程缓冲区 网络IO模型品种同步阻塞 比方你要去实现这样一件事件，把水烧开，灌入暖瓶 当初给你一口一般的锅，你也不晓得水什么时候能够烧开，你决定守在旁边期待水开。 这个时候的你是什么也做不了的，是不是感觉很浪费时间 当水开了就须要你把水灌入暖瓶，你还是做不了其余的事件 同步非阻塞 比方还是烧一锅开水，你还是不晓得水什么时候会开，你抉择了另外一个策略，去忙其它的事件然而要时不时看下谁开没开 改良了什么呢？ 你能够在空挡工夫忙其它的事件 减少了什么麻烦呢？ 你得时不时的确认水开没开(就意味着得不停的调用cpu，占用cpu资源）可能你上一次刚看的时候水没开，等你刚看完水开了，那就得等下一次查看的时候能力发现，减少了提早，等你晓得了水开了，本人去把水灌好 Linuxc/c++服务器开发高阶视频学习材料+qun720209036获取 更多视频内容包含C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，MongoDB，ZK，流媒体，P2P，K8S，Docker，TCP/IP，协程，DPDK多个高级知识点分享。 异步阻塞 这个就比拟二了 如果给你一个智能热水壶，水开了会主动的揭示你的，然而你还是要傻傻的等 齐全没有利用好智能热水壶的劣势（不做解释） 同步异步：关注的是音讯的告诉机制 阻塞非阻塞：关注的是在收到后果之前调用者的状态是期待还是忙本人的事件 IO多路复用 还拿烧水的例子 不要你来管水开没开，间接交给一个代理，如果代理名叫select，select在那帮你监控水开没开，捎带他还会看饭有没有煮好，你把所有的事件都交代给它，能够去忙本人的事件了在饭还没熟，水还没开的时候select就处于一个期待的状态，如果这个时候水开了select会水开了的后果写到一个小黑板你能够看到并晓得水开了，不须要你去查看水开没开，接下来由你将烧开的水灌进暖瓶（用户过程前半部分不阻塞，后半部份阻塞） select、poll、epoll的区别 无论是select、poll、epoll都能够面对多个用户过程的申请，它相当于一个代理人，收集很多用户过程的申请，他帮你从磁盘上获取数据，复制到内核中，那么这个数据筹备没筹备好它的实现机制是不一样的 告诉形式：假如有一个用户数据筹备好了，那么还有很多用户数据还没有筹备好，那么如何告诉？ select和poll是遍历扫描，效率低下 epoll采纳回调机制，epoll会被动告诉，效率更高（nginx反对） 信号驱动IO 举例：比方咱们的智能热水壶我么设定好烧水当前，会给你一个反馈后果为设定胜利，而后你就能够去忙其余的事件了，等到水烧开了会发给你一条短息，这个时候你再回去把水灌入暖瓶 告诉机制： 程度触发：屡次告诉 边缘触发：只告诉一次

NginxNginx命令1.启动命令 start nginx2.重启命令 nginx -s reload3.进行命令 nginx -s stop编辑Nginx.conf文件http{ #必须在http协定之内进行配置 server{ listen 80; server_name "监听域名地址"; location / { root "反向代理的是一个目录"; } } server{.....}}#配置图片代理服务器 http://image.jt.com:80 server { listen 80; server_name image.jt.com; location / { root D:/JT-SOFT/images; } }编辑hosts文件hosts文件门路：C:Windows/System32/drivers/etc/hosts #IP 域名 映射关系127.0.0.1 image.jt.com127.0.0.1 manage.jt.com127.0.0.1 www.jt.com127.0.0.1 sso.jt.com127.0.0.1 localhost实现域名的代理批改Nginx.conf文件 server{ listen 80; server_name manage.jt.com; location / { #代理实在服务器地址 proxy_pass http://localhost:9080; } }负载平衡轮询策略阐明: 依照nginx.conf中配置文件的程序顺次拜访. #配置商品后盾服务器 server{ listen 80; server_name manage.jt.com; location / { #代理实在服务器地址 #proxy_pass http://localhost:9080; #映射到集群 proxy_pass http://jtWindows; } } #配置Tomcat服务器集群 ，默认为 轮询策略 upstresm jtWindows{ server 127.0.0.1:9080; server 127.0.0.1:9081; server 127.0.0.1:9082; }权重策略阐明: 因为公司的物理服务器可能性能有高有低,为了让高性能的服务器解决更多的数据. ...

1. Nginx装置步骤1.1 官网介绍Nginx官网 1.2 上传安装包上传到指定目录 /usr/local/src 1.3 解压Nginx压缩文件 1.挪动装置目录到指定文件 mv nginx-1.19.4.tar.gz software/2.批改文件名称 mv nginx-1.19.4 nginx1.4 对于nginx目录阐明 1.5装置nginx服务器阐明:在源文件中执行如下命令 ./configure 间接后果: 2. make 3. make install 1.6 nginx命令阐明阐明:nginx工作目录阐明 命令: 1.windows命令: 1.启动命令: start nginx 2.重启命令: nginx -s reload 3.敞开命令: nginx -s stop 2.Linux命令 1.启动命令: ./nginx 2.重启命令: ./nginx -s reload 3.敞开命令: ./nginx -s stop1.7 批改nginx配置文件 需要阐明:1.实现图片反向代理2.实现tomcat负载平衡实现 具体实现:批改实现之后,重启nginx服务器. #配置图片代理服务器 http://image.jt.com:80 server { listen 80; server_name image.jt.com; location / { #root D:/JT-SOFT/images; root /usr/local/src/images; } } #配置商品后盾服务器 server{ listen 80; server_name manage.jt.com; location / { #代理实在服务器地址 #proxy_pass http://localhost:8091; #映射到集群 #proxy_pass http://jtWindows; proxy_pass http://jtLinux; } } #配置tomcat服务器集群 1.默认 轮询策略 2.权重策略 3.ip_hash策略 upstream jtWindows { #ip_hash; down 标识宕机 backup 备用机 #max_fails=1 示意最大的失败次数 #fail_timeout=60s 如果拜访不通,则在60秒内,不会再次拜访故障机 server 127.0.0.1:8081 max_fails=1 fail_timeout=60s; server 127.0.0.1:8082 max_fails=1 fail_timeout=60s; server 127.0.0.1:8083 max_fails=1 fail_timeout=60s; } upstream jtLinux { server 192.168.126.129:8081; server 192.168.126.129:8082; server 192.168.126.129:8083; }1.8 批改hosts文件阐明:因为没有购买image/manage.jt.com的域名,所以须要通过hosts文件批改转向批改windows中的hosts文件 ...

日志的重要性显而易见，可我仿佛齐全疏忽了它，导致往往呈现什么问题，第一工夫并不是去看日志。 很显然我齐全漠视了它的弱小性，就拿 nginx 的拜访日志来说，能够从中剖析出如下信息： 申请的响应工夫申请达到的后端服务器的地址和端口申请是否存在缓存配置申请体、申请头、响应体和响应头的大小等客户端的IP 地址、UserAgent 等信息自定义变量的内容通过这些信息，能够失去响应耗时的申请以及申请量和并发量，从而剖析并发起因，这对于利用级别的服务来说是十分重要的。 GoAccess 是什么GoAccess 是一个开源的实时网络日志分析器和交互式查看器，能够在类 Unix 零碎中的终端或通过浏览器运行。 —— GoAccess 官网 为什么抉择 GoAccess？因为GoAccess 被设计成一个基于终端的疾速日志分析器。它的核心思想是实时疾速剖析和查看Web服务器统计信息，而无需应用浏览器。同时也能够将输出到HTML 或者 CSV、JSON。GoAccess简直能够解析任何Web日志格局（Apache，Nginx，Amazon S3，Elastic Load Balancing，CloudFront等）。只须要设置日志格局并依据您的日志运行它。GoAccess 入门昨天在应用 GoAccess 时，踩到了一些坑，导致我一度认为这个工具是不是存在什么Bug。因为在看他人的教程中都是开箱即用。 上面从装置到应用会一一具体阐明。 装置 GoAccess因为服务器的操作系统是 Ubuntu，所以这里以 Ubuntu为例： 因为并非所有发行版都提供最新版本的 GoAccess，所以这里应用官网提供的最新稳定版的装置形式 $ echo "deb http://deb.goaccess.io/ $（lsb_release -cs）main" | sudo tee -a /etc/apt/sources.list.d/goaccess.list$ wget -O - https://deb.goaccess.io/gnugpg.key | sudo apt-key add - $ sudo apt-get update$ sudo apt-get install goaccess确定日志格局在计算机装置了GoAccess 之后，要做的第一件事件就是确定拜访日志的日志格局，能够在永恒设置它们，也能够通过命令行传递他们。 这里用Nginx 的 access.log 为例 ...

user root;worker_processes 1;#error_log logs/error.log;#error_log logs/error.log notice;#error_log logs/error.log info;#pid logs/nginx.pid;events { worker_connections 1024;}http { include mime.types; # gzip on; # gzip_types text/plain text/css application/json application/javascript application/x-javascript text/javascript text/xml application/xml application/rss+xml application/atom+xml application/rdf+xml; # 负载平衡 # upstream mysite.com { # server localhost:8081; # server localhost:8082; # server localhost:8083; # server localhost:8084; # server localhost:8085; # hash $request_uri; # } server { listen 8080; server_name localhost; # hash mode location / { root /srv/; index index.html; } # history mode # location / { # root /srv/; # try_files $uri $uri/ /index.html; # } # api proxy # location ^~ /api/ { # 留神开端的"/" # proxy_pass http://mysite.com/; # 留神开端的"/" # } # socket proxy # location ^~ /socket/ { # proxy_pass http://mysite.com/socket/; # proxy_http_version 1.1; # proxy_set_header Upgrade $http_upgrade; # proxy_set_header Connection "upgrade"; # } } # 负载平衡 # server { # listen 8081; # server_name localhost; # location / { # proxy_pass http://ip1.com; # } # } # server { # listen 8082; # server_name localhost; # location / { # proxy_pass http://ip2.com; # } # }}

nginx踩坑一1.电脑系统 windows10专业版2.在开发的过程中,咱们常常会应用到nginx,上面是我遇到的一些问题,心愿对你有所帮忙!3.在应用nginx的时候,咱们启动了nginx之后,发现应用命令:nginx.exe -s stop命令会提醒报错!4.cmd 输出命令 netstat -ano 如图 找到nginx监听端口的pid,效果图如下:5.通过cmd 命令tasklist|findstr "PID" 能够 找到监听端口的过程,如果你有很多个过程,这样的办法就很麻烦!倡议应用 6。6.的确发现有nginx服务在运行 通过cmd命令 taskkill /f /t /im nginx.exe 完结过程 后果如图:7.最初拜访http://192.168.137.63:8010 失败 阐明nginx服务被胜利进行,效果图如下:8.本期的分享到了这里就完结啦,是不是很nice,心愿对你有所帮忙,让咱们一起致力走向巅峰!

nginx配置1.开发环境 vue+node2.电脑系统 windows10专业版3.在应用我的项目开发的过程中,咱们常常会应用nginx进行转发,上面我我的总结,心愿对你有所帮忙!4.nginx官网下载地址: http://nginx.org/en/download.html//本次应用的版本是:1.18.05.下载之后,咱们会失去这样的一个目录构造:5-1.咱们次要配置的是,如下图:5-2.conf文件夹上面的nginx.conf代码如下: #user nobody;worker_processes 1;#error_log logs/error.log;#error_log logs/error.log notice;#error_log logs/error.log info;#pid logs/nginx.pid;events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; server { listen 8010; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; location / { root G:/chendistmo/dist; index index.html index.htm; # proxy_pass http://192.168.137.63:3000; } location /api { proxy_pass http://192.168.137.63:3000; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # #location ~ \.php$ { # root html; # fastcgi_pass 127.0.0.1:9000; # fastcgi_index index.php; # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; # include fastcgi_params; #} # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #} } # another virtual host using mix of IP-, name-, and port-based configuration # #server { # listen 8000; # listen somename:8080; # server_name somename alias another.alias; # location / { # root html; # index index.html index.htm; # } #} # HTTPS server # #server { # listen 443 ssl; # server_name localhost; # ssl_certificate cert.pem; # ssl_certificate_key cert.key; # ssl_session_cache shared:SSL:1m; # ssl_session_timeout 5m; # ssl_ciphers HIGH:!aNULL:!MD5; # ssl_prefer_server_ciphers on; # location / { # root html; # index index.html index.htm; # } #}}5-3.咱们须要批改的中央,如下图: ...

nginx设置index.html不缓存因为我的项目都是工程化打包，所以每次发包，除了index.html，其余文件的后缀都是带MD5串的。此时要在nginx设置不缓存index.html，防止浏览器拜访的是旧的文件，导致脚本文件404history模式路由路由采纳history模式时，须要nginx配置路由try_files $uri /index.html;因为我的项目只有一个html，然而每拜访一个门路都会寻找对应门路下的html，找不到，就让他找根目录下的

场景介绍本文介绍如何在半小时内，通过阿里云容器ACK服务和文件存储NAS服务搭建一个简略的弹性、高可用NGINX网站。在实现本文的所有操作后，您将取得一个单网页的网站，用户的申请将会被打散到多个容器节点上，并且依据业务负载主动扩缩容，即便某个容器节点宕机也不会影响用户拜访。另外您还能够将本地编辑的网页疾速更新到网站上。 背景常识本教程应用到的云产品如下： 云服务器ECS 云服务器（Elastic Compute Service，简称ECS）是阿里云提供的性能卓越、稳固牢靠、弹性扩大的IaaS（Infrastructure as a Service）级别云计算服务。云服务器ECS免去了您洽购IT硬件的后期筹备，让您像应用水、电、天然气等公共资源一样便捷、高效地应用服务器，实现计算资源的即开即用和弹性伸缩。阿里云ECS继续提供创新型服务器，解决多种业务需要，助力您的业务倒退。 文件存储NAS 阿里云文件存储（Network Attached Storage，简称 NAS）是面向阿里云 ECS 实例、E-HPC 和容器服务等计算节点的文件存储服务。NAS 提供了简略的可扩大文件存储以供与 ECS 配合应用，多个ECS实例能够同时拜访 NAS 文件系统，并且存储容量会随着您增加和删除文件而主动弹性增长和膨胀，为在多个实例或服务器上运行的工作负载和应用程序提供通用数据源。 容器服务Kubernetes版 阿里云容器服务Kubernetes版ACK（Alibaba Cloud Container Service for Kubernetes）是寰球首批通过Kubernetes一致性认证的服务平台，提供高性能的容器利用治理服务，反对企业级Kubernetes容器化利用的生命周期治理，让您轻松高效地在云端运行Kubernetes容器化利用。 本教程七个步骤，实现前五个步骤即可实现弹性高可用的NGINX网站，最初两个步骤验证网站的弹性和高可用属性。 步骤一：创立资源步骤二：挂载文件系统NAS到ECS服务器步骤三：上传文件到NAS步骤四：配置NAS挂载信息步骤五：创立NGINX利用步骤六：拜访测试网站步骤七：验证服务高可用步骤八：验证弹性扩缩容 步骤一：开启体验云产品资源体验地址：https://developer.aliyun.com/... 开启云产品资源 步骤二：挂载文件系统NAS到ECS服务器阿里云文件存储NAS是一个可共享拜访，弹性扩大，高牢靠，高性能的分布式文件系统。它能够为容器提供长久化的存储服务。在接下来的操作里，您的网页文件将会被保留在NAS文件系统中，当容器pod被创立后即可间接调用NAS里的文件，并且在pod被销毁后，NAS里的文件也会持续留存。1.应用资源提供的子账号（能够应用浏览器的无痕模式），登录NAS文件系统控制台。2.单击左侧疏导栏文件系统列表，而后单击文件系统 ID进入文件系统详情页。3.单击挂载应用，查看挂载点信息，复制挂载命令。4.关上终端工具，在终端中输出连贯命令ssh [username]@[ipaddress]。您须要将其中的username和ipaddress替换为资源提供的的ECS服务器的公网IP。例如： ssh root@123.123.123.123命令显示后果如下：5.在终端中执行以下命令，挂载NAS到ECS服务器。装置NFS客户端。 sudo yum install nfs-utils执行第3步中复制的挂载命令，挂载NAS到ECS的/mnt目录。 sudo mount -t nfs -o vers=3,nolock,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 3******7.cn-shanghai.nas.aliyuncs.com:/ /mnt步骤三：上传文件到NAS应用ACK集群搭建NGINX服务后，在您关上网站首页时，容器就会从NAS文件系统中读取这一步上传的网页文件，返回给浏览器。在网站搭建实现后，您能够通过同样的办法更新NAS里的文件。1.在本地创立index.html文件。 Windows零碎：关上文本编辑器，输出test index page for nginx-nas-demo，而后保留文件类型为HTML文件。MacOS或Linux：关上命令行工具，而后执行以下命令即可。mkdir -p ~/Documents/nginx-nas-demoecho "test index page for nginx-nas-demo" > ~/Documents/nginx-nas-demo/index.html2.下载并装置SFTP客户端，例如：FileZilla。3.上传index.html文件到NAS。 双击运行FileZila。依据以下信息，连贯服务器。主机：资源提供的ECS公网IP。用户名：root明码：资源提供的ECS明码。端口：22。在左侧目录树找到本地创立的index.html文件，在右侧目录树输出/mnt，进入NAS目录。将左侧区域的index.html拖拽到右侧区域，即可将本地文件上传到NAS。4.您能够应用步骤二的形式近程连贯到ECS，在/mnt目录中查看刚上传的index.html文件。 步骤四：配置NAS挂载信息要应用ACK服务挂载应用NAS，须要先配置容器存储卷PV和存储申明PVC信息，这些信息将会在您部署NGINX利用的时候用到。1.配置存储卷。进入ACK集群列表，单击ACK集群名称，进入集群详情页。单击左侧疏导栏中的存储卷。单击存储卷标签页，而后单击创立。抉择NAS存储卷类型，填写存储卷名称，抉择NAS挂载点，最初单击创立。操作流程参见如下图。图1：图2：2.配置存储申明。 ...

编程是门手艺，NGINX社区的教训分享 一文提过，业余的程序员善于整体设计和细节解决能力。本文探讨整体设计，尤其是模块化这个技能。 全能蠢才，Fabrice BellardFFmpeg，最弱小的流媒体库 QEMU，硬件虚拟化的虚拟机 TCC，迷你CC编译器 QuickJS，100%反对JS语法的C引擎 等等，以上皆出自一人之手，法国蠢才。 去年QuickJS曾一度刷爆技术圈，NGINX社区的哥们第一工夫举荐给我看，并以蠢才称他。 这软件开辟了我的视线。本文以它为引子探讨我认为十分重要的技能：如何组织代码。 NJS，实现语言引擎真难私下问过Fabrice Bellard（给QJS提过patch）开发QJS的历程，答案令人惊叹，他只用了两年的业余时间。参加NJS这几年，才深知实现语言引擎有多简单。 NJS从17年开始，当初差不多实现40%。但根底曾经十分良好，后续性能开发会疾速很多。而且罕用性能都曾经反对，其中我反对了模块化，箭头函数，等罕用的。语言解析引入了LL(k)。 看似做了些不错的工作。然而跟QJS比，以台球打个比方。一个长距离很准的选手，90%的球都能打进，看似很厉害。但对一个发力十分厉害的人来说，他可能只需80%的准度，再加良好的走位，就能轻松一杆清台。 提QJS不是不可一世，这样比照很不偏心。QJS作者自身就是个JS专家，他都能用JS实现虚拟机。参加NJS的人员，包含Igor都不是真正的JS语法里手，JS的语法着实太宏大。咱们平时开发过程中，有个社区外的JS里手对咱们帮忙十分大，几乎就是JS活字典。因而在后期，只能靠着语法手册，而后实现，有些实现跟语法的实质有出入的话，又得重头再来。举个例子，晚期实现的apply和call两个语法真是让人吃尽了苦头，这也是我最早参加的，因为修复它的bug，做了重构，而后发现社区的人十分承受这种重构的做法，有种碰到知音的感觉。 QuickJS，五万行代码一个文件的软件我会解释这种做法是正当的。此时必须提出来，前面再详加解释。 模块化，最好的代码组织形式我在参加NJS时，第一件事就是让它反对模块化编程。NJS刚进去时我就开始关注，前面挺长一段时间，用NJS写代码只能放在一个文件里，这对代码组织是极不敌对的。先看下JS的模块化用法：main.js /* 自定义模块 */import foo from 'foo.js';foo.inc();/* 内置模块 */import crypto from 'crypto';var h = crypto.createHash('md5');var hash = h.update('AB').digest('hex');foo.js var state = {count:0}function inc() { state.count++;}function get() { return state.count;}export default {inc, get}反对模块化之后，变得十分好用。这个大性能也是NGINX作者Igor亲自帮review和调整的，播种良多。主观讲，JS语法比Lua切实好用太多，NJS目前曾经十分稳固，只是性能没那么繁多，举荐轻量利用思考用NJS，而且社区十分沉闷，置信将来可期。 当初轻瞥一下QuickJS的源码。 JSContext *JS_NewContext(JSRuntime *rt){ JSContext *ctx; ctx = JS_NewContextRaw(rt); if (!ctx) return NULL; JS_AddIntrinsicBaseObjects(ctx); JS_AddIntrinsicDate(ctx); JS_AddIntrinsicEval(ctx); JS_AddIntrinsicStringNormalize(ctx); JS_AddIntrinsicRegExp(ctx); JS_AddIntrinsicJSON(ctx); JS_AddIntrinsicProxy(ctx); JS_AddIntrinsicMapSet(ctx); JS_AddIntrinsicTypedArrays(ctx); JS_AddIntrinsicPromise(ctx); return ctx;}void *JS_GetContextOpaque(JSContext *ctx){ return ctx->user_opaque;}void JS_SetContextOpaque(JSContext *ctx, void *opaque){ ctx->user_opaque = opaque;}所有源代码扔进一个文件里，我看过不少软件的源码，而且是比拟残缺的。NGINX, Unit, NJS, Lua等，以集体感观而言，QuickJS是最好的。初看有点凌乱，但细看的话（可能须要很相熟JS语法），相对的巨匠之作。 如果想删除某个语法性能，在QuickJS里能够间断的从某行始终删除到另一行，间断的一块。这在其它软件是不可能做到的，要么多个文件都要删除，要么在一个文件也要删除多个不同的中央。我认为这就是模块化的精华：高内聚。 学过设计准则的同学想必都晓得软件要高内聚，低耦合。我的了解是只有做到了高内聚，低耦合就是自然而然的事件。 举个例子，要实现nginx lua模块。有两个重要的性能：nginx模块相干函数，lua封装相干函数。 适度设计形式： ...

实用手册：https://wizardforcel.gitbooks... 1 nginx根底操作1.1 nginx装置# yum疾速装置yum -y install pcre pcre-devel zlib zlib-devel openssl openssl-devel# 编译装置wget http://nginx.org/download/nginx-1.14.1.tar.gztar -zxvf nginx-1.14.1.tar.gz./configure --prefix=/usr/local/nginx \--with-http_stub_status_module \--with-http_gzip_static_module\--with-http_realip_module\--with-http_sub_module \--with-http_ssl_module\--with-http_realip_module \--with-http_sub_module \--with-http_gunzip_module\--with-http_gzip_static_module\--with-http_auth_request_module\--with-http_random_index_module \--with-http_slice_module \--with-http_stub_status_modulemake && make install# 查看加载的模块及版本信息nginx -V1.2 nginx常用命令# 查看Nginx的版本号nginx -V# 进行nginx -s stop# 退出 nginx -s quit# 重启加载配置 nginx -s reload# 配置文件启动nginx -c </path/to/config> # </path/to/config> 为 Nginx 指定一个配置文件，来代替缺省的# 不运行，而仅仅测试配置文件nginx -t# nginx 将查看配置文件的语法的正确性，并尝试关上配置文件中所援用到的文件。1.3 nginx管制信号再次回过头看看nginx的原理图，咱们还能够通过信号去操作nginx，默认状况下nginx将其主过程的pid写入到/usr/local/nginx/nginx.pid文件中。 # nginx 进行命令，等所有申请完结后敞开服务。（从容敞开）Kill -QUIT nginx 主过程号# 从新载入配置。用新的配置开始新的工作过程，从容敞开旧的工作过程kill -HUP nginx 主过程号# 疾速敞开kill -TERM nginx 主过程号# 或kill -INT nginx 主过程号# 从新关上日志文件kill -USR1 nginx 主过程号# 平滑降级可执行程序kill -USR2 nginx 主过程号# 从容敞开工作过程kill -WINCH nginx 主过程号2 nginx配置阐明2.1 根底配置阐明配置语法阐明： ...

创立ssl证书 $ mkdir -p /etc/nginx/ssl $ cd /etc/nginx/ssl $ openssl genrsa -idea -out server.key 1024 $ openssl req -new -key server.key -out server.csr $ openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt留神要加过期工夫，默认的有效期很短Nginx 配置 $ cd /etc/nginx/conf.d $ vim https.conf输出以下内容 server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; server_name _; root /usr/share/nginx/html; ssl_certificate "/etc/nginx/ssl/server.crt"; ssl_certificate_key "/etc/nginx/ssl/server.key"; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_ciphers PROFILE=SYSTEM; ssl_prefer_server_ciphers on; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } }保留退出并重启nginx ...

跨域这个话题曾经谈了很多年了，怎么当初又要谈这个问题？原本是能够不用再提了的，然而因为Chrome 86版本当前又减少了很多限度，导致咱们不得不再次提起。 CORS对于前端开发来说，跨域通常有两种形式，一种是在服务端批改nginx配置，在response headers里增加CORS设置，另一种是在本地架设代理。咱们先谈第一种。 本来在nginx里增加CORS曾经是一种惯例操作，简略到变本加厉： location /somewhere/ { if ($request_method = OPTIONS) { add_header Access-Control-Allow-Origin "$http_origin"; add_header Access-Control-Allow-Credentials "true"; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS"; add_header Access-Control-Allow-Headers "sitessubid,Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,Keep-Alive,X-Requested-With,If-Modified-Since"; add_header Content-Length 0; add_header Content-Type text/plain; return 200; } if ($request_method = POST) { add_header Access-Control-Allow-Origin "$http_origin"; add_header Access-Control-Allow-Credentials "true"; } }而后咱们只有在每个axios或者fetch申请里增加withCredentials就能主动把对应该服务器的cookies随申请一并发送了。 但问题在Chrome 86版本当前，Chrome强制给从服务端下发的每个cookie都减少了一个缺省的SameSite属性，并且强制把这个属性设置为Lax，从而导致咱们的withCredentials不起作用，只有是跨域的状况，cookies连取都取不到，更不要提发送了。在这里我不想再详述SameSite的原理，感兴趣的能够去这里理解。 这就须要咱们必须从服务端动手，批改nginx下发cookies时的SameSite属性。 SameSite和secure批改SameSite又分为两种状况：如果你用的是低版本的nginx，可能还不肯定能齐全解决问题，目前惟一能批改的变通之道是批改cookie的path，使它前面带上SameSite属性，例如这样： proxy_cookie_path ~(.*) "$1; SameSite=none";这里理论批改的是cookie里的path值，但因为附加了;，所以浏览器会认为自;当前的是新属性，所以也会承受这个SameSite设定。 然而仅此还不够，Chrome又要求如果SameSite值为none的话，则还必须设置secure属性，也就是要求所有下发cookie的域名必须应用https协定，所以最终批改的后果是： proxy_cookie_path ~(.*) "$1; SameSite=none; secure";但这种状况只能解决相似于cookie是以path结尾的状况，如果上游服务器下发cookie时不止有path，并且在path结尾指定了其它的SameSite，那就无能为力了，因为这么批改path之后cookie会变成： path=/; SameSite=none; secure; SameSite=Lax浏览器依然以最初一个SameSite=Lax为准。目前低版本nginx对这个问题无解。 ...

1 网络IO模型1.1 网络IO基本概念了解IO别离示意输出(input)和输入(output)。它形容的是计算机的数据流动的过程，因而IO第一大特色是有数据的流动；那么对于IO的整个过程大体上分为2个局部，第一个局部为IO的调用，第二个过程为IO的执行。IO的调用指的就是零碎调用，IO的执行指的是在内核中相干数据的处理过程，这个过程是由操作系统实现的，与程序员无关。 IO多路复用是指内核一旦发现过程指定的一个或者多个IO条件筹备读取，它就告诉该过程，目前反对I/O多路复用的零碎调用有select、poll、epoll，I/O多路复用就是通过一种机制，一个过程能够监督多个描述符（socket），一旦某个描述符就绪（个别是读就绪或者写就绪），可能告诉程序进行相应的读写操作。 描述符(socket)在windows中能够叫做句柄。咱们能够了解成一个文件对应的ID。IO其实就是对1.2 对同步 异步 阻塞 非阻塞在网络中的了解能够先看以前写的文章：对同步 异步 阻塞 非阻塞在网络中的了解 阻塞IO：申请过程始终期待IO准备就绪。非阻塞IO：申请过程不会期待IO准备就绪。同步IO操作：导致申请过程阻塞，直到IO操作实现。异步IO操作：不导致申请过程阻塞。 举个小例子来了解阻塞，非阻塞，同步和异步的关系，咱们晓得编写一个程序能够有多个函数，每一个函数的执行都是互相独立的；然而，对于一个程序的执行过程，每一个函数都是必须的，那么如果咱们须要期待一个函数的执行完结而后返回一个后果(比方接口调用)，那么咱们说该函数的调用是阻塞的，对于至多有一个函数调用阻塞的程序，在执行的过程中，必然存在阻塞的一个过程，那么咱们就说该程序的执行是同步的，对于异步天然就是所有的函数执行过程都是非阻塞的。这里的程序就是一次残缺的IO，一个函数为IO在执行过程中的一个独立的小片段。 咱们晓得在Linux操作系统中内存分为内核空间和用户空间，而所有的IO操作都得取得内核的反对，然而因为用户态的过程无奈间接进行内核的IO操作，所以内核空间提供了零碎调用，使得处于用户态的过程能够间接执行IO操作，IO调用的目标是将过程的外部数据迁徙到内部即输入，或将内部数据迁徙到过程外部即输出。而在这里探讨的数据通常是socket过程外部的数据。 1.3 五种IO模型基本原理在上图中，每一个客户端会与服务端建设一次socket连贯，而服务端获取连贯后，对于所有的数据的读取都得通过操作系统的内核，通过零碎调用内核将数据复制到用户过程的缓冲区，而后才实现客户端的过程与客户端的交互。那么依据零碎调用的形式的不同分为阻塞和非阻塞，依据零碎解决利用过程的形式不同分为同步和异步。 模型1：阻塞式IO每一次客户端产生的socket连贯实际上是一个文件描述符fd,而每一个用户过程读取的实际上也是一个个文件描述符fd,在该期间的零碎调用函数会期待网络申请的数据的达到和数据从内核空间复制到用户过程空间，也就是说，无论是第一阶段的IO调用还是第二阶段的IO执行都会阻塞，那么就像图中所画的一样，对于多个客户端连贯，只能开拓多个线程来解决。 模型2：非阻塞IO模型对于阻塞IO模型来说最大的问题就体现在阻塞2字上，那么为了解决这个问题，零碎的内核因而产生了扭转。在内核中socket反对了非阻塞状态。既然这个socket是不阻塞的了，那么就能够应用一个过程解决客户端的连贯，该过程外部写一个死循环，一直的询问每一个连贯的网络数据是否曾经达到。此时轮询产生在用户空间，然而该过程仍然须要本人解决所有的连贯，所以该期间为同步非阻塞IO期间，也即为NIO。 模型3：IO多路复用在非阻塞IO模型中，尽管解决了IO调用阻塞的问题，然而产生了新的问题，如果当初有1万个连贯，那么用户线程会调用1万次的零碎调用read来进行解决，在用户空间这种开销太大，那么当初须要解决这个问题，思路就是让用户过程缩小零碎调用，然而用户本人是实现不了的，所以这就导致了内核产生了进一步变动。在内核空间中帮忙用户过程遍历所有的文件描述符，将数据筹备好的文件描述符返回给用户过程。该形式是同步阻塞IO，因为在第一阶段的IO调用会阻塞过程。 IO多路复用是指内核一旦发现过程指定的一个或者多个IO条件筹备读取，它就告诉该过程，目前反对I/O多路复用的零碎调用有select、poll、epoll。，I/O多路复用就是通过一种机制，一个过程能够监督多个描述符（socket），一旦某个描述符就绪（个别是读就绪或者写就绪），可能告诉程序进行相应的读写操作。 select/poll为了让内核帮忙用户过程实现文件描述符的遍历，内核减少了零碎调用select/poll(select与poll实质上没有什么不同，就是poll缩小了文件描述符的个数限度)，当初用户过程只须要调用select零碎调用函数，并且将文件描述符全副传递给select就能够让内核帮忙用户过程实现所有的查问，而后将数据筹备好的文件描述符再返回给用户过程，最初用户过程顺次调用其余零碎调用函数实现IO的执行过程。 epoll在select实现的多路复用中仍然存在一些问题。 1、用户过程须要传递所有的文件描述符，而后内核将数据筹备好的文件描述符再次传递回去，这种数据的拷贝升高了IO的速度。2、内核仍然会执行复杂度为O(n)的被动遍历操作。对于第一个问题，提出了一个共享空间的概念，这个空间为用户过程和内核过程所共享，并且提供了mmap零碎调用，实现用户空间和内核空间到共享空间的映射，这样用户过程就能够将1万个文件描述符写到共享空间中的红黑树上，而后内核将准备就绪的文件描述符写入共享空间的链表中，而用户过程发现链表中有数据了就间接读取而后调用read执行IO即可。 对于第二个问题，内核引入了事件驱动机制(相似于中断)，不再被动遍历所有的文件描述符，而是通过事件驱动的形式被动告诉内核该文件描述符的数据筹备结束了，而后内核就将其写入链表中即可。对于epoll来说在第一阶段的epoll_wait仍然是阻塞的，故也是同步阻塞式IO。 模型4：信号驱动式IO在IO执行的数据筹备阶段，不会阻塞用户过程。当用户过程须要期待数据的时候，会向内核发送一个信号，通知内核须要数据，而后用户过程就持续做别的事件去了，而当内核中的数据筹备好之后，内核立马发给用户过程一个信号，用户过程收到信号之后，立马调用recvfrom，去查收数据。该IO模型应用的较少。 模型5：异步IO(AIO)利用过程通过 aio_read 告知内核启动某个操作，并且在整个操作实现之后再告诉利用过程，包含把数据从内核空间拷贝到用户空间。信号驱动 IO 是内核告诉咱们何时能够启动一个 IO 操作，而异步 IO 模型是由内核告诉咱们 IO 操作何时实现。是真正意义上的无阻塞的IO操作，然而目前只有windows反对AIO，linux内核临时不反对。 总结前四种模型的次要区别于第一阶段，因为他们的第二阶段都是一样的：在数据从内核拷贝到利用过程的缓冲区期间，过程都会阻塞。相同，异步 IO 模型在这两个阶段都不会阻塞，从而不同于其余四种模型。 间接内存与零拷贝间接内存并不是虚拟机运行时数据区的一部分，也不是Java 虚拟机标准中农定义的内存区域。间接内存申请空间消耗更高的性能，间接内存IO读写的性能要优于一般的堆内存，对于java程序来说，零碎内核读取堆类的对象须要依据代码段计算其偏移量来获取对象地址，效率较慢，不太适宜网络IO的场景，对于间接内存来说更加适宜IO操作，内核读取寄存在间接内存中的对象较为不便，因为其地址就是袒露的过程虚拟地址，不须要jvm翻译。那么就能够应用mmap开拓一块间接内存mapbuffer和内核空间共享，并且该间接内存能够间接映射到磁盘上的文件，这样就能够通过调用本地的put而不必调用零碎调用write就能够将数据间接写入磁盘,RandomAccessFile类就是通过开拓mapbuffer实现的读写磁盘。 以音讯队列Kafka来说，有生产者和消费者，对于生产者，从网络发来一个音讯msg并且被拷贝到内核缓冲区，该音讯通过Kafka调用recvfrom将内核中的msg读到队列中，而后加上音讯头head,再将该音讯写入磁盘。如果没有mmap的话，就会调用一个write零碎调用将该音讯写入内核缓冲区，而后内核将该音讯再写入磁盘。在此过程中呈现一次80中断和2次拷贝。但实际上Kafka应用的是mmap开拓了间接内存到磁盘的映射，间接应用put将音讯写入磁盘。实际上也是通过内核拜访该共享区域将该音讯写入的磁盘。同时在Kafka中有一个概念叫segment,个别为1G大小。它会充分利用磁盘的程序性，只追加数据，不批改数据。而mmap会间接开拓1G的间接内存，并且间接与segment造成映射关系，在segment满了的时候再开拓一个新的segment，清空间接内存而后在与新的segment造成映射关系。 零拷贝形容的是CPU不执行拷贝数据从一个存储区域到另一个存储区域的工作，这通常用于通过网络传输一个文件时以缩小CPU周期和内存带宽。 在Kafka的消费者读取数据的时候，如果以后消费者想读取的数据是不是以后间接内存所映射的segment怎么办？如果没有零拷贝的话，过程会先去调用read读取，而后数据会从磁盘被拷贝到内核，而后内核再拷贝到Kafka队列，过程再调用write将数据拷贝到内核缓冲区，最初再发送给消费者。实际上能够发现，数据没有必要读到Kafka队列，间接读到内核的缓冲区的时候发送给消费者就行了。实际上，linux内核中有一个零碎调用就是实现了这种形式读取数据——sendfile,它有2个参数，一个是infd(读取数据的文件描述符),一个是outfd(客户端的socket文件描述符).消费者只需调用该函数，通知它须要读取那个文件就能够不通过Kafka间接将数据读到内核，而后由内核写到消费者过程的缓冲区中。 2 nginx原理理解2.1 什么是nginxNginx 是一款自在的、开源的、高性能的HTTP服务器和反向代理服务器；同时也是一个IMAP、POP3、SMTP代理服务器； Nginx 能够作为一个HTTP服务器进行网站的公布解决，另外 Nginx 能够作为反向代理进行负载平衡的实现。 2.1.1 nginx的三个次要利用场景1、动态资源服务（通过本地文件系统提供服务）2、缓存、负载平衡服务器3、API服务（OpenResty） 2.2 为什么抉择nginx?更快 这体现在两个方面：一方面，在失常状况下，单次申请会失去更快的响应；另一方面， 在高峰期（如有数以万计的并发申请）， Nginx 能够比其余Web服务器更快地响应申请。高扩展性 Nginx 的设计极具扩展性，它齐全是由多个不同性能、不同档次、不同类型且耦合度极低的模块组成。因而，当对某一个模块修复 Bug 或进行降级时，能够专一于模块本身，毋庸在意其余。 而且在HTTP模块中，还设计了 HTTP 过滤器模块：一个失常的 HTTP 模块在解决完申请后，会有一串 HTTP 过滤器模块对申请的后果进行再解决。这样，当咱们开发一个新的 HTTP 模块时，岂但能够应用诸如 HTTP 外围模块、events模块、log模块 等不同档次或者不同类型的模块，还能够一成不变地复用大量已有的 HTTP 过滤器模块。 这种低耦合度的优良设计，造就了 Nginx 宏大的第三方模块，当然，公开的第三方模块也如官网公布的模块一样容易应用。 Nginx 的模块都是嵌入到二进制文件中执行的，无论官网公布的模块还是第三方模块都是如此。这使得第三方模块一样具备极其优良的性能，充分利用 Nginx的高并发个性，因而，许多高流量的网站都偏向于开发合乎本人业务个性的定制模块。高可靠性 高可靠性是咱们抉择 Nginx 的最根本条件，因为 Nginx 的可靠性是大家引人注目的，很多家高流量网站都在外围服务器上大规模应用 Nginx 。 Nginx 的高可靠性来自于其外围框架代码的优良设计、模块设计的简略性；另外，官网提供的罕用模块都十分稳固，每个 worker 过程绝对独立，master过程在1个worker过程出错时能够疾速“拉起”新的 worker 子过程提供服务。低内存耗费 个别状况下，10000个非沉闷的HTTP Keep-Alive连贯在 Nginx 中仅耗费2.5MB的内存，这是 Nginx 反对高并发连贯的根底。单机反对10万以上的并发连贯 这是一个十分重要的个性！随着互联网的迅猛发展和互联网用户数量的成倍增长，各大公司、网站都须要应酬海量并发申请，一个可能在峰值期顶住10万以上并发申请的Server， 无疑会失去大家的青眼。实践上，Nginx反对的并发连贯下限取决于内存，当然，可能及时地解决更多的并发申请，是与业务特点严密相干的。热部署 master治理过程与 worker 工作过程的拆散设计，使得 worker 可能提供热部署性能，即能够在7×24小时不间断服务的前提下，降级 worker 的可执行文件。当然，它也反对不进行服务就更新配置项、更换日志文件等性能。最自在的BSD许可协定 这是 worker 能够疾速倒退的弱小能源。BSD许可协定不只是容许用户收费应用 worker ，它还容许用户在本人的我的项目中间接应用或批改 worker 源码，而后公布。这吸引了有数开发者持续为 worker 奉献本人的智慧。2.3 Nginx相干的开源版本1、阿里巴巴Tengine Tengine是由淘宝网发动的Web服务器我的项目。它在Nginx的根底上，针对大访问量网站的需要，增加了很多高级性能和个性。2、openresty OpenResty® 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其外部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于不便地搭建可能解决超高并发、扩展性极高的动静 Web 利用、Web 服务和动静网关。 ...

文 | 平哥 日期 | 20201025 Step 1 上传并解压安装文件上传并解压文件：fastdfs-nginx-module_v1.16.tar.gz Step 2 批改配置文件进入解压目录中src目录 # cd fastdfs-nginx-module/src编辑config文件， # vim config批改配置文件中第四行，把门路中local去掉。参数是用于配置装置nginx中的FastDFS组件的时候，在什么地位查找FastDFS外围代码。批改后如图： Step 3 装置nginx的依赖# yum install -y gcc gcc-c++ make automake autoconf libtool pcre pcre-devel zlib zlib-devel openssl openssl-devel显示如下代表装置胜利： Step 4 上传Nginx并解压上传并解压文件：nginx-1.16.1.tar.gz Step 5 批改Nginx配置1. 进入到nginx文件夹 # cd nginx-1.16.12. 创立长期目录批改配置文件中好多地位都应用了/var/temp/nginx目录，然而默认不会主动创立这个目录的，须要手动创立。 # mkdir -p /var/temp/nginx3. 批改配置文件参数命令如下： ./configure \--prefix=/usr/local/nginx \--pid-path=/var/run/nginx/nginx.pid \--lock-path=/var/lock/nginx.lock \--error-log-path=/var/log/nginx/error.log \--http-log-path=/var/log/nginx/access.log \--with-http_gzip_static_module \--http-client-body-temp-path=/var/temp/nginx/client \--http-proxy-temp-path=/var/temp/nginx/proxy \--http-fastcgi-temp-path=/var/temp/nginx/fastcgi \--http-uwsgi-temp-path=/var/temp/nginx/uwsgi \--http-scgi-temp-path=/var/temp/nginx/scgi \--add-module=/root/upload/fastdfs-nginx-module/src提醒：--add-module必须定义，此配置信息是用于指定装置Nginx时须要加载的模块，如果未指定，Nginx装置过程不会加载fastdfs-nginx-module模块，后续性能无奈实现。值为Step 1 解压目录中的src目录 ...

本文起源：http://8rr.co/LSUH 前言本篇文章次要介绍的是Nginx如何实现负载平衡。 负载平衡介绍在介绍Nginx的负载平衡实现之前，先简略的说下负载平衡的分类，次要分为硬件负载平衡和软件负载平衡，硬件负载平衡是应用专门的软件和硬件相结合的设施，设施商会提供残缺成熟的解决方案，比方F5，在数据的稳定性以及安全性来说十分牢靠，然而相比软件而言造价会更加低廉；软件的负载平衡以Nginx这类软件为主，实现的一种音讯队列散发机制。 简略来说所谓的负载平衡就是把很多申请进行分流，将他们调配到不同的服务器去解决。比方我有3个服务器，别离为A、B、C，而后应用Nginx进行负载平衡，应用轮询策略，此时如果收到了9个申请，那么会平均的将这9个申请分发给A、B、Cf服务器，每一个服务器解决3个申请，这样的话咱们能够利用多台机器集群的个性缩小单个服务器的压力。 Nginx实现负载平衡的示例图: 负载平衡策略NGINX开源反对四种负载平衡办法，而NGINX Plus又减少了两种办法。 1.Round Robin: 对所有的申请进行轮询发送申请，默认的调配形式。 nginx.conf 配置示例: upstream xuwujing {   server www.panchengming.com;   server www.panchengming2.com;}注:下面的域名也能够用IP代替。 2.Least Connections：以起码的流动连接数将申请发送到服务器，同样要思考服务器权重。 nginx.conf 配置示例: upstream xuwujing {    least_conn;    server www.panchengming.com;    server www.panchengming2.com;}3.IP Hash : 发送申请的服务器由客户机IP地址决定。在这种状况下，应用IPv4地址的前三个字节或整个IPv6地址来计算散列值。该办法保障来自雷同地址的申请达到雷同的服务器，除非该服务器不可用。 upstream xuwujing {     ip_hash;     server www.panchengming.com;     server www.panchengming2.com;}4.Generic Hash: 申请发送到的服务器由用户定义的键决定，该键能够是文本字符串、变量或组合。 upstream xuwujing {     hash $request_uri consistent;     server www.panchengming.com;        server www.panchengming2.com; }5.Least Time (NGINX Plus only) – 对于每个申请，NGINX Plus抉择具备最低均匀提早和最低流动连接数的服务器，其中最低均匀提早是依据蕴含least_time指令的下列参数计算的: header ：从服务器接管第一个字节的工夫。last_byte：从服务器接管残缺响应的工夫。last_byte inflight：从服务器接管残缺响应的工夫。upstream xuwujing { least_time header; server www.panchengming.com; server www.panchengming2.com; } 6.Random：每个申请将被传递到随机抉择的服务器。如果指定了两个参数，首先，NGINX依据服务器权重随机抉择两个服务器，而后应用指定的办法抉择其中一个。 least_conn ：流动连贯的起码数量least_time=header (NGINX Plus)：从服务器接管响应标头的最短均匀工夫 ($upstream_header_time)。least_time=last_byte (NGINX Plus) ：从服务器接管残缺响应的最短均匀工夫（$upstream_response_time）。 upstream xuwujing {random two least_time=last_byte;server www.panchengming.com;server www.panchengming2.com;}Nginx+SpringBoot实现负载平衡环境筹备依赖JDK1.8以上的版本；依赖Nginx环境；这里的我的项目就用自己之前的一个springboot我的项目，SpringBoot的我的项目地址: https://github.com/xuwujing/s... 首先咱们下载这个我的项目，输出:mvn clean package 将我的项目进行打包为jar文件,而后将application.properties和此jar我的项目放在一个文件夹中，而后复制该文件夹(这里为了清晰所以进行复制，理论不复制更改端口重启也行)，批改复制文件夹application.properties的端口，比方改为8086。 Nginx 配置咱们找到nginx的配置文件nginx.conf，该配置在nginx/conf/nginx.conf目录下，而后咱们来批改该配置，新增如下配置: upstream pancm{   server 127.0.0.1:8085;   server 127.0.0.1:8086;}upstream pancm：定义一个名称，随便就行；server + ip:端口 or 域名；如果不想应用Round Robin策略，也能够换成其余的。 ...

这两天在搞 酷瓜云网课 的 app，采纳 uni-app 做全端反对，现学现卖，目前算是入门了。 在做 H5 的时候难免会跨域申请后端 API，尽管用 HBuilder 内置的浏览器不会有跨域问题（这个应该是做了外部解决），然而那个内置浏览器真尼妈坑爹，过一会就会卡死，导致 HBuilder 无响应，杀过程也是杯水车薪，只能重启，反复几次谁受的了。起初发现用内部的浏览器不会有这个问题，然而又面临跨域。 这里采纳配置 nginx 来反对 CORS，这样的话就不必动任何代码了。正确的配置如下： location ~ \.php$ { if ($request_method = 'OPTIONS') { add_header 'Access-Control-Allow-Origin' '*' always; add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE' always; add_header 'Access-Control-Allow-Headers' '*' always; add_header 'Access-Control-Max-Age' 1728000 always; add_header 'Content-Length' 0; add_header 'Content-Type' 'text/plain; charset=utf-8'; return 204; } if ($request_method ~* '(GET|POST|DELETE|PUT)') { add_header 'Access-Control-Allow-Origin' '*' always; }}PS：网上很多都是采集，粘贴复制的垃圾文章，齐全没有去验证的，碰到了会节约还多工夫，还会把你带坑里去。

HTTP协定的Cache -Control指定申请和响应遵循的缓存机制。在申请音讯或响应音讯中设置 Cache-Control并不会影响另一个音讯处理过程中的缓存处理过程。申请时的缓存指令包含: no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached等。响应音讯中的指令包含: public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。 Cache-Control:设置绝对过期工夫, max-age指明以秒为单位的缓存工夫. 若对动态资源只缓存一次, 能够设置max-age的值为315360000000 (一万年). 比方对于提交的订单，为了避免浏览器回退从新提交，能够应用Cache-Control之no-store相对禁止缓存，即使浏览器回退仍然申请的是服务器，进而判断订单的状态给出相应的提示信息！ 一.   浏览器中对于Cache的3属性:1. Cache-Control:设置绝对过期工夫, max-age指明以秒为单位的缓存工夫. 若对动态资源只缓存一次, 能够设置max-age的值为315360000000 (一万年). 比方对于提交的订单，为了避免浏览器回退从新提交，能够应用Cache-Control之no-store相对禁止缓存，即使浏览器回退仍然申请的是服务器，进而判断订单的状态给出相应的提示信息！ Http协定的cache-control的常见取值及其组合释义:no-cache: 数据内容不能被缓存, 每次申请都从新拜访服务器, 若有max-age, 则缓存期间不拜访服务器.no-store: 不仅不能缓存, 连暂存也不能够(即: 长期文件夹中不能暂存该资源).private(默认): 只能在浏览器中缓存, 只有在第一次申请的时候才拜访服务器, 若有max-age, 则缓存期间不拜访服务器.public: 能够被任何缓存区缓存, 如: 浏览器、服务器、代理服务器等.max-age: 绝对过期工夫, 即以秒为单位的缓存工夫.no-cache, private: 关上新窗口时候从新拜访服务器, 若设置max-age, 则缓存期间不拜访服务器.-  private, 负数的max-age: 后退时候不会拜访服务器.-  no-cache, 负数的max-age: 后退时会拜访服务器. 2. Expires:设置以分钟为单位的相对过期工夫, 优先级比Cache-Control低, 同时设置Expires和Cache-Control则后者失效. 也就是说要留神一点:  Cache-Control的优先级高于Expires expires起到管制页面缓存的作用，合理配置expires能够缩小很多服务器的申请, expires的配置能够在http段中或者server段中或者location段中.  比方管制图片等过期工夫为30天, 能够配置如下:location ~ .(gif|jpg|jpeg|png|bmp|ico)$ { root /var/www/img/`;` expires 30d; }再比方:location ~ .(wma|wmv|asf|mp3|mmf|zip|rar|swf|flv)$ { ...

OpenResty 我的项目模板，新我的项目能够 clone 下来批改 我的项目地址：https://github.com/fengjx/ope... 相干浏览 OpenResty 从入门到开发一个网关服务OpenResty 最佳实际跟我学OpenResty(Nginx+Lua)开发环境依赖openrestyluarocksmake cmd$ make helpMakefile cmd: deps: 装置依赖 start: 启动服务（前台过程） start: 启动服务（后盾过程） start: 进行服务 start: 进行服务 help: Makefile帮忙疾速开始# 下载我的项目模板$ git clone https://github.com/fengjx/openresty-quick-start.git# 删除 git 文件$ rm -rf .git# 批改我的项目名$ mv openresty-quick-start my-project$ cd my-project# 装置依赖$ make deps# 启动服务$ make start-backgroundserver start for background# 拜访测试$ curl -i http://localhost:1024HTTP/1.1 200 OKDate: Wed, 14 Oct 2020 13:14:59 GMTContent-Type: application/jsonTransfer-Encoding: chunkedConnection: keep-aliveServer: OpenRestyok# 进行服务$ make quitserver quit目录构造├── Makefile - makefile 脚本├── README.md - 阐明文档├── conf - nginx 配置│ ├── common - 公共配置│ └── servers - server 配置├── logs - 日志目录├── rockspec - 依赖治理└── src - lua 源码目录 ├── app.lua └── core

前后端拆散我的项目，前后端共用一个域名。通过域名后的 url 前缀来区别前后端我的项目。以 vue + php 我的项目为例。间接上 server 模块的 nginx 配置。 server { listen 80; #listen [::]:80 default_server ipv6only=on; server_name demo.com; # 配置我的项目域名 index index.html index.htm index.php; # 1.转给前端解决 location / { # 前端打包后的动态目录 alias /home/wwwroot/default/vue-demo/dist/; } # 2.转给后端解决 location /api/ { try_files $uri $uri/ /index.php?$query_string; } # 3.最终php在这里转给fpm location ~ [^/]\.php(/|$) { # 后端我的项目目录 root /home/wwwroot/default/demo/public/; #fastcgi_pass 127.0.0.1:9000; fastcgi_pass unix:/tmp/php-cgi.sock; fastcgi_index index.php; include fastcgi.conf; include pathinfo.conf; } # 4.解决后端的动态资源 location /public/ { alias /home/wwwroot/default/demo/public/uploads/; } #error_page 404 /404.html; access_log /home/wwwlogs/access.log main;}简略解释 ...

装置编译环境需先装置好编译环境make，gcc和g++ 开发库 yum -y install gcc automake autoconf libtool makeyum install gcc gcc-c++装置pcrepcre(Perl Compatible Regular Expressions)： perl 兼容的正则表达式库。 以下各编译装置的源码包均放在/usr/local/src下，Nginx依赖pcre是为了重写rewrite。 从ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/下载pcre包，不宜太新，举荐应用pcre8.39或8.40，太新的pcre版本Nginx不反对。 cd /usr/local/srcwget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.39.tar.gztar -zxvf pcre-8.39.tar.gzcd pcre-8.39./configuremakemake install<!--more--> 装置zlibzlib是为了Nginx压缩 从http://zlib.net/出下载以后最...://zlib.net/zlib-1.2.11.tar.gz cd /usr/local/srcwget http://zlib.net/zlib-1.2.11.tar.gztar -zxvf zlib-1.2.11.tar.gzcd zlib-1.2.11./configuremakemake install装置sslcd /usr/local/srcwget https://www.openssl.org/source/openssl-1.0.1t.tar.gztar -zxvf openssl-1.0.1t.tar.gzcd openssl-1.0.1t./config # 不是./Configuremakemake install装置NginxNginx 个别有两个版本，别离是稳定版和开发版，您能够依据您的目标来抉择这两个版本的其中一个，上面是把 Nginx 装置到 /usr/local/nginx 目录下的具体步骤： cd /usr/local/srcwget https://nginx.org/download/nginx-1.10.2.tar.gztar -zxvf nginx-1.10.2.tar.gzcd nginx-1.10.2./configure --sbin-path=/usr/local/nginx/nginx --conf-path=/usr/local/nginx/nginx.conf --pid-path=/usr/local/nginx/nginx.pid --with-http_ssl_module --with-pcre=/usr/local/src/pcre-8.39 --with-zlib=/usr/local/src/zlib-1.2.11 --with-openssl=/usr/local/src/openssl-1.0.1t --with-http_v2_modulemakemake install--with-pcre=/usr/local/src/pcre-8.39 指的是pcre-8.39 的源码门路。--with-zlib=/usr/local/src/zlib-1.2.11 指的是zlib-1.2.11 的源码门路。--with-openssl=/usr/local/src/openssl-1.0.1t指的是openssl-1.0.1t 的源码门路。启用 https,时如需应用 http/2 协定，则会依赖ngx_http_v2_module模块，能够应用--with-http_v2_module配置参数来启用。启动Nginx测试nginx.conf是否正确 ...

新建配置配置文件 （例如进入到nginx装置目录下的conf目录，创立： agent_deny.conf） 禁止Scrapy等工具的抓取 if ($http_user_agent ~* (Scrapy|Curl|HttpClient)) { return 403; }禁止指定UA及UA为空的拜访#forbidden Scrapyif ($http_user_agent ~* (Scrapy|Curl|HttpClient)){ return 403;}#forbidden UAif ($http_user_agent ~ "Bytespider|FeedDemon|JikeSpider|Indy Library|Alexa Toolbar|AskTbFXTV|AhrefsBot|CrawlDaddy|CoolpadWebkit|Java|Feedly|UniversalFeedParser|ApacheBench|Microsoft URL Control|Swiftbot|ZmEu|oBot|jaunty|Python-urllib|lightDeckReports Bot|YYSpider|DigExt|YisouSpider|HttpClient|MJ12bot|heritrix|EasouSpider|Ezooms|^$" ){ return 403;}#forbidden not GET|HEAD|POST method accessif ($request_method !~ ^(GET|HEAD|POST)$){ return 403;}而后，在网站相干配置中的 server段插入如下代码： include agent_deny.conf; 重启nginx：/data/nginx/sbin/nginx -s reload测试 应用curl -A 模仿抓取即可，比方： curl -I -A 'YYSpider' <<<www.xxx.con>>>后果[root@11 conf]# curl -I -A 'YYSpider' www.xxx.cnHTTP/1.1 403 ForbiddenServer: nginx/1.12.0Date: Wed, 24 Apr 2019 11:35:21 GMTContent-Type: text/htmlContent-Length: 169Connection: keep-alive模仿UA为空的抓取：curl -I -A' ' <<<www.xxx.cn>>>后果[root@11 conf]# curl -I -A' ' www.xxx.cnHTTP/1.1 403 ForbiddenServer: nginx/1.12.0Date: Wed, 24 Apr 2019 11:36:06 GMTContent-Type: text/htmlContent-Length: 169Connection: keep-alive模仿百度蜘蛛的抓取：curl -I -A 'Baiduspider' <<<www.xxx.cn>>>[root@11 conf]# curl -I -A 'Baiduspider' www.xxx.cnHTTP/1.1 200 OKServer: nginx/1.12.0Date: Wed, 24 Apr 2019 11:36:47 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Fri, 12 Apr 2019 13:49:36 GMTConnection: keep-aliveETag: "5cb09770-264"Accept-Ranges: bytesUA类型FeedDemon 内容采集BOT/0.1 (BOT for JCE) sql注入CrawlDaddy sql注入Java 内容采集Jullo 内容采集Feedly 内容采集UniversalFeedParser 内容采集ApacheBench cc攻击器Swiftbot 无用爬虫YandexBot 无用爬虫AhrefsBot 无用爬虫YisouSpider 无用爬虫（已被UC神马搜寻收买，此蜘蛛能够放开！）jikeSpider 无用爬虫MJ12bot 无用爬虫ZmEu phpmyadmin 破绽扫描WinHttp 采集cc攻打EasouSpider 无用爬虫HttpClient tcp攻打Microsoft URL Control 扫描YYSpider 无用爬虫jaunty wordpress爆破扫描器oBot 无用爬虫Python-urllib 内容采集Indy Library 扫描FlightDeckReports Bot 无用爬虫Linguee Bot 无用爬虫nginx 防盗链配置背景：避免第三方援用链接拜访咱们的图片，耗费服务器资源和网络流量，咱们能够在服务器上做防盗链限度。实现防盗链的形式有两种：refer形式和签名形式。 ...

NGINX联结创始人安德鲁·阿列克谢夫（Andrew Alexeev）曾说：NGINX是为对Apache性能不称心的人而构建的。随着Internet需要的变动，Web服务器的工作也在变动。NGINX的构建比以往任何时候都更有效率，更可扩大，更平安，更弱小。 本文提供了Nginx的基本概念及常识。以开发者必备的Nginx基础知识为主，列举了一些Nginx教程，心愿对大家有所帮忙。 一.环境 服务器版本：CentOS 7.2 为了保障学习阶段不遇到奇怪的事件，请保障以下四点： 确认零碎网络确认yum可用确认敞开iptables确认停用selinux#查看iptables状态systemctl status firewalld.service#敞开防火墙（长期敞开）systemctl stop firewalld.service#查看SELinux状态 getenforce#长期敞开SELinux setenforce 0装置一些零碎根本工具，失常状况零碎都会自带 yum -y install gcc gcc-c++ autoconf pcre pcre-devel make automakeyum -y install wget httpd-tools vim二.基本概念 2.1Nginx是什么？ Nginx是一个高性能的http和反向代理服务器，其特点是占用内存小，并发能力强。Nginx专为性能优化而开发，性能是其最重要的考量，能禁受高负载的考验，有报告表明能反对高达50000个并发连接数。 2.2正向代理与反向代理 为了便于了解，首先先来理解一下一些基础知识，nginx是一个高性能的反向代理服务器那么什么是反向代理呢？ 代理是在服务器和客户端之间假如的一层服务器，代理将接管客户端的申请并将它转发给服务器，而后将服务端的响应转发给客户端。 不论是正向代理还是反向代理，实现的都是下面的性能。如果你对OSI 七层模型与 TCP/IP 四层模型不是很相熟能够再回顾下。 正向代理正向代理（forward）意思是一个位于客户端和原始服务器 (origin server) 之间的服务器，为了从原始服务器获得内容，客户端向代理发送一个申请并指定指标 (原始服务器)，而后代理向原始服务器转交申请并将取得的内容返回给客户端。 正向代理是为咱们服务的，即为客户端服务的，客户端能够依据正向代理拜访到它自身无法访问到的服务器资源。 正向代理对咱们是通明的，对服务端是非通明的，即服务端并不知道本人收到的是来自代理的拜访还是来自实在客户端的拜访。 反向代理反向代理（Reverse Proxy）形式是指以代理服务器来承受 internet 上的连贯申请，而后将申请转发给外部网络上的服务器，并将从服务器上失去的后果返回给 internet 上申请连贯的客户端，此时代理服务器对外就体现为一个反向代理服务器。 反向代理是为服务端服务的，反向代理能够帮忙服务器接管来自客户端的申请，帮忙服务器做申请转发，负载平衡等。 反向代理对服务端是通明的，对咱们是非通明的，即咱们并不知道本人拜访的是代理服务器，而服务器晓得反向代理在为他服务。 2.3负载平衡 如果申请数过大，单个服务器解决不了，咱们减少服务器的数量，而后将申请散发到各个服务器上，将原先申请集中到单个服务器的状况改为申请散发到多个服务器上，就是负载平衡。 Upstream 指定后端服务器地址列表，在 server 中拦挡响应申请，并将申请转发到 Upstream 中配置的服务器列表。 `upstream balanceServer {  server 10.1.22.33:12345;    server 10.1.22.34:12345; server 10.1.22.35:12345;}server {     server_name  fe.server.com;    listen 80;    location /api {        proxy_pass http://balanceServer;  }}` ...

Nginx 编译 Nginx针对 Unix 环境 下载 Nginx从 Nginx 官网 出下载想要编译版本的 Nginx，Nginx 官网提供三个版本： Mainline version 主线版本，性能较新，稳定性较 Stable version 稍差，倡议学习应用该版本，理论生产应用 Stable version。 Stable version稳固版本 Legacy versions历史版本 wget http://nginx.org/download/nginx-1.17.4.tar.gztar -zxvf nginx-1.17.4.tar.gzcd nginx-1.17.4Nginx 源码目录介绍 auto编译时的依赖库以及针对操作系统个性抉择库 CHANGES英文版 Nginx 各版本变更阐明 CHANGES.ru俄文版 Nginx 各版本变更阐明（Nginx 作者是俄罗斯人） conf配置文件目录 configure编译配置，编译前生成两头文件不便编译 次要有编译门路配置、某些性能开关及模块配置 --prefix 设置服务器寄存地址，也是其余未配置门路的目录的默认根目录 --XXX-path 代表设置 XXX 目录的地址 --with-XXX_module 代表启用某些模块 --without-XX_module 代表禁用某些模块，这些模块是 Nginx 默认会编译的模块 还有一些其余参数能够参考能够参考 Ngxin 官网文档 contribvim 提醒插件以及一些晋升应用 Nginx 效率的工具脚本 配置 vim 提醒 ...

白名单浏览器无奈辨别JS的起源，有的JS是来自利用自身的，而有的则有可能来自歹意注入。因为浏览器无奈辨别JS的起源，这可能会被XSS攻打所利用。 什么是XSS？例如在一个博客网站，发表一篇蕴含歹意脚本的<script>标签的文章，这篇文章会保留在服务器中。当其他人拜访这篇文章时，会在访问者的浏览器中执行歹意的脚本。因为浏览器无奈辨别JS代码是好的，还是坏的。浏览器都会下载并执行JS。 CSP（Content-Security-Policy）Content-Security-Policy 的 HTTP Header 能够批示浏览器只信赖指定白名单的JS源。即便通过XSS攻打注入了歹意的脚本文件，浏览器也不会执行。 CSP Nginx 示例server { listen 8090; server_name localhost; root /Users/zhangyue/Desktop/csp; index index.html; add_header Content-Security-Policy "script-src 'self';"; location ~* \.(?:js|css)$ { expires 7d; add_header Cache-Control no-store; }}增加CSP之前 jqeury的cdn能够失常被加载 增加CSP之后 增加CSP后，浏览器只会抛出一个谬误，不会执行任何白名单之外的JS代码 其余资源除了javascript外，CSP还能够对网站的其余的资源进行限度 style-src 限度css的资源地址img-src 限度图片的资源地址font-src 限度字体资源的地址…… 等等# img-src 为图片资源减少白名单server { add_header Content-Security-Policy "script-src 'self';"; # 只容许http://photocdn.sohu.com; 和 当面域名下的图片进行加载 add_header Content-Security-Policy "img-src 'self' http://photocdn.sohu.com;";}然而值得注意的是，如果你不在nginx中对具体（css，js，image……）的资源作出限度，那么就代表不限度资源的起源。默认能够加载任何起源的资源。 应用 default-src 能够为没有指定白名单的资源，提供一个默认的白名单。 server { listen 8090; server_name localhost; index index.html; # default-src 为没有提供的资源提供了白名单: 'self'，只容许加载以后域名下的资源 add_header Content-Security-Policy "script-src 'self';img-src 'self' http://photocdn.sohu.com;default-src 'self'";}http-equiv除了通过配置Nginx，为页面增加CSP。还能够通过 meta 标签的http-equiv的属性，增加页面增加CSP。http-equiv能够为content属性值提供，提供http头。 ...

Nginx 是一个高性能的 HTTP 和反向代理服务器，特点是占用内存少，并发能力强，事实上 Nginx 的并发能力的确在同类型的网页服务器中体现较好。Nginx 专为性能优化而开发，性能是其最重要的要求，非常重视效率，有报告 Nginx 能反对高达 50000 个并发连接数。 Nginx 常识网结构图Nginx 的常识网结构图如下： 反向代理正向代理：局域网中的电脑用户想要间接拜访网络是不可行的，只能通过代理服务器来拜访，这种代理服务就被称为正向代理。 反向代理：客户端无奈感知代理，因为客户端拜访网络不须要配置，只有把申请发送到反向代理服务器，由反向代理服务器去抉择指标服务器获取数据，而后再返回到客户端。 此时反向代理服务器和指标服务器对外就是一个服务器，裸露的是代理服务器地址，暗藏了实在服务器 IP 地址。 负载平衡客户端发送多个申请到服务器，服务器解决申请，有一些可能要与数据库进行交互，服务器处理完毕之后，再将后果返回给客户端。 一般申请和响应过程如下图： 然而随着信息数量增长，访问量和数据量飞速增长，一般架构无奈满足当初的需要。 咱们首先想到的是降级服务器配置，能够因为摩尔定律的日益生效，单纯从硬件晋升性能曾经逐步不可取了，怎么解决这种需要呢？ 咱们能够减少服务器的数量，构建集群，将申请散发到各个服务器上，将原来申请集中到单个服务器的状况改为申请散发到多个服务器，也就是咱们说的负载平衡。 图解负载平衡： 假如有 15 个申请发送到代理服务器，那么由代理服务器依据服务器数量，平均分配，每个服务器解决 5 个申请，这个过程就叫做负载平衡。 动静拆散为了放慢网站的解析速度，能够把动静页面和动态页面交给不同的服务器来解析，放慢解析的速度，升高由单个服务器的压力。 动静拆散之前的状态： 动静拆散之后： 装置参考链接： Nginx服务介绍与装置 Nginx 常用命令#查看版本：./nginx -v#启动：./nginx#敞开（有两种形式，举荐应用 ./nginx -s quit）：./nginx -s stop./nginx -s quit#从新加载 Nginx 配置：./nginx -s reloadNginx 的配置文件配置文件分三局部组成： ①全局块 从配置文件开始到 events 块之间，次要是设置一些影响 Nginx 服务器整体运行的配置指令。 并发解决服务的配置，值越大，能够反对的并发处理量越多，然而会受到硬件、软件等设施的制约。 ...

nginx 学习反向代理负载平衡动静拆散反向代理正向代理 客户端通过代理服务器拜访网络 称之为正向代理反向代理 通过反向代理服务器 转发到真正的服务器 能够暗藏实在服务器负载平衡 客户端发送申请到反向代理服务器 反向代理服务器平均分配申请到多台服务器动静拆散 把动静页面和动态页面离开进行部署 装置nginxsudo yum install epel-releasesudo yum install nginx敞开防火墙 nginx常用命令ps -ef | grep nginx 查看nginx过程nginx -v 查看版本号nginx -s stop 敞开命令nginx -s reload 重启命令 nginx配置文件配置文件由三局部组成 第一局部 全局块从配置文件到 events之间的内容 user nginx;worker_processes auto; //并发量error_log /var/log/nginx/error.log;pid /run/nginx.pid;# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.include /usr/share/nginx/modules/*.conf;第二局部 eventsnginx反对的最大连接数 worker_connections 服务器与用户网络连接局部 events { worker_connections 1024;}第三局部 大多数性能和配置 http块http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; # Load modular configuration files from the /etc/nginx/conf.d directory. # See http://nginx.org/en/docs/ngx_core_module.html#include # for more information. include /etc/nginx/conf.d/*.conf; server { listen 80 default_server; listen [::]:80 default_server; server_name _; root /usr/share/nginx/html; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /404.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } }# Settings for a TLS enabled server.## server {# listen 443 ssl http2 default_server;# listen [::]:443 ssl http2 default_server;# server_name _;# root /usr/share/nginx/html;## ssl_certificate "/etc/pki/nginx/server.crt";# ssl_certificate_key "/etc/pki/nginx/private/server.key";# ssl_session_cache shared:SSL:1m;# ssl_session_timeout 10m;# ssl_ciphers HIGH:!aNULL:!MD5;# ssl_prefer_server_ciphers on;## # Load configuration files for the default server block.# include /etc/nginx/default.d/*.conf;## location / {# }## error_page 404 /404.html;# location = /404.html {# }## error_page 500 502 503 504 /50x.html;# location = /50x.html {# }# }}http全局块 server局部 和虚拟主机有密切关系 全局server ...

为什么应用宝塔面板？老手建站最大的苦楚就是不好入门，代码太多，无奈轻松治理。在这里，咱们介绍一种简略好用的收费服务器运维面板——宝塔面板。应用宝塔面板，能够在可视界面中为服务器装置利用、同步文件、定期执行代码、治理服务，十分不便。 【往期文章】如果还有不理解宝塔面板怎么应用的小伙伴，能够看下往期文章： 宝塔面板教程（1）基于云服务器搭建宝塔面板教程最全详解宝塔面板教程（2）宝塔面板增加WordPress站点具体图文教程宝塔面板教程（3）基于宝塔面板胜利配置网站SSL平安证书宝塔面板教程（4）WordPress网站的备份与复原（宝塔面板）宝塔面板的装置1. 装置Xshell参考教程：应用Xshell6近程连贯阿里云Linux云服务器 2. 应用Xshell（或阿里云自带治理终端）连贯到阿里云服务器 （1）阿里云自带治理终端连贯到服务器No. 1. 进入云服务器治理控制台No. 2. 抉择进入云服务器ECS No. 3. 进入实例列表 No. 4. 点击近程连贯，输出连贯明码，进入治理终端 No. 5. 输出ESC实例的用户名和明码，连贯到云服务器 （2）Xshell连贯到云服务器No. 1. 关上Xshell，点击新建会话 No. 2. 双击创立好了的会话，输出ESC实例的用户名和明码，连贯到云服务器（1）双击会话 （2）一次性承受密钥 （3）输出用户名 （4）输出明码 （5）胜利连贯到云服务器 3. 装置宝塔面板（1）进入宝塔面板官网宝塔面板官网地址 （2）进入宝塔面板装置教程，复制云服务器零碎的宝塔面板装置指令。宝塔面板装置教程 （3）在Xshell（或阿里云自带的治理终端）中执行命令：（我的云服务器零碎是ubuntu） wget -O install.sh http://download.bt.cn/install/install-ubuntu_6.0.sh && sudo bash install.sh1 （4）面板装置实现，命令行显示面板网址、用户名、明码等信息。 4. 拜访云服务器端宝塔面板个别为ip:8888/一个8位字符的平安入口名称，然而一开始无法访问 （1）从云服务器治理控制台从新进入实例列表，抉择平安组配置。云服务器治理控制台 （2）抉择配置规定 （3）发现入方向没有端口为8888的平安组规定，点击增加平安组规定 （4）填写平安组规定（右侧会有提醒） （5）依照之前提醒的地址拜访面板（http://ip:8888/一个8位字符的平安入口名称） 5. 面板软件装置以及服务器搭建（1）举荐套件装置（举荐装置LNMP，然而不要装置外面的MYSQL老版本）如果你不理解两种的区别和差别请应用举荐装置（LNMP套件），装置形式这里依据本身理论的状况抉择，如果以后环境为生产环境，请应用（编译装置），确保前期程序运行的稳定性，（极速装置）次要用体验和测试应用，正式状况下请防止应用（极速装置），如果不须要这些套件也能够在面板左侧性能栏抉择《软件治理》，在以后列表自行抉择安装程序。抉择一键装置后，在面板的左上角，会主动显示工作的数量，点击后进入工作列表。 ...

需要剖析当实现文件上传时，要求业务返回页面的是虚拟地址实在是存储在磁盘里要求虚拟地址和磁盘地址映射-用到了反向代理机制 反向代理1.反向代理服务器位于用户与指标服务器之间2.用户间接拜访反向代理服务器就能够取得指标服务器的资源3.个别反向代理机制爱护了实在的服务器信息4.用户根部不分明实在的服务器是谁 正向代理路由器：办理宽带-账号/明码（只能被一台机器应用）-中端设施 （路由器：家庭局域网）1.客户端在发动申请时，确定了指标服务器的地址2.服务器不分明到底是哪台客户端拜访的，认为只是路由器拜访的3.爱护了客户端信息 Nginx高性能的HTTP和反向代理web服务器特点：1.内存小 —— 不超过2M Tomcat服务器大概占600M 2.并发能力强——3-5万次/秒 Tomcat服务器大概150-220 下载http://nginx.org/en/download.... 注意事项：1.不要放在零碎文件目录中 中文门路和空格2.Nginx服务器启动的速度特地快，窗口会闪退 只启动一次即可3.nginx启动会占用80端口4.nginx命令的运行必须在nginx.exe所在的目录中执行 nginx命令1.启动命令：start nginx2.重启命令：nginx -s reload3.进行命令：nginx -s stop查看目录：dir 清 cls 端口被占用1.查找过程id：netstat -ano|findstr "8080"2.基于过程id杀过程:taskkill /f /pid 过程id 配置http协定 所有服务都是写在http{}里 一个反向代理（每一个服务）就是一个server端口能够反复，域名不能反复…………………………………………………………………………………………………………/示意拦挡所有的门路root关键字 代理的是一个目录index关键字 示意要跳转的页面 所做的配置都要包裹在http{}里.则重启nginx #配置图片服务器 server{ listen 80; #虚构url server_name image.jt.com; location / { #转向目录 root D:/JT-SOFT/images; } }批改hosts文件没有则新建C:WindowsSystem32driversetc # 京淘配置 #左侧写IP地址 右侧写域名 两头应用空格分隔127.0.0.1 image.jt.com127.0.0.1 manage.jt.com127.0.0.1 www.jt.com#Bug 有时在应用该软件时可能会呈现失落字母的景象.127.0.0.1 sso.jt.com批改后必须刷新Windows开始 -> 运行 -> 输出cmd -> 在CMD窗口输出 ： ipconfig /flushdnsLinux终端输出 ： sudo rcnscd restartMac OS X终端输出 ： sudo killall -HUP mDNSResponder其余：断网，再开网；终极办法： 重启机器；Nginx实现tomcat集群部署 负载平衡服务器的反向代理 ...

在我的项目中有一个性能须要在浏览器页面中浏览服务器的目录。服务器应用Nginx，而Nginx提供了相应的ngx_http_autoindex_module 模块，该模块提供了咱们想要的性能。 Nginx ngx_http_autoindex_module 模块该模块有以下几个命令： 浏览目录根本配置依据下面的命令，一个简略的Nginx浏览目录的配置如下： location /download{ root /home/map/www/; #指定目录所在门路 autoindex on; #开启目录浏览 autoindex_format html; #以html格调将目录展现在浏览器中 autoindex_exact_size off; #切换为 off 后，以可读的形式显示文件大小，单位为 KB、MB 或者 GB autoindex_localtime on; #以服务器的文件工夫作为显示的工夫} 能够看到页面中的展现信息和配置想要的统一，但还有个问题是中文文件名显示的时候乱码。 中文文件名乱码要解决下面的问题，只须要增加如下配置即可： charset utf-8,gbk; #展现中文文件名 残缺配置如下： location /download{ root /home/map/www/; #指定目录所在门路 autoindex on; #开启目录浏览 autoindex_format html; #以html格调将目录展现在浏览器中 autoindex_exact_size off; #切换为 off 后，以可读的形式显示文件大小，单位为 KB、MB 或者 GB autoindex_localtime on; #以服务器的文件工夫作为显示的工夫 charset utf-8,gbk; #展现中文文件名} 文件列表的第一行是一个目录，点进去，展现如下： 略微有一点审美的同学是不是感觉这样展现不太好看呢？是的，很不美观，感觉乱哄哄的。上面就来解决这个问题。 目录浏览丑化咱们应用开源的Fancy Index来丑化页面，Github看这里 在丑化之前，须要装置Nginx FancyIndex模块。装置模块步骤如下。 ...

我的项目背景公司目前有一些接入到4G网络的树莓派，须要通过近程shell连贯对其进行治理和日常保护。然而这些设施没有固定的公网ip，所以须要通过内网穿透来解决。 筹备工作须要进行穿透的树莓派*N（咱们装置的是ubuntu 20零碎，以下操作命令均基于此零碎）一台具备公网IP/域名的服务器，零碎不限（咱们应用的是阿里云windows server）lanproxy架构原理这里大略讲一下过程，很多细节须要看后续步骤能力了解大体流程： 首先咱们在阿里云开启内网穿透lanproxy服务端，监听8000端口在阿里云上lanproxy控制台中，为一个树莓派创立密钥（启动客户端的时候须要用到这个密钥）并且指定一个对外端口10000客户端（树莓派）启动lanproxy客户端，连贯到阿里云8000端口，单方建设长连贯通过xshell连贯到阿里云10000端口，即可胜利连贯到该树莓派。注意事项： 以上提及的所有端口基于咱们公司理论我的项目填写，理论配置过程中能够随便填写。以上用到的服务器（阿里云）端口要在防火墙中凋谢，否则无奈应用架构图： PS：有的小伙伴可能会问，所有树莓派都连贯到同一个阿里云端口，那么服务端是靠什么来进行路由转发的呢？答案是密钥，这里会在下边的教程中提及。 部署过程1.装置服务端下载服务端–下载地址链接里边有好多文件，留神别弄混了，服务端的文件名为：proxy-server-0.1.zip将压缩包解压之后，首先关上conf/config.properties文件，内容如下： server.bind=0.0.0.0#客户端的连贯端口server.port=4900 server.ssl.enable=trueserver.ssl.bind=0.0.0.0server.ssl.port=4993server.ssl.jksPath=test.jksserver.ssl.keyStorePassword=123456server.ssl.keyManagerPassword=123456server.ssl.needsClientAuth=falseconfig.server.bind=0.0.0.0#服务端后盾界面端口号config.server.port=8090#后盾账号config.admin.username=admin#后盾明码config.admin.password=admin其中有两行特地容易混同的中央须要独自阐明 server.port=4900 config.server.port=8090其中server.port是服务端与被穿透设施通信时用到的端口（架构图中没有画出这个对应的端口），也就是我在上边架构图中画的8000端口。config.server.port是指服务端后盾界面端口，咱们部署完后，通过 localhost:8090即可拜访这个界面。近程端口（就是我上边提到的10000、10001、10002）不在配置文件中配置，须要去后盾界面中配置！ 以上内容能够依据须要批改。ssl局部因为咱们我的项目中没有用到，故不做解说。 启动服务端须要java运行环境，没有的须要自行装置一下！ 配置完后，应用bin/目录下的具体sh或bat文件启动我的项目。通过locathost:8090（如果你改端口了，就用自定义的端口）拜访后盾，而后依照如下图示操作。到此为止，咱们装置好了lanproxy客户端，并且配置了一台客户端的密钥和穿透端口。须要留神的是，以上用到的端口都须要在防火墙中对外开放（我用的阿里云，须要在阿里云后盾配置平安组策略）。 接下来咱们须要配置客户端。 2.装置客户端首先我筹备了一台装有ubuntu 20的树莓派（无桌面）。lanproxy筹备了用go编译号的客户端，应用起来非常不便。点击下载客户端 下载链接中， lanproxy-client-*结尾的都是客户端，须要依据本人的零碎抉择对应的版本。树莓派是arm架构的，所以我下载的是lanproxy-client-linux-arm.tar.gz，如果是应用桌面cpu的服务器（英特尔或amd），则须要下载lanproxy-client-linux-amd64-20190523.tar.gz或 lanproxy-client-linux-386-20190523.tar.gz（别离对应64位和32位机器） 应用树莓派获取压缩包并解压后，应用命令后盾启动程序 sudo nohup client_linux_arm7 -s 服务端IP或域名 -p 服务端端口 -k 密钥 &其中“服务端端口”指的就是方才配置文件中“server.port”字段指定的端口号 3.测试客户端启动后，登录lanprox控制台，在‘客户端治理’界面即可查看到设施的在线状态。 应用xshell进行连贯，输出公网的ip和端口号，则能够间接连贯到树莓派里边了。 优化树莓派增加客户端开机自启性能待实现 服务器增加服务端开机自启性能待实现

为了更直观的查看和下载文件，能够用nginx做成目录浏览设置全局的在http里设置保障和server同级http{ autoindex on; #开启nginx目录浏览性能 autoindex_exact_size off; #文件大小从KB开始显示 autoindex_localtime on; #显示文件批改工夫为服务器本地工夫 ............. }只关上网站局部（location ）目录浏览性能，这里有个坑，我在windows上root 中文的文件夹名字不行。mac上也一样location / { root ../../360Download; autoindex on; #开启nginx目录浏览性能 autoindex_exact_size off; #文件大小从KB开始显示 autoindex_localtime on; #显示文件批改工夫为服务器本地工夫}效果图

一、装置 Nginx(mac自带Nginx无需装置)终端执行： brew search nginxbrew install nginx装置完当前，能够在终端输入的信息里看到一些配置门路： /usr/local/etc/nginx/nginx.conf （配置文件门路）/usr/local/var/www （服务器默认门路）/usr/local/Cellar/nginx/1.6.2 （貌似是装置门路） 二、拜访localhost:8080Nginx 默认8080端口，这时曾经能够拜访了： localhost:8080会有一个默认欢送界面。 三、批改 php-fpm 文件1.执行命令：sudo cp /private/etc/php-fpm.conf.default /private/etc/php-fpm.conf 2.找到目录下的 php-fpm 文件/private/etc/php-fpm.conf 3.找到32行的 error_log ，改为（正行替换，留神 ‘;’ 和空格）：error_log = /usr/local/var/log/php-fpm.log 否则 php-fpm 时会报错 ERROR: failed to open error_log (/usr/var/log/php-fpm.log): No such file or directory (2) 四、批改 Nginx 配置1.关上 nginx.config 文件/usr/local/etc/nginx/nginx.conf2.找到 server 的 location 配置，给 index 加一个 index.phplocation / { root html; index index.html index.htm index.php;}3.并关上 server 下被正文的 location ~.php$（即删除代码后面的 ‘#’），如下：location ~ .php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; include fastcgi_params;}4.并批改 fastcgi_param 参数fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;改为fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;五、创立 index.php在 /usr/local/var/www 目录下，删除 index.html，创立 index.php，输出 ...

问题Nginx配置了缓存 发现Java HttpClient调用后 再次curl调用 却没有走缓存 Nginx-Cache: MISS起因抓包进行比拟 tcpdump tcp -i utun1 -tttt -s 0 and host api.ceicdata.com -vvvvcurl 2020-09-26 22:00:22.881052 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 342) 10.9.8.22.64092 > api.ceicdata.com.http: Flags [P.], cksum 0xfc9b (correct), seq 1:291, ack 1, win 2055, options [nop,nop,TS val 1025591764 ecr 3641213951], length 290: HTTP, length: 290 GET /v2//layout/tables/TB2992477/series HTTP/1.1 Host: api.ceicdata.com User-Agent: curl/7.54.0 Accept: */*HttpClient ...

很多软件不再反对python2 我也被迫应用python3了 所以应用pip3先装置certbot pip3 install certbot再装置certbot的nginx插件 pip3 install certbot-nginx因为nginx是本人装的 不在零碎变量里 新建软连贯 找不到nginx的配置会执行失败ln -s /usr/local/nginx/conf/ /etc/nginx申请证书在nginx失常运行的状况下，以下主动实现申请，须要替换 email@youremail.com ， domain.com 以及 -d 前面的域名为本人的域名： certbot --nginx --agree-tos --redirect \ -m email@youremail.com --eff-email \ --preferred-challenges http-01 \ --cert-name url.com \ -d url.com,xyz.url.com,www.url.com -qnginx配置文件里增加 ssl_certificate /etc/letsencrypt/live/www.url.com/fullchain.pem; # managed by Certbotssl_certificate_key /etc/letsencrypt/live/www.url.com/privkey.pem; # managed by Certbotssl_prefer_server_ciphers on;重启nginx 配置自动更新证书 30 03 01 * * certbot renew

由nginx权限有余引起， 解决： 终端执行： sudo nginx -s stopsudo rm -rf /usr/local/var/run/nginx/*sudo nginx详情见：https://stackoverflow.com/que...

302谬误景象:nginx在应用非80端口做反向代理时，浏览器拜访发现返回302谬误 解决方案: //如果是 proxy_set_header Host $host;//那么改成proxy_set_header Host $host:$server_post;//没有配置则加上proxy_set_header Host $host:$server_post;//以下为增加地位location ^/api { proxy_set_header Host $host:$server_post; proxy_pass http://127.0.0.1;}400谬误nginx400谬误是因为request header过大，通常是因为cookie中写入了较长的字符串所引起的。若cookie太大，可能还须要调整large_client_header_buffers(默认4k) 403谬误参考(403谬误解决)[https://rumenz.com/rumenbiji/...] 413谬误413 Request Entity Too Large上传文件过程中容易呈现这个问题,传递的某些数据大小超过了nginx的配置 解决方案： hhtp{ client_max_body_size 8M; //扭转这个值 client_body_buffer_size 128k; //缓冲区大小}如果后端是php 批改php.inipost_max_size = 8M upload_max_filesize = 6M重启php服务如果后端是SpringbootSpring Boot 1.3.x multipart.maxFileSize=8Mmultipart.maxRequestSize=8MSpring Boot 1.4.x and 1.5.xspring.http.multipart.maxFileSize=8Mspring.http.multipart.maxRequestSize=8MSpring Boot 2.xspring.servlet.multipart.max-file-size=8Mspring.servlet.multipart.max-request-size=8M414谬误414 Request-URI Too Large 申请的url太长了 解决方案: http{ client_header_buffer_size 512k; large_client_header_buffers 4 512k;}499谬误这是nginx定义的一个状态码，用于示意这样的谬误：服务器返回http头之前，客户端就提前敞开了http连贯 问题的外围就是要排查为什么服务端解决工夫过长 可能问题： 1.后盾python程序处理申请工夫过长 2.mysql慢查问 通过查看监控： 1.cpu和内存的应用，都在失常范畴 2.后台程序拜访失常 3.MySQL没有慢查问 ...

本地开发有时候须要调试动态文件资源，无奈间接拜访，能够通过配置本地Nginx服务的形式来进行，顺便记录一下Nginx的配置步骤 装置<!--通过 Brew 装置： -->brew install nginx<!--启动： -->brew services start nginx<!--查看配置： -->cat usr/local/etc/nginx/nginx.conf<!--编辑配置： -->vi usr/local/etc/nginx/nginx.confNginx命令： <!--启动：-->nginx<!--进行/重启-->nginx -s stop/start/restart配置文件文件地址： usr/local/etc/nginx/nginx.conf # 此处配置为root owner能力拜访root的动态文件，否则会报403user root owner;worker_processes 1;#error_log logs/error.log;#error_log logs/error.log notice;#error_log logs/error.log info;#pid logs/nginx.pid;events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; server { # 监听端口 listen 8080; # 绑定域名 server_name local.XXX.com; #charset koi8-r; #access_log logs/host.access.log main; #文件门路和入口文件 location / { root /usr/local/var/www; index index.html index.htm; } # 接口资源1 location /XXXapi/ { proxy_pass https://api.XXX.com; } # 接口资源2 location /apiXXX/ { proxy_pass https://api.XXX.com; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } include servers/*;}配置步骤装置Nginx通过SwitchHost绑定HOST (127.0.0.1 local.XXX.com)配置端口和域名# 监听端口listen 8080;# 绑定域名server_name local.XXX.com;指定入口文件和动态文件门路#文件门路和入口文件 location / { root /usr/local/var/www; index index.html index.htm; }如果有额定的API资源，通过proxy_pass绑定对应的API资源地址# 接口资源1location /XXXapi/ { proxy_pass https://api.XXX.com; }# 接口资源2location /apiXXX/ { proxy_pass https://api.XXX.com; }将动态文件放入Nginx配置的文件门路DONE，本地能够通过对应的HOST关上动态网站资源并拜访

上传文件时报 413 Request Entity Too Large如果应用了ngin动态转发：批改nginx.conf配置，在http{}中退出: client_max_body_size 3024m;而后重启nginx 后盾限度:springBoot在配置文件中增加： servlet: multipart: max-file-size: 3024MB max-request-size: 3024MB

大家都晓得，前段nginx做反代，如果后端服务器宕掉的话，nginx是不能把这台realserver提出upstream的，所以还会有申请转发到后端的这台realserver下面去，尽管nginx能够在localtion中启用proxy_next_upstream来解决返回给用户的谬误页面，办法在：http://www.linuxyan.com/web-s...首先去这里下载nginx的模块https://github.com/yaoweibin/...上面是nginx打上模块补丁的装置$ wget http://nginx.org/download/nginx-1.16.1.tar.gz’$ tar -xzvf nginx-1.16.1.tar.gz$ cd nginx-1.16.1/$ patch -p1 < /path/to/nginx_http_upstream_check_module/check.patch注：因nginx版本更新，1.2以上版本的nginx，补丁为check_1.16.1+.patch$ ./configure --add-module=/data/nginx_upstream_check_module-master --prefix=/data/nginx --with-http_stub_status_module --with-http_ssl_module --with-file-aio --with-http_realip_module --add-module=/data/brotli/ngx_brotli --add-module=/data/echo-nginx-module-0.61$ make$ mv /data/nginx/sbin/nginx /tpm/$ mv obj/nginx /data/nginx/sbin/之后在nginx.conf配置文件外面的upstream退出健康检查，如下： [root@81-nginx-test xxxx]# cat up.conf upstream ser{ip_hash;server 192.168.0.47:8090 max_fails=2 fail_timeout=10s;server 192.168.0.48:8090 max_fails=2 fail_timeout=10s;check interval=5000 rise=1 fall=5 timeout=4000;keepalive 20000;}这里上面加的这句话我解释下，interval检测间隔时间，单位为毫秒，rsie申请2次失常的话，标记此realserver的状态为up，fall示意申请5次都失败的状况下，标记此realserver的状态为down，timeout为超时工夫，单位为毫秒。 在server段外面能够退出查看realserver状态的页面 [root@81-nginx-test xxxx]# cat a.conf ####uat-skpay-backmanage.xxxx.comserver { listen 80; server_name back.xxxx.com; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; #add_header X-Frame-Options SAMEORIGIN; index index.html; access_log /data/ser.log; location / { if ($request_method !~ ^(GET|POST|PUT|DELETE|HEAD|OPTIONS)$) { return 403; } #proxy_pass http://service-backmanage_uat; #proxy_pass http://192.168.0.48:8090/backmanage/; proxy_pass http://ser; proxy_redirect off; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 16k; proxy_buffering on; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_max_temp_file_size 1024m; } location /nstatus { check_status; access_log off; allow all; }}####uat-skpay-backmanage.xxxx.comserver { listen 80; server_name dev-back.xxxx.com; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; #add_header X-Frame-Options SAMEORIGIN; index index.html; access_log /data/ser.log; location / { if ($request_method !~ ^(GET|POST|PUT|DELETE|HEAD|OPTIONS)$) { return 403; } #proxy_pass http://service-backmanage_uat; #proxy_pass http://192.168.0.48:8090/backmanage/; proxy_pass http://ser; proxy_redirect off; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 16k; proxy_buffering on; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_max_temp_file_size 1024m; } location /nstatus { check_status; access_log off; allow all; }} ...

一、编写脚本 vi /etc/init.d/nginx批改/etc/init.d/nginx代码如下： #!/bin/bash# nginx Startup script for the Nginx HTTP Server# it is v.0.0.2 version.# chkconfig: - 85 15# description: Nginx is a high-performance web and proxy server.# It has a lot of features, but it's not for everyone.# processname: nginx# pidfile: /var/run/nginx.pid# config: /usr/local/nginx/conf/nginx.confnginxd=/usr/local/nginx/sbin/nginxnginx_config=/usr/local/nginx/conf/nginx.confnginx_pid=/var/run/nginx.pidRETVAL=0prog="nginx"# Source function library.. /etc/rc.d/init.d/functions# Source networking configuration.. /etc/sysconfig/network# Check that networking is up.[ ${NETWORKING} = "no" ] && exit 0[ -x $nginxd ] || exit 0# Start nginx daemons functions.start() {if [ -e $nginx_pid ];then echo "nginx already running...." exit 1fi echo -n $"Starting $prog: " daemon $nginxd -c ${nginx_config} RETVAL=$? echo [ $RETVAL = 0 ] && touch /var/lock/subsys/nginx return $RETVAL}# Stop nginx daemons functions.stop() { echo -n $"Stopping $prog: " killproc $nginxd RETVAL=$? echo [ $RETVAL = 0 ] && rm -f /var/lock/subsys/nginx /var/run/nginx.pid}# reload nginx service functions.reload() { echo -n $"Reloading $prog: " #kill -HUP `cat ${nginx_pid}` killproc $nginxd -HUP RETVAL=$? echo}# See how we were called.case "$1" instart) start ;;stop) stop ;;reload) reload ;;restart) stop start ;;status) status $prog RETVAL=$? ;;*) echo $"Usage: $prog {start|stop|restart|reload|status|help}" exit 1esacexit $RETVAL:wq保留退出 ...

1、配置域名指向这台服务器IP；2、在nginx中配置两个server（端口都为：80）。 找到nginx.conf文件，并批改： vi /usr/local/nginx/conf/nginx.conf减少一个server，如下图： 名称简介listen端口server_name绑定域名location/root文件门路location/index默认首页

用超级治理身份操作 # 下载安装包wget http://nginx.org/download/nginx-1.12.2.tar.gz# 装置依赖yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel# 解压缩tar -zxvf nginx-1.12.2.tar.gzcd nginx-1.12.2/# 执行配置./configure# 编译装置(默认装置在/usr/local/nginx)makemake installnginx主配置文件：/usr/local/nginx/conf/nginx.conf nginx日志文件：/usr/local/nginx/logs/access.log 启动Nginx：/usr/local/nginx/sbin/nginx 如果是VMware虚拟机Linux下装置Nginx，如何在本地window上拜访？ 1、查看虚拟机的IP地址 [root@nginx nginx-1.18.0]# ifconfig 2、敞开防火墙 [root@localhost /]# cd ~[root@localhost ~]# service iptables stop[root@localhost ~]# chkconfig iptables off3、Windows下关上浏览器，拜访刚刚查看的虚拟机的IP地址，呈现以下页面示意拜访胜利。

语法： location [=|~|~*|^~] /uri/ { # ... }规定： / 结尾示意通用匹配（任何申请都会匹配到）= 结尾示意准确匹配^~ 结尾示意uri以某个惯例字符串结尾（如url门路）~ 结尾示意辨别大小写~* 结尾示意不辨别大小写!~ 结尾示意辨别大小写不匹配!~* 结尾示意不辨别大小写不匹配优先级： 首先准确匹配 = -> 其次以xx结尾匹配^~ -> 而后是按文件中程序的正则匹配 -> 最初是交给 / 通用匹配。 当有匹配胜利时候，进行匹配，按以后匹配规定解决申请。 示例： location = / { #规定1}location = /user { #规定2}location ^~ /static/ { #规定3}location ~ \.(gif|jpg|png|js|css)$ { #规定4，留神：是依据括号内的大小写进行匹配。括号内全是小写，只匹配小写}location ~* \.png$ { #规定5}location !~ \.html$ { #规定6}location !~* \.html$ { #规定7}location / { #规定8}欢送关注：http://fenxianglu.cn/

网页显示 403 ForbiddenNginx(yum 装置日志个别在/var/log/nginx/error.log) 谬误日志显示open() "/web/www/one.txt" failed (13: Permission denied), client: 192.168.1.110, server: rumenz.com, request: "GET /one.txt HTTP/1.1", host: "rumenz.com"总结四种起因: SELinux没有敞开Nginx启动用户和工作用户不统一网页所在的目录权限不对短少默认的首页解决方案: SELinux没有敞开1.1 长期敞开SELinux,然而重启操作系统还会开启 setenforce=01.2 永恒敞开SELinux vim /etc/selinux/config将SELINUX=enforcing 批改为 SELINUX=disabled 状态Nginx启动用户和工作用户不统一[root@rumenz#]ps aux | grep "nginx: worker process" | awk '{print $1}'nobodyroot批改Nginx 配置文件 vim /etc/nginx/nginx.conf将 user nobody; 批改为 user root; 重启Nginx留神:Nginx的启动用户和工作用户能够不统一,然而要配好网页目录的权限,让工作用户有拜访网页目录的权限网页所在的目录权限问题3.1 精密管制:网页根目录要用x权限(也就是能够cd进去),网页所在的父级目录要有r(可读权限)3.2 简略粗犷(不举荐,不平安,然而成果显著): chmod -R 777 /webchmod -R 777 /web/www短少默认的首页4.1 权限配完了,拜访首页还显示403 Forbidden?4.2 网页根目录提供一个默认的首页:index.html

上文简略介绍了一下nginx,本文说一下其实现. 官网示例想要通过nginx实现反向代理,次要须要进行conf目录下nginx.conf文件的配置: # nginx 须要应用http/https协定的http { #反向代理服务 一个服务就是一个server server { # nginx监听的端口号 默认监听80端口 listen 80; # server名称 业务逻辑名称 server_name localhost; # 反向代理实现 / 代表拦挡所有申请 location / { # root 转向到目录中 html index 默认拜访页面 root html; index index.html index.htm; } }}咱们次要设置的就是server{...},一个server代表一个服务,多个服务咱们就要配置多个server.上述代码可是实现一个简略的反向代理业务,拦挡localhost:80的申请,转到html目录下的index.html页面,是一个nginx自带的欢送页面. 实例1依据我的项目,我进行了如下配置: #配置图片服务器 server{ listen 80; server_name image.com; location / { #因为windows操作系统问题 所以须要/替换\ root D:/SOFT/images; } }这样就能够将我的项目中要拜访hhtp://image.com的申请跳转至本地的D:/SOFT/images目录上来保留/获取图片. 实例2下面的实例,只是再上传图片的反向代理,那咱们如果整个我的项目的登录都须要反向代理要怎么做?---须要通过hosts文件 hosts文件操作系统为了开发人员测试不便,能够通过hosts执行文件的域名与IP的映射关系.如果配置了hosts文件,则先走hosts之后执行寰球DNS域名解析服务. 操作系统为开发者提供了一个hosts文件.该文件能够实现域名与IP地址的映射关系.然而因为只是测试时应用.所以该配置只对本机无效. 个别hosts文件的门路为:C:WindowsSystem32driversetchosts hosts配置: 左侧写IP地址 右侧写域名 两头应用空格分隔 如:127.0.0.1 image.com ...

简介以下为百度的介绍:Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点（俄文：）开发的，第一个公开版本0.1.0公布于2004年10月4日. nginx能够作为反向代理服务器/负载平衡服务器/电子邮件服务器等.Nginx在各大网站中都有利用.开源收费的. 特点:1.占用内存少 服务启动时不超过2M C语言开发的2.并发能力强 tomcat服务器并发能力 150-220个/秒 nginx 3-5万/秒 咱们这么学习次要是要应用Nginx作为反向代理服务器.所以咱们就须要理解什么是反向代理! 反向代理 总结一下: 正向代理是客户端代理,用户分明的晓得拜访的服务器是谁. 爱护了客户端信息反向代理是服务器端代理.用户不分明拜访的实在服务到底是谁. 爱护了服务端信息Nginx装置及应用装置将nginx解压到本地磁盘目录中.启动nginx:进入nginx控制台: 在nginx.exe根目录下cmd执行命令常用命令: 命令1: 启动nginx: start nginx命令2: 重启nginx: nginx -s reload命令3: 敞开nginx: nginx -s stopnginx启动项阐明:每次启动nginx服务时会启动2个过程项(多个线程)nginx守护过程: 避免主过程意外敞开的. 如果意外了则重启主过程.nginx主过程: 次要提供反向代理服务.nginx不能失常启动的阐明dos命令: netstat -ano80端口被PID=4的给占用的!! 零碎驱动等问题占用了80端口注意事项nginx因为底层实现用C语言写的,所以要求装置目录中不要呈现中文/空格等字符.计算机名称如果是中文的 须要改为英文装置nginx时因为权限的问题,不要放到C盘的系统文件中.Nginx启动时会占用80端口..

别离应用 alias 和 root 配置拜访 b.html 1.1 root->url追加到root后定位nginx中的root配置: location ^~ /app1/ { root /web;}# 拜访: localhost/app1/b.htmlb.html 在服务器的目录: /web/app1/b.html拜访时url是什么? localhost/app1/b.html拜访url映射到哪里? /app1/b.html：root+location 映射： /web/app1/b.html 1.2 alias->url被alias替换nginx中的alias配置: location ^~ /app2/ { alias /web;}b.html目录: /web/b.html拜访: localhost/app2/b.html论断: 相当于替换b.html 在服务器的目录: /web/b.html拜访时url是什么? localhost/app2/b.html (url和下面相似)拜访url映射到哪里? /app2/b.html：alias替换location 映射： /web/b.html 1.3 小结alias:location的uri会被alias的替换;root:location的uri会追加到root的前面连起来;

关注公众号“执鸢者”，获取大量教学视频并进入业余交换群，回复“nginx”获取本节思维导图。 小林通过层层面试，终于进入一家一线互联网公司。有一天，她的mentor给她安排了一个工作，让她配置一下nginx，小林是一脸懵逼，您说啥？nginx是啥？心里一万只草泥马呼啸而过，然而刚强的小林没有放弃，筹备零碎的理解一下nginx，而后开启了打怪降级的路线。对于Nginx的学习，小林次要从六局部进行：根底、原理、常用命令、配置文件、用处及相干计算，由浅入深，层层递进，最终达到前端够用、运维入门的成果。心愿通过本博文帮忙不懂Nginx的同学疾速学习Nginx。 一、根底 二、原理 三、常用命令 四、配置文件 本节中的指令、变量不全，只是罕用的一些，本人能够下载思维导图而后进行保护。4.1 组成 4.2 每个块都可呈现的指令 4.3 内置变量 4.4 应用 五、用处 5.1 Web服务器 5.2 正向代理 5.3 反向代理 5.4 负载平衡 5.5 动静拆散 六、一些计算 欢送大家关注公众号(回复“nginx”获取本节的思维导图,回复“书籍”获取大量前端学习材料,回复“前端视频”获取大量前端教学视频)

CentOS Linux 零碎应用 yum 装置的 Nginx 短少一些须要的模块，只能用编译的形式来解决，记录一下装置过程。 首先须要用 yum 装置零碎依赖： sudo yum install -y gcc make \ pcre-devel perl-ExtUtils-Embed openssl-devel而后下载 nginx 源码: wget -c http://nginx.org/download/nginx-1.18.0.tar.gz解压并进入源码目录并按本人的需要执行编译操作： tar zxvf nginx-1.18.0.tar.gzcd nginx-1.18.0./configure --prefix=/usr/local/nginx \ --user=zzxworld \ --group=zzxworld \ --with-http_perl_module \ --with-http_ssl_module \ --with-http_v2_modulemakesudo make install编译实现后，就能够应用 /usr/local/bin/bin/nginx 来治理 Nginx 了。不过更好的形式是应用 Systemd 服务。将 Nginx 接入 Systemd 也很简略，在 /usr/lib/systemd/system/ 目录创立一个 nginx.service 文件，内容如下： [Unit]Description=The NGINX HTTP and reverse proxy serverAfter=syslog.target network-online.target remote-fs.target nss-lookup.targetWants=network-online.target [Service]Type=forkingExecStartPre=/usr/local/nginx/sbin/nginx -tExecStart=/usr/local/nginx/sbin/nginxExecReload=/usr/local/nginx/sbin/nginx -s reloadExecStop=/usr/local/nginx/sbin/nginx -s quitPrivateTmp=true [Install]WantedBy=multi-user.target而后就能够应用 systemctl 命令来治理 Nginx 了。 ...

nginx下反向代码 apache 下的 wordpress启用证书后的数据流大体如下： 因为wordpress在接管到申请后会进行：以后申请信息是否与数据库中设置的以后网站地址相一致。从而导致在进行数据转发时因为在nginx层面产生了https与http的转换，进而导致了301的问题。对应下面的数据流，对应的流程如下： 如果把wordpress中的网站地址变更为：http://www.codedemo.club，则因为在判断协定的时候http与http雷同，则不会产生301的谬误。但因为wordpress外部发送动态资源地址时，地址上退出了网站前缀，比方发送的CSS地址为：http://www.codedemo.club/sytle.css，而非/sytle.css。这将触发一个浏览器的一个爱护机制 ---- 浏览器阻止：在一个https的页面上调用http申请。 吐个槽：话说学校某教学相干的零碎正是因为在https页面上加载了http插件，从而导致一些EXCEL的导出无奈失常工作了。解决方案联合上文形容以及在因为定制端口导致的301重定向问题一文中的剖析，得出以下论断：若要防止wordpress的301问题，则必须保障转发给wordpress的域是雷同的。 又因为域雷同的三要素是：协定、域名、端口号。所以最终的论断是：若要防止wordpress的301问题，则必须保障转发给wordpress的协定、域名、端口号都是雷同的。 nginx+apache全面启用https在apache中启用https，nginx在进行转发时将数据按apache的证书进行加密后，传给apache服务： 以上便保障了拜访wordpress时协定也是https的。 这个计划最大的问题在于须要别离对nginx、apache配置证书。nginx在进行数据转发时，进行了数据的解密与加密，apache又从新对数据进行了一次解密。从效率上来讲必定是最低的，当然也是最不值得举荐的计划。 批改wordpress源码另一种计划是在nginx将以后协定通过header转发。wordpress判断转发的header信息中协定是否为https。如果为https则重置零碎变量，从而让wordpress误认为以后的http申请为https申请：修改文件为：wp-config.php define( 'WP_DEBUG', false ); + if ( $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' )+ { + $_SERVER['HTTPS'] = 'on';+ $_SERVER['SERVER_PORT'] = 443;+ }本计划须要对wordpress源码进行批改，尽管解决了问题，但仍有待欠缺。

nginx下反向代码 apache 下的 wordpress启用证书后的数据流大体如下： 因为wordpress在接管到申请后会进行：以后申请信息是否与数据库中设置的以后网站地址相一致。从而导致在进行数据转发时因为在nginx层面产生了https与http的转换，进而导致了301的问题。对应下面的数据流，对应的流程如下： 如果把wordpress中的网站地址变更为：http://www.codedemo.club，则因为在判断协定的时候http与http雷同，则不会产生301的谬误。但因为wordpress外部发送动态资源地址时，地址上退出了网站前缀，比方发送的CSS地址为：http://www.codedemo.club/sytle.css，而非/sytle.css。这将触发一个浏览器的一个爱护机制 ---- 浏览器阻止：在一个https的页面上调用http申请。 吐个槽：话说学校某教学相干的零碎正是因为在https页面上加载了http插件，从而导致一些EXCEL的导出无奈失常工作了。解决方案联合上文形容以及在因为定制端口导致的301重定向问题一文中的剖析，得出以下论断：若要防止wordpress的301问题，则必须保障转发给wordpress的域是雷同的。 又因为域雷同的三要素是：协定、域名、端口号。所以最终的论断是：若要防止wordpress的301问题，则必须保障转发给wordpress的协定、域名、端口号都是雷同的。 nginx+apache全面启用https在apache中启用https，nginx在进行转发时将数据按apache的证书进行加密后，传给apache服务： 以上便保障了拜访wordpress时协定也是https的。 这个计划最大的问题在于须要别离对nginx、apache配置证书。nginx在进行数据转发时，进行了数据的解密与加密，apache又从新对数据进行了一次解密。从效率上来讲必定是最低的，当然也是最不值得举荐的计划。 批改wordpress源码另一种计划是在nginx将以后协定通过header转发。wordpress判断转发的header信息中协定是否为https。如果为https则重置零碎变量，从而让wordpress误认为以后的http申请为https申请：修改文件为：wp-config.php define( 'WP_DEBUG', false ); + if ( $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' )+ { + $_SERVER['HTTPS'] = 'on';+ $_SERVER['SERVER_PORT'] = 443;+ }本计划须要对wordpress源码进行批改，尽管解决了问题，但仍有待欠缺。