Nginx

倒退Nginx 的开发始于 2002 年，由 Igor Sysoev 发动，最后是为了解决 C10K 问题，即如何让一个服务器同时解决超过一万个客户端连贯。 第一个公开版本公布于 2004 年 10 月。自此，Nginx 此开始了它的疾速倒退。Nginx 目前是世界上应用最多的 Web 服务器之一，依据 Netcraft 的统计，截至 2024 年 2 月，Nginx 占据了寰球 Web 服务器市场的 32.8% 的份额，仅次于 Apache。 装置与治理支流 Linux 发行版的包管理工具都反对下载 nginx，这里以 Manjaro 为例： sudo pacman -S nginxNginx 可通过-s参数响应一些自带的信号，比方： stop：立刻敞开quit：失常敞开reload：从新加载配置文件reopen：从新关上日志文件例如，当咱们在etc/nginx/conf.d中批改配置文件增加 Web 服务时，改变内容并不会间接失效，须要咱们重启 nginx 服务或者应用-s reload指令传递从新加载配置文件的信号。 此外，咱们能够通过systemctl等指令治理本地的 Nginx 服务，比方最常见的查看 Nginx 状态的指令： systemctl status nginxNginx配置文件构造在正式介绍之前，我想要先从 nginx 配置文件动手，这可能会更加便于了解，毕竟配置文件是咱们接触 nginx 最间接的中央。 Linux 下 nginx 配置文件的默认地位是在/etc/nginx/nginx.conf，这里先举一个简略的例子： # 全局块user nobody; # 指定运行nginx服务的用户和用户组worker_processes 1; # 指定工作线程数error_log logs/error.log; # 指定谬误日志的门路和级别pid logs/nginx.pid; # 指定pid文件的门路# events块events { worker_connections 1024; # 指定每个工作过程能够同时开启的最大连接数}# http块http { # http全局块 include mime.types; # 引入MIME-Type定义文件 default_type application/octet-stream; # 设置默认的MIME-Type sendfile on; # 开启sendfile传输文件的优化 keepalive_timeout 65; # 设置连贯超时工夫 # server块 server { # server全局块 listen 8000; # 监听8000端口 server_name localhost; # 设置虚拟主机的名称 # location块 location / { root html; # 设置根目录的门路 index index.html index.htm; # 设置默认的首页文件 } # location块 location /images { root /data; # 设置图片资源的门路 autoindex on; # 开启目录浏览性能 } # location块 location ~ \.php$ { root html; # 设置PHP文件的门路 fastcgi_pass 127.0.0.1:9000; # 设置PHP-FPM的地址和端口 fastcgi_index index.php; # 设置默认的PHP文件 fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; # 设置PHP脚本的残缺门路 include fastcgi_params; # 引入fastcgi的配置文件 } }}全局块：从开始到events块之间的局部，次要设置一些影响 nginx 服务器整体运行的配置指令，例如user，worker_processes，error_log，pid等。events块：波及的指令次要影响 nginx 服务器与用户的网络连接，例如worker_connections，accept_mutex，multi_accept，use等。http块：蕴含http全局块和多个server块，代理、缓存和日志定义等绝大多数的性能和第三方模块的配置都能够放在这个块中。http全局块是不蕴含在server块中的局部，次要设置一些影响http协定的配置指令，例如include，default_type等。server块是虚拟主机的配置，每个server块能够蕴含server全局块和多个location块。server全局块是不蕴含在location块中的局部，次要设置一些影响虚拟主机的配置指令，例如listen，server_name等。location块是 URL 匹配的配置，每个location块能够蕴含一些针对特定申请的解决规定，例如root，index，proxy_pass等。从不便了解的角度，每个server块就对应一个利用，而location能够了解为利用对应的路由。个别状况下，咱们想要在本人的服务器中新增某个 Web 利用配置，就在http块中增加server块即可。 ...

在 MacOS 上应用 homebrew 装软件是个司空见惯的行为，他会主动配置好依赖和各种环境，十分不便便捷。在装置 NGINX 的时候只须要执行 brew install nginx 指令就能够了。同时通过 homebrew 的 brew services 指令治理各种服务的启停也很不便。 然而最近在搞 nginScript （以下简称 njs ）的时候却遇到了很大的问题：无奈编译进去 njs 的二进制模块，且没有任何参考文档，仿佛除了齐全从二进制编译 NGINX 以外别无他法，想要用 njs 就只能放弃应用 homebrew 进行装置治理。同时官网上有些步骤应用的指令也有些过期了。 通过集体解读源码及肯定的大胆尝试后发现了另外一条路，本文只谈操作，背地的原理和心路历程不再赘述，感兴趣的小伙伴多的话也能够另开一篇文章写一写。 下载源码首先须要下载下来 NGINX 和 njs 模块的源码。 # 官网文档中应用 hg 下载源码hg clone http://hg.nginx.org/nginxhg clone http://hg.nginx.org/njs# 集体摸索发现 NGINX 组织在 GitHub 有个镜像git clone git@github.com:nginx/nginx.gitgit clone git@github.com:nginx/njs.git# 如果没有配置 GitHub ssh key 的话就应用上面的命令 clonegit clone https://github.com/nginx/nginx.gitgit clone https://github.com/nginx/njs.git下载下来源码后进入 NGINX 的源码目录 cd nginx切换 tag 到 homebrew 装置的版本 ...

工夫线2019 年 3 月 11 日，F5 Networks 发表以 6.7 亿美元收买 Nginx。 2022.01.18, NGINX 创始人 Igor Sysoev 从 NGINX 和 F5 到职：“Igor Sysoev 抉择来到 F5，以便将更多的工夫留给陪伴家人和敌人，以及集体我的项目。感激他所做的所有让全世界的网站变得更好。” 在 2024.4.14 情人节这天，作为 nginx 的长期外围开发者之一，马克西姆-杜宁（Maxim Dounin）发表创立一个名为 Freenginx 的新分叉我的项目。 他在发表 Freenginx 时说道"你们可能晓得，F5 于 2022 年敞开了莫斯科办事处，从那时起我就不再为 F5 工作了。 不过，咱们曾经达成协议，我将持续作为志愿者参加nginx开发。在近两年的工夫里，我始终致力于改良nginx，收费为大家提供更好的nginx。可怜的是，F5一些新的非技术管理人员最近决定干预nginx多年来应用的安全策略，忽视策略和开发者的立场。 这很好了解：他们领有这个我的项目，能够对其做任何事件，包含以市场为导向的行为，忽视开发者和社区的立场。 不过，这还是与咱们的协定相矛盾。 更重要的是，我无奈再管制F5外部对nginx的批改，也不再将nginx视为一个为公众利益开发和保护的自在开源我的项目。 因而，从今天起，我将不再参加F5经营的nginx开发。 取而代之的是，我将启动另一个我的项目，由开发者而非公司实体运行。 指标是使nginx开发不受公司任意行为的影响。 欢送提供帮忙和奉献。 心愿大家都能从中受害。 freenginx.org上的简短申明freenginx.org的指标是使nginx的开发不受任意公司行为的影响。开源和商业利益与指标不同决定了开源我的项目的不同倒退方向，这不好评说好坏对错。 作为商业公司，F5毕竟真金白银花了那么多钱领有了nginx，全职人员的老本付出，这必定须要往商业化方向考量，心愿能找到商业与开源的均衡。 Maxim Dounin 有着开发者的自在现实园，站在开发者和开源使用者的角度看开源我的项目的倒退，nginx 能更凋谢更自在，方向由社区掌控。也真心心愿 freenginx 能倒退顺利。 oracle-jdk vs openjdk, mysql vs mariadb, 当初有了 nginx vs freenginx, 咱们当初能够开始关注 Freenginx 的将来倒退，看将来有多少其余开发者会专一于这个新的分叉。 ...

在前端生态中，代理服务扮演着重要的角色。代理服务是指一种中间层服务，用于在前端应用程序和后端服务器之间进行申请转发和数据交互。它能够提供以下性能和劣势： 跨域申请：代理服务能够解决浏览器的同源策略限度，使前端利用能够从不同的域名或端口申请数据。通过代理服务，前端利用能够将申请发送到同一域名下的代理服务器，并由代理服务器转发到指标服务器，从而防止跨域限度。安全性和隐衷爱护：代理服务能够在前端和后端之间充当平安屏障，暗藏后端服务器的实在地址和细节。通过代理服务，能够实现平安的数据传输、身份验证和访问控制，爱护后端服务器的安全性，并提供额定的隐衷爱护。缓存和性能优化：代理服务能够缓存动态资源或响应后果，以加重后端服务器的负载，并进步前端利用的性能。通过在代理层缓存数据，能够缩小对后端的申请次数，放慢响应速度，并缩小对网络带宽的占用。申请转发和路由：代理服务能够依据特定的规定和条件将申请转发到不同的后端服务器，实现申请的负载平衡、路由和散发。这使得前端利用能够灵便地依据需要将申请发送到不同的服务实例或后端集群。日志记录和监控：代理服务能够记录申请和响应的日志，并提供监控和剖析性能。通过代理服务，能够收集对于申请流量、性能指标和谬误日志的信息，帮忙进行故障排查、性能优化和系统监控。总而言之，代理服务在前端生态中扮演着要害的角色，提供了跨域申请、安全性、性能优化、申请转发和监控等性能。它在构建古代前端利用中施展着重要作用，帮忙开发人员解决跨域问题、进步性能并提供更好的用户体验。 装置nginx这里咱们以 nginx/1.12.2 为例。须要获取源码： $ cd /opt/$ wget http://nginx.org/download/nginx-1.12.2.tar.gz$ tar -zxvf nginx-1.12.2.tar.gz编译装置 $ cd /opt/nginx-1.12.2/$ sudo make -j2$ sudo make installmake install 后，会笼罩之前装置的 Nginx。Mac 通常会装置在 /usr/local/ 目录下。 Nginx配置反向代理在 Nginx 中配置反向代理非常简单。上面是一个根本的反向代理配置示例： 编辑 Nginx 配置文件： $ sudo vim /usr/local/nginx/conf/nginx.conf 增加如下配置项： server { listen 80; server_name example.com; location / { proxy_pass http://backend_server; }}启动 Nginx： $ sudo /usr/local/nginx/sbin/nginx如果曾经启动了，执行上面命令从新加载配置文件： $ sudo /usr/local/nginx/sbin/nginx -s reload如果想要进行服务，执行上面命令： $ sudo /usr/local/nginx/sbin/nginx -s stop在上述示例中，咱们创立了一个服务器块（server block），监听 example.com 的端口 80。在 location / 块中，咱们应用了 proxy_pass 指令将申请代理到名为 backend_server 的后端服务器。 ...

window命令start nginx // 开机启动，不要应用 ./nginx会失落光标./nginx -s reload //重启./nginx -s stop 进行./nginx -t 配置是否正确前端部署单文件index.html<!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Document</title></head><body> index</body></html>nginx.confworker_processes 1;events { worker_connections 1024;}http { server { listen 80; location / { root html; index index.html index.htm; } }}成果 vueCli我的项目根门路vue我的项目配置 nginx.confworker_processes 1;events { worker_connections 1024;}http { server { listen 80; location / { root html; index index.html index.htm; } } server { # //不能写80 listen 81; location / { root html/app; index index.html index.htm; } }} ...

NGINX 在线配置调试工具在线调试地址背景：学习 nginx 最头痛的问题在与，解析过程不可见，经常因成果不合乎配置预期而懊恼，只能无脑尝试解决。或者网上上翻阅各种教程，理解各个命令优先级，过程简单繁琐nginx 个别放在 linux 服务器中，建设文件夹测试，查看日志都较为简单，测试过程操作繁琐而且个别 nginx 配置一次就不会常常改，学习老本高，刚学会，没有得使用就很容易遗记因而，如果能有一个工具，解析 nginx 的运行流程，是先通过那个命令，再通过那个命，零碎的拜访门路是怎么样的，那就直观很多性能介绍：所见即所得，提供 location 配置编写处，点击测试按钮，即可将该配置动静生成并设置测试文件夹，测试目录提供了做 nginx 做配置测试时，服务器可用的目录提供测试门路入口，发动测试主动拜访该门路，直观测试 nginx 配置成果右侧是该测试门路状况的成果，返回拜访到的资源文本，直观显示申请后果左下角展现 nginx 在该申请过程中，各个罕用变量的值，直观理解 nginx 的可用变量，以便应用变量右下角展现 nginx 在解析该门路的过程，十分具体，应用 try_files 的各个 try 过程都能展现

知识点1、如何进入nginx容器// 通过exec命令能够进入到镜像外面。 docker exec -it nginx-alpine /bin/sh // 退出镜像 exit这里须要留神下，如果是规范的nginx镜像，个别是通过 docker exec -it nginx01 bash 来进入到镜像外面。 所以当通过 bash 进不去的时候，可换成其余命令试试。 比方：docker exec -it nginx-alpine sh 因为Dockerfile没有设置WORKDIR，所以进去后就到根目录了。而且因为以后的nginx镜像是alpine版本，进去后用不了 ll 命令，只能是 ls 命令。相当于精简了一些命令。 nginx配置文件在/etc/nginx 2、把文件从宿主机拷贝到容器外面详情： 构建nginx镜像的知识点

nginx 装置njs 模块yum install nginx-module-njs援用 njs 模块// nginx.conf load_module modules/ngx_http_js_module.so; events {} http { server {}}运行// nginx.conf load_module modules/ngx_http_js_module.so; events {} http { js_path "/etc/nginx/njs/"; js_import index.js; server { listen 80; location / { js_content index.hello; } }}// /etc/nginx/njsfunction hello(r) { r.return(200, "Hello world, index!");}export default { hello };

一、HTTP的身份验证HTTP提供了一个用于权限管制和认证的通用框架。 流程如下：1、用户第一次通过客户端拜访页面，服务器端向客户端返回401状态码，并在WWW-Authenticate响应头阐明验证的信息。 2、客户端收到相应后，弹窗让用户输出用户名和明码。 3、用户输出后，客户端通过编码或加密的形式，把用户名和明码通过Authorization申请头发送给服务端。 4、服务端验证通过，则返回200状态码，不然则返回401状态码。 流程图如下所示： 详情： nginx配置auth_basic，要求账号密码的原理

As we all know, Nginx is a very popular reverse proxy server. It is very stable and has a lot of features. But I choose Traefik instead of Nginx as a reverse proxy in test environment since it is more suitable for my use case. In this post, I will explain why I choose Traefik instead of Nginx. BackgroundI have a test environment which is running on a single server. It has a lot of services running on it. I want to expose these services to the internet. So I need a reverse proxy server to do this. I am used to using Swag as a reverse proxy for years, witch is based on Nginx. But it is a little bit hard to configure. So I want to find a better solution. ...

背景有些材料，须要随时能够通过外网拜访到。服务器有了，材料也上传到服务器了。 但又不想谁都能拜访，也不想搞个登录模块那么简单，所以就有了这个需要。 论断通过nginx配置auth_basic来实现简略的登录拜访性能 步骤1、生成用户名和明码的文件三种形式来创立文件和明码： 第一种形式，通过-c命令，执行后会提醒输出明码。 第二种形式，要先创立文件，而后通过-b命令，执行的时候带上用户名和明码，而不会再提醒输出明码。 详情： 拜访nginx服务，要求账号密码

前言微信小程序在生产环境必须应用域名发动HTTPS申请。这就须要配置HTTPS。通常咱们的nginx配置文件能够很简略，只须要配置证书和私钥就行： ssl_certificate your.server.domin.cer;ssl_certificate_key your.server.domin.key;此时，应用浏览器发动申请时，曾经能够看到小锁了，相似这样： 但应用微信小程序发动申请时，就可能遇到玄学问题： 在开发工具里能够失常发动申请真机调试时，无奈向后盾发动申请，提醒"errno":600001因为手机型号和零碎不同，甚至呈现“有的手机能够拜访但有的不行”的状况本文来解决这个问题。 起因剖析先贴出残缺的控制台信息： {"errno":600001,"errMsg":"request:fail errcode:-202 cronet_error_code:-202 error_msg:net::ERR_CERT_AUTHORITY_INVALID"} 简略翻译一下就是：证书验证失败。 这个时候就纳闷了：明明我浏览器曾经提醒平安了啊？怎么微信小程序就不行了呢？ 去查这个600001错误代码，确实有其他人遇到过，比方这个问答：https://developers.weixin.qq.com/community/develop/doc/000408... 但网上查不到十分有价值的信息，只是晓得可能是“证书链”的问题，在官网文档对于HTTPS证书这一块有这些要求： 其中有一条就是证书信赖链必须残缺。 那么怎么查呢？ 这个网站 https://myssl.com/ 提供了证书检测的性能。 HTTPS是工作在应用层的，所以必须输出"协定+域名+端口"而不是"协定+域名" 对于一个小程序连不上的后盾地址，会提醒证书评级为B级，并且证书链不残缺： 的确是证书的问题。 那么怎么解决呢？ 解决对于通过acme自动化部署的证书，部署时会生成一组文件，包含： ca.cer——颁发机构CA的证书fullchain.cer——残缺证书链your.domin.cer——本级域名证书your.domin.key——本级域名私钥可能还有其余文件，但咱们只须要钻研这几个就能够了。 通常直觉上一看，your.domin.cer和your.domin.key这俩文件齐刷刷的，必定就是这俩了。 这样的确能够，而且浏览器也认可这个证书，然而小程序不认。 证书链不残缺的意思就是：只加载了本级域名的证书但没有加载CA的证书。这就是小程序不能用的间接起因。 另外，如果咱们输入your.domin.cer、ca.cer、fullchain.cer，就会惊奇的发现，fullchain.cer就是后面两个文件内容连起来，看图： ca.cer: domin.cer: fullchain.cer（留神看，这里是两段）: 所以，fullchain = ca + yourdomin 论断很简略，如果你部署证书的文件夹中有两段的fullchain.cer文件，就用这个文件作为证书；如果某些证书发放机构没有给出残缺的证书链，就把yourdomin和ca这两个文件拼起来作为证书。 这样一波操作之后，再检测一下证书，就是A级了： 此时小程序也能够拜访失常。 总结浏览器只须要有证书和私钥就能通过认证，但小程序多认证了一个证书链残缺的证书链包含本级域名的信息和CA的信息如果nginx只加载本级域名证书，而没有CA的证书，就是证书链不残缺，证书评级是B，就会呈现“网页能拜访但小程序提醒不平安”的问题解决办法就是应用残缺的证书链，能够应用颁发机构生成的，也能够手动拼接本文只公布segmentfault，禁止转载，如在其余平台看到请举报。

最近搭建了一个网站当前，总感觉裸奔的网站十分不平安，须要加上防护措施。加一套 waf 防火墙，而后就能够安心的睡觉了。因为服务器应用了宝塔1治理，所以我须要既能跟宝塔一起用的 waf。 先说论断宝塔自带 waf 免费；宝塔软件商店里 waf 要么不适合，要么门槛太高，不好用；其它收费 waf 大多要命令行装置，施展不了宝塔劣势。最好是有一个能在宝塔 docker 上运行的防火墙，既能用宝塔治理服务状态，又能有本人治理界面的 waf，而且要收费，还得无效。所以，我最初抉择用 docker compose 模板 + 雷池 waf 社区版。装置办法参考我的另一篇文章 https://www.jianshu.com/p/978e08095628 waf 比照宝塔内置 waf既然用宝塔做服务治理，第一反馈就是在宝塔上找找没有适合的 waf。在十分显眼的中央，找到了 “防火墙” 入口，而后看到了十分显眼的 “立刻购买”。本着来都来了的想法，看了一下官网防火墙的性能介绍2，性能还是十分多的，各位看官有钱的捧个钱场，我只能捧集体场。 另外依据文档介绍，nginx 防火墙是基于 Lua 实现的，也就是说这个防火墙的实质是人工规定，人工规定防火墙在防护能力上能够抵挡常见攻打，只能亡羊补牢不能防患未然。宝塔内置 waf 还有一个 Apache 版本3，与 nginx 相似，只是一个基于 Apache 一个基于 Nginx，这两者的差异见仁见智，宝塔官网举荐的是 nginx 版本。 宝塔软件商店中的收费 waf宝塔自带了一个软件商店，抱着试试看的态度搜了一下，还真找到了 3 款 waf。前两个是官网内置的免费版，第 3 个则是免费版。这一看，不得了啊，这是打算跟官网同台竞技啊。连忙装上试试。 感激作者 “民国三年一场雨”，民国三年就是 1914年，一百多年过来了，也不晓得雨里产生什么。思考到这个利用只有 403.95k 大小，总感觉这个性能可能没有想的那么多。 依据配置界面，启用防护，而后试着发动一次攻打申请，而后被拦挡了。后盾治理界面看到的成果记录是 拦挡成果是 拦挡页面上还有提醒，误报请分割宝塔 http://www.bt.cn/bbs？这不是官网 waf 么？为什么非要假装一下本人？在一个荫蔽角落还找到一个“教程”链接4，发帖人是宝塔技术-小强5，这下是官网的收费 waf 没跑了。 另外我还发现，这个收费防火墙，在软件商店里浏览的时候是找不到的，必须搜寻能力搜进去。所以，其实，人家是不心愿你持续应用这个 waf 的。并且在应用时，还遇到了其它问题 治理界面不好找我须要先进利用商店，搜寻 waf，而后找到之后，在通过 “设置” 按钮进入。 ...

明天咱们要演示如何在微软的 Azure 云上部署自主部署版的 OpenResty XRay。视频演示中用到的命令阐明，详见文档。创立订阅和资源组第一步咱们要创立订阅和资源组，关上 Azure 首页，点击订阅图标。这里咱们曾经提前创立好了订阅，名字叫 Azure subscription 1。再返回 Azure 首页。筹备创立资源组，点击资源组图标。这里咱们曾经创立好了资源组，名字叫 AKS。资源组 AKS 隶属于刚刚创立好的订阅 Azure subscription 1。创立 Azure Kubernetes 服务第二步，咱们来创立 Azure Kubernetes 服务。咱们返回 Azure 首页，点击 Kubernetes 服务图标。点击创立按钮，抉择创立 Kubernetes cluster。抉择刚刚创立好的资源组，名为 AKS。这里抉择群组的配置，这里依照本人的需要抉择即可。这里依据需要来抉择节点的大小。其余的配置依据本人的需要调节，而后点击 Review + Create 即可。 期待部署实现。 立刻申请收费试用 OpenResty XRay筹备环境变量第三步，筹备前面要用到的环境变量。关上一个终端，登录 Linux 机器。咱们应用 .env.sample 文件来做演示。这些环境变量的应用阐明详见文档。通过命令行登录 Azure第四步，通过命令行登录 Azure。留神，咱们须要当时装置好 Azure 的命令行工具 az。具体装置文档详见 Azure 官网文档这里咱们应用 az login 命令，关上提醒的 URL。登录胜利后，界面如下：执行 az account 命令绑定订阅。 接下来，执行 az aks 命令，获取 Kubernetes 的拜访配置。为 Kubernetes 创立 namespace 和 secret第五步，为 Kubernetes 创立 namespace 和 secret。先创立 Kubernetes namespace。再创立 Kubernetes Secret。创立 Azure Disk第六步，创立 Azure Disk。先获取节点的资源组名称。再应用命令创立 Azure Disk。应用雷同的命令创立要应用的多块硬盘，这些命令在咱们的文档中都有阐明。更新长久化卷的配置文件第七步，更新长久化卷的配置文件。这一步应用咱们提供的配置文件即可。获取节点的资源组名称。用 sed 命令替换长久化卷的的配置。更新 kubernetes 的配置文件第八步，更新 kubernetes 的配置文件。XRAY_CONSOLE_HOST 变量是部署好 OpenResty XRay 服务后，要应用的域名。用 sed 命令替换 kubernetes 配置。创立长久化卷第九步，创立长久化卷。应用 kubectl apply 命令即可。长久化卷创立胜利后，能够应用 kubectl get 命令查看。应用 OpenResty XRay 疾速透视和解决您的软件问题部署 Kubernetes 服务第十步，部署 Kubernetes 服务。这里也是应用 kubectl apply 命令部署 Kubernetes 服务。应用 kubectl get 命令查看服务状态为 Running 即为部署胜利。配置利用网关最初一步，是配置利用网关。关上 Azure 治理界面首页。关上 Kubernetes 服务。 ...

原文作者：NGINX 原文链接：与 NGINX 团队间接交换 | 微服务之月炽热报名中 转载起源：NGINX 官方网站 NGINX 惟一中文官网社区 ，尽在 nginx.org.cn 又是一个激情似火的六月，一年一度的 Microservices June 微服务之月再次回归！ 微服务之月是 NGINX 一年一度的收费线上教学我的项目，往年咱们将次要关注“微服务交付”的概念和技巧。在微服务之月的学习期间，您有任何和课程内容相干的问题都能够在微信群与来自 NGINX 团队的单元导师间接答疑。 本篇文章咱们将具体介绍四位单元导师，[](https://www.nginx.org.cn/article/detail/12624)点击此处理解更多我的项目背景信息。 报名工夫6月1日 - 7月1日 流动模式课程录像、上机试验、单元小测、微信群答疑 流动主题微服务交付 – 利用开发的十二因素、Secrets 的治理与配置、自动化部署、可观测性实际 收费报名点击此处进行报名 我的项目简介微服务之月是 NGINX 一年一度的收费线上教学我的项目，往年咱们将会关注和“微服务交付”相干的外围根底概念。本我的项目的难度为中等偏低，无论您是 Kubernetes 的初学者，还是曾经在生产环境广泛应用 Kubernetes，您都将从这个我的项目中播种实用的常识和技能。 通过参加本我的项目，您不仅将和社区的小伙伴们独特交换提高，还能够间接在微信群中与 NGINX 团队进行互动答疑。 针对每个单元的内容，咱们将提供多种学习模式，包含： 关注概念解说的课程录像提供实操教训的上机试验测验学习成绩的单元小测咱们将一次性放出所有的学习材料，这意味着您能够依据您的工夫来合理安排学习节奏。您还能够抉择实现所有的课程内容以取得全面的视角，或者筛选您感兴趣的局部来进行深刻探索或查漏补缺。 实现课程学习,就有机会取得 NGINX 独家定制的精美好礼以及 NGINX 授予的结课证书。 点击此处理解更多我的项目背景信息。 导师简介往年的课程将分为四个单元，实现本我的项目所需的总时长约为 8 小时。在微服务之月的学习期间，您有任何和课程内容相干的问题都能够在微信群与来自 NGINX 团队的单元导师间接答疑。 第一单元在微服务架构中施行利用开发的十二因素 易久平 F5 NGINX 资深架构师 曾任惠普企业架构师、摩天轮票务技术总监等职务，多年从事软件开发、架构设计、技术治理等相干工作，对于服务网关、微服务、中间件等技术有丰盛的研发和架构教训。 第二单元微服务 Secrets 治理与配置根底入门 汤炜涛 F5 NGINX 解决方案参谋 10 年利用交付畛域从业教训，目前次要负责金融行业客户的解决方案设计。中国 DevOps 社区公益课讲师。专一于多云多活数据中心架构，容器化环境利用交付设计，利用交付与 DevOps 交融等技术畛域。领有阿里云 ACP、AWS SAP、K8S CKA & CKS、Jenkins CJE 等认证。 ...

先说说奇葩的需要：https转其余网站的http在我的项目里用iframe内嵌其余网站，这个“其余网站”不是咱们开发的，并且是http，但浏览器会默认阻止从https网站向http地址发动申请 因而初步的解决方案是：用咱们本人的服务器nginx转发一次，尽管服务器到“其余网站”的传输还是明文，但至多能够做到甩锅（至多用户到咱们的服务器的传输是SSL......） 而后这个“其余网站”就呈现了有限重定向问题。 另外，依据以往的经验，在给WordPress加https的时候，也可能会遇到有限重定向的问题。 起因实质上是因为：“其余网站”的服务程序具备申请头校验。 通常来说，nginx转发的申请，是带有原始申请头信息的申请。比方：nginx服务器的地址是https://server1.domin:1111生产服务器的地址是http://server2.domin:2222 浏览器向https://server1.domin:1111发动申请此时，尽管nginx把申请代理到了http://server2.domin:2222但因为一系列的参数设置，http申请头中的信息还是https://server1.domin:1111 这种状况下，如果“其余网站”的服务程序（Apache或nginx）中退出了申请头校验，也就是说，如果端口不是2222，就重定向；如果地址不是server2.domin，就重定向。 而咱们的nginx曾经把申请头改成了原始信息，天然不能通过他们的验证，所以就会被强制重定向了。 如图，它把我的38004端口的申请重定向到了默认的443,阐明对方服务器有地址校验，而且重定向只扭转了端口。 而如果我的nginx恰好也用的443,就会有限重定向了。 解决咱们先来看看通常应用的nginx的重写参数： server { listen 38002 ssl; server_name server1.domin; ssl_certificate server1.domin.cer; ssl_certificate_key server1.domin.key; location / { proxy_set_header Host $host; proxy_set_header X-Real_IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr:$remote_port; proxy_pass http://server2.domin:2222/; }}这种状况下，就是间接在代理的申请中，退出原始申请头信息那么咱们怎么改呢？咱们要让对方服务器认为，nginx发过来的申请不是代理过来的，而是间接发过来的。再换种形式说，此时nginx的作用不再是反向代理，而是正向代理，目标是暗藏真正的申请信息，让对方服务器认为就是nginx间接申请的对方服务器。 所以咱们要把ip、端口等等参数间接写死。 server { listen 443 ssl; server_name server1.domin; ssl_certificate server1.domin.cer; ssl_certificate_key server1.domin.key; location / { proxy_set_header Host server2.domin; // 对方服务器的域名 proxy_set_header X-Real-IP 123.123.123.123; // 对方服务器的实在地址，从控制台中找到 proxy_set_header X-Forwarded-For $123.123.123.123:80; proxy_set_header X-Forwarded-Host server2.domin; // 对方服务器的域名 proxy_set_header X-Forwarded-Port 80; // 对方服务器的端口 proxy_pass http://server2.domin:2222/; }}于是代理过程就变成了这样： ...

Nginx负载平衡配置是一个散发申请的过程。能够通过将同一个服务的多个实例配置到不同的服务器上，通过Nginx代理申请，将申请散发到这些实例上实现负载平衡。上面具体介绍Nginx负载平衡的配置过程和宕机状况解决： 在Nginx配置文件中增加upstream配置块：http { upstream backend { server backend1.example.com weight=5; server backend2.example.com; server backend3.example.com; server backend4.example.com max_fails=3 fail_timeout=30s; } # ...}在这个配置块中，backend是定义的一个服务名，其中蕴含了多个服务实例。每个实例应用server关键字定义，并通过weight参数为实例设定权重，默认权重为1。咱们能够通过为实例设置不同的权重值来实现不同的负载平衡策略。 在下面的配置中，backend4.example.com的宕机状况将被解决。即当一个后端服务器因为服务器故障、网络问题等起因不能提供服务时，Nginx会将它从服务池中临时移除。在此例中，当backend4.example.com呈现3次失败后，将被标记为失败状态，并在30秒内不再进行申请转发。 在Nginx配置文件中增加server配置块，将申请转发至upstream：http { upstream backend { server backend1.example.com weight=5; server backend2.example.com; server backend3.example.com; server backend4.example.com max_fails=3 fail_timeout=30s; } server { listen 80; server_name www.example.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }}通过将申请代理至http://backend，Nginx会将申请转发到backend中定义的多个服务实例。在配置过程中，还能够对申请进行更细粒度的管制，如用户Session平衡、申请Header批改等等。 以上就是Nginx负载平衡的配置过程，宕机状况解决的形式次要是通过fail_timeout和max_fails参数管制。当一个后端服务在fail_timeout内呈现max_fails次失败时，将被临时移除。这样可能保障后端服务呈现故障时，不会影响到整个零碎的稳定性和可靠性。

在linux中，默认的SSH端口号为22，因为这是咱们都晓得的端口号，一旦有入侵者进行端口扫描的时候扫描出22端口，就立马晓得这是进行SSH登录的端口号，因此咱们须要批改默认的端口号。 本次测试环境：Centos7.6零碎-服务器来自：蓝易云 定位建站服务器，特点是 香港五网CN2网络 ，国内速度优良，反对VPC内网互联、快照、备份等性能。 挪动+联通+电信+教育网+广电-五网CN2-提早超低！ 蓝易云持有 IDC 、 ISP 、CDN许可证，为正规商家。 SSH 1.教程开始云服务器一到手，第一件事就是更改ssh端口，避免被扫描破解。 批改端口号是通过批改SSH的配置文件实现的，登录ssh后，输出： vi /etc/ssh/sshd_config向下找到#Port 22这段 SSH端口批改 键盘上按一下 i 进入编辑模式 删除掉Port 22后面的#，而后键盘按一下回车键【如果没有#可不用删除，间接下一步】 输出新的端口号如：Port 10000（这个你本人定，最大不能超过65535） 编辑好，先按ESC键，再输出 wq 保留退出. 接着重新启动ssh，代码如下： systemctl restart sshd.service#删除或新增都需重启SSH服务，否则不失效。而后再应用已批改的端口登录【教程演示的是10000端口】，看是否能够连贯胜利，连贯胜利后在删除22端口. 2.端口放行不过在这有一个问题，个别的linux服务器都有自带的防火墙iptables规定，把端口10000 在规定中设置备放行。 【如果没有应用iptables，请在服务商平安组放行你批改的端口号】蓝易云平安组默认端口全开 如果装置了宝塔面板请在：宝塔-平安-零碎防火墙,放行一下端口。否则无奈应用 iptables -I INPUT  -p tcp --dport 10000 -j ACCEPT参数 -I 是把下面那条规定插入到iptables规定的最后面，而后删除ssh默认的22端口，保留规定，重启防火墙，到此功败垂成。 上面说一下，怎么删除iptables规定，有时候有些规定太长，删除时要写一大串，既浪费时间又容易写错，这时咱们能够先应用–line-number查看出该条规定的行号，再通过行号删除，代码如下： [root@test ~]# iptables -nL --line-numberChain INPUT (policy ACCEPT)num  target     prot opt source               destination1    DROP       all  --  192.168.1.1          0.0.0.0/02    DROP       all  --  192.168.1.2          0.0.0.0/03    DROP       all  --  192.168.1.3          0.0.0.0/0比方删除第二条规定，输出 ： [root@test ~]# iptables -D INPUT 23.教程完结

原文作者：NGINX 原文链接：立刻报名 | Microservices June 微服务之月再度开启 转载起源：NGINX 官方网站 NGINX 惟一中文官网社区 ，尽在 nginx.org.cn 又是一个激情似火的六月，一年一度的 Microservices June 微服务之月再次回归！ 微服务之月是 NGINX 一年一度的收费线上教学我的项目，往年咱们将次要关注“微服务交付”的概念和技巧。实现课程学习就有机会取得 NGINX 独家定制的精美好礼以及 NGINX 授予的结课证书。 报名工夫6月1日 - 7月1日 流动模式课程录像、上机试验、单元小测、微信群答疑 流动主题微服务交付 – 利用开发的十二因素、Secrets 的治理与配置、自动化部署、可观测性实际 收费报名点击此处报名 我的项目亮点难度适中：从根底概念讲起，配以入手实操环节，确保课程实践扎实且内容实用。形式多样：包含录像、试验、小测和探讨群，全方位晋升学习效果。讲师领导：您将有机会间接与 NGINX 团队进行互动，最大水平减速学习停顿。工夫灵便：您将依据需要自行把握学习节奏，确保充沛排汇课程内容。赢取证书：您将有机会取得 NGINX 的结课证书和独家纪念品，助力您的职业倒退。课程内容借助微服务，越来越多的开发人员开始利用多个小组件（每个组件执行单个性能，且它们之间相互放弃通信）来构建大型的简单利用。 即便在当下，您所在的企业还并未转型到微服务架构，在将来您也很可能会须要微服务的相干技能。 微服务之月是 NGINX 一年一度的收费线上教学我的项目，去年咱们次要探讨了和“微服务网络”相干的话题，往年咱们将会关注和“微服务交付”相干的外围根底概念。 错过了去年的 Microservices June？点击此处立刻理解更多信息。 和去年一样，本我的项目的课程将分为四个单元，共计 8 课时的学习内容。课程主题包含： 第一单元：在微服务架构中施行利用开发的十二因素第二单元：微服务 Secrets 治理与配置根底入门第三单元：利用 Docker、Kubernetes 和 Gitlab 实现微服务自动化部署和 CI/CD第四单元：借助可观测性治理混沌而简单的微服务微服务之月属于根底型教学我的项目，如果您是软件开发者、DevOps 工程师、平台运维工程师、 IT 运维工程师、SRE 工程师、云原生架构师等角色，本我的项目所提供的概念和技能将反对您顺利度过企业的微服务架构转型，并且助力您的职业倒退。 学习模式Microservices June 微服务之月共分为四个单元，针对每个单元的内容，咱们将提供多种学习模式，包含： 关注概念解说的课程录像提供实操教训的上机试验测验学习成绩的单元小测通过参加本我的项目，您不仅将和社区的小伙伴们独特交换提高，还能够间接在微信群中与 NGINX 团队进行互动答疑。 不过与去年不同的是，往年咱们将于 6 月 8 日一次性放出所有的学习材料，这意味着您能够依据您的工夫来合理安排学习节奏。 ...

原文作者：Derek DeJonghe of F5 原文链接：寰球首发 | 《NGINX 齐全指南》中文版 转载起源：NGINX 开源社区 NGINX惟一中文官网社区 ，尽在nginx.org.cn 在社区小伙伴们的督促下，咱们很快乐地与大家分享这个好消息：由 O'Reilly 出版的《NGINX 齐全指南》中文版（2022 年最新版）现已正式上线！ 《NGINX 齐全指南》旨在通过一些简略易懂的例子解析利用交付中实在存在的问题。本书内容丰盛全面，探讨了 NGINX 的大部分次要个性，可帮忙您学习如何应用这些性能。 这本 180 多页易于了解的配置指南将为您讲述从如何装置 NGINX 到如何进行配置，再到如何调试和排除利用性能故障。不仅如此，本书还提供了将 NGINX 用于负载平衡、云部署、自动化、容器和微服务、服务网格、平安防护等场景的相干配置示例。 通过浏览本书，您将理解到： ◆ 如何应用 NGINX 实现高性能的负载平衡并施行健康检查 ◆ 如何应用 NGINX 智能地路由流量，并依据多个属性管制流量 ◆ 如何在搁置 NGINX 服务器的任何中央缓存内容，从而无效创立本人的 CDN ◆ 如何通过实现测试自动化、放弃客户端长链接、放弃上游长链接、响应缓冲、日志缓冲、操作系统调优等形式实现性能调优 ◆ 如何应用 NGINX App Protect 爱护您的利用和 API，以及启用用于缓解 DDoS 攻打、阻止七层攻打和启用 SSO 的相干配置 ◆ 如何应用 NGINX Service Mesh优化并爱护微服务和容器环境 ◆ 如何应用 NGINX Instance Manager 实现主动配置，并监控 NGINX Plus 和 NGINX 开源版实例 ...

咱们晓得，nginx作为webserver，自身只能解决动态资源文件；对于动静的PHP申请，须要调用相应的PHP解释器来执行；因而须要配置fastcgi_pass，以实现nginx与php-fpm过程间的通信。 nginx与php-fpm过程间的通信有两种形式： 1、TCP就是IP加端口；长处是能够跨服务器；毛病是相比上面的办法要慢；配置示例：php-fpm.conf: listen = 127.0.0.1:9000nginx.conf: fastcgi_pass = 127.0.0.1:90002、UDSUDS 就是 UNIX Domain Socket 协定的缩写；长处是速度相比TCP要快，因为它不通过传输层(5层网络模型之一)；毛病是只实用于nginx和php-fpm在同一服务器的场景。配置示例：php-fpm.cnf: listen = /run/php/php-fpm.socknginx.conf: listen = unix:/run/php/php-fpm.sock那么，为什么UDS比TCP要快？一般而言，socket编程，是建设在传输层根底上的，就是下面的第一种通信形式，但在Unix零碎上，存在一种非凡的socket，这种socket无需应用传统的IP地址+端口形式，而是间接应用文件来进行程序间的数据交互； 在Unix操作系统中，所有都能够看做是文件，天然包含程序运行的一些信息。因此，能够间接借助于这些程序运行时产生的文件来进行不同程序之间的数据交互，这就是UDS形式（此种socket只能在unix零碎上应用）。 UDS形式，对于程序自身来说，只需读取和写入共享的socket文件即可(又分为【StreamSocket-流套接字】和【DatagramSocket-数据包套接字】)，可用在两个没有关联关系的过程之间，间接通过socket文件进行数据交互；时下大火的一种容器技术，docker，和实体机进行数据传输和信息替换应用的也正是UDS。 其特点如下： 1) 传输不通过网络协议栈(也就是那5层网络模型)，不须要打包拆包，只是数据间的拷贝；2) 因为是在本机通过内核通信，不会丢包也不会呈现发送包的秩序和接管包的秩序不统一的问题;基于以上特点，其传输速度更快，有文章称是TCP的两倍，没有深刻理解，不予置评。但UDS作为目前比拟宽泛应用的IPC机制，传输速度更快是必定的，毕竟网络协议是为不牢靠通信设计的，而IPC机制实质上是牢靠通信，免去了这些繁琐的牢靠校验步骤。UDS与TCP连贯形式简略示意： UDS形式：nginx <=> socket <=> php-fpmTCP本机形式：nginx <=> socket <=> TCP/IP <=> socket <=> php-fpmTCP跨服务器形式：nginx <=> socket <=> TCP/IP <=> 物理层 <=> 路由器 <=> 物理层 <=> TCP/IP <=> socket <=> php-fpmnginx应用UDS与php-fpm过程间通信的益处：这种通信形式产生在零碎内核里，不会在网络中流传，它不会走到TCP的那一层，间接以stream-socket文件模式通信；从而防止了频繁创立TCP短链接而导致的 TIME_WAIT 连贯过多的问题。 当然了，UDS不能跨服务器也是最显著的毛病之一，至于如何抉择，需各位看官本人斟酌。 谈谈php-fpm、fastcgi、cgi之间的关系 CGI (Common Gateway Interface)：是一种通用的 Web 服务器和内部应用程序之间进行数据交互的标准协议，它定义了 Web 服务器和内部应用程序之间传递数据的格局和标准。在 CGI 模式下，PHP 程序每次申请都须要启动一个新的过程来解决申请，包含ini，加载扩大配置等，并在申请处理完毕后完结过程，因而效率较低；FastCGI(Fast Common Gateway Interface)：是对 CGI 的一种改良，它能够在过程池中保护多个 PHP 过程，并与 Web 服务器放弃长连贯，以进步性能。在 FastCGI 模式下，PHP 过程只在启动时创立一次，并放弃运行状态，不须要每次申请都重新启动过程；php-fpm (PHP FastCGI Process Manager)：是一个独立的 PHP 过程管理器，能够治理 FastCGI 模式下的 PHP 过程池，并提供过程调度、过程监控、申请解决等性能。php-fpm 能够独立于 Web 服务器运行，也能够与 Nginx、Apache 等 Web 服务器配合应用。联合括号中的英文全拼就比拟容易了解了，简略来说：CGI 和 FastCGI 是两个协定，或者叫行业标准，FastCGI 又是 CGI 的降级款计划。任何语言编写的程序都能够通过 FastCGI/CGI 协定来提供 Web 服务，不是专属于PHP的，这样了解就很清晰了。 ...

原文作者：Amir Rawdat of F5 原文链接：NGINX 和 HAProxy：基于私有云规范环境的用户体验测试比照 转载起源：NGINX 官方网站业内许多性能基准测试，都是基于峰值吞吐量或每秒申请数 (RPS)，但这些指标可能会过分简化理论站点的性能状况。以峰值吞吐量或靠近峰值吞吐量运行其服务的企业寥寥无几，因为无论采纳哪种形式，10% 的性能变动都会产生重大影响。站点所需的吞吐量或 RPS 不是有限的，而是取决于内部因素，例如站点必须服务的并发用户数量和每个用户的沉闷水平。最终重要的是您的用户可能获得最佳服务。最终用户并不在乎有多少人正在拜访您的站点。他们只在意本人所取得的服务，而且他们无奈承受因零碎过载而导致的性能低下。 因而，对于企业真正重要的是，即便在高负载下也要能为所有用户提供继续的低提早的可靠性能。在比照作为反向代理运行于 Amazon Elastic Compute Cloud (EC2) 之上的 NGINX 和 HAProxy 时，咱们从以下两方面着手探讨： 测量这两种代理能够牢靠解决的负载程度计算提早指标百分位数的散布状况，这是与用户体验最间接相干的指标测试程序和收集的指标咱们应用压测工具wrk2模仿了一个客户端，在规定的时间段内收回间断的 HTTPS 申请。被测系统（HAProxy 或 NGINX）充当反向代理，与wrk线程模仿的客户端建设加密连贯，将申请转发到运行 NGINX Plus R22 的后端 Web 服务器，Web 服务器将生成的响应（一个文件）返回给客户端。 这三个组件（客户端、反向代理和 Web 服务器）都在Ubuntu 20.04.1 LTS， EC2 的 c5n.2xlarge Amazon Machine Image (AMI) 实例上运行。 如上所述，咱们从每次测试运行中收集了残缺的提早指标百分位散布。提早指标是指客户端从生成申请到接管响应所用的工夫。提早百分位散布会将测试期间收集的提早测量值从高到低（即从延迟时间最长到最短）进行排序。 测试方法客户端借助 wrk2（版本 4.0.0），咱们在 Amazon EC2 实例上运行以下脚本： taskset -c 0-3 wrk -t 4 -c 100 -d 30s -R requests_per_second --latency https://adc.domain.com:443/为了模仿多个客户端拜访 Web 利用，咱们生成了 4 个wrk线程，这些线程共与反向代理建设 100 个连贯。在 30 秒的测试运行期间，该脚本生成了指定数量的 RPS。这些参数对应于以下wrk2选项： ...

根本状况是这样的： 用户应用AD域用户登录了Windows零碎，关上网站外网域名（非内网IP）时，须要应用这个登录的AD帐号主动进入Web零碎。外网域名映射到一台装置了nginx的Linux服务器，通过nginx负载平衡散发到两台Windows服务器上。 因为nginx默认不反对NTLM认证，导致关上网站域名时认证失败，始终反复弹出帐号密码输入框。 通过网上查阅了大量材料，并重复尝试，解决的办法是须要启用一个nginx-ntlm-module的nginx模块，方法如下： 1、下载nginx源码及依赖的源码包。有点麻烦，见前面提供的源码包。2、下载nginx-ntlm-module源码：https://github.com/gabihodoroaga/nginx-ntlm-module。3、编译源码为可执行文件，并装置到linux。4、按模块阐明的配置nginx.conf。 为不便起见，我整顿了一个源码包，将其放到Linux上解压缩，执行外面_build_install_linux.sh即可实现编译并装置到/usr/local/nginx/目录。下载地址：https://github.com/hzsrc/nginx-ntlm-src

作者：京东物流 殷世杰 Nginx曾经广泛应用于J-one和Jdos的环境部署上，本文对Nginx的罕用的配置和基本功能进行解说，适宜Nginx入门学习。 1 外围配置找到Nginx装置目录下的conf目录下nginx.conf文件，Nginx的基本功能配置是由它提供的。 Nginx的配置文件(conf/nginx.conf)整体上分为如下几个局部： ： 区域职责全局块配置和Nginx运行相干的全局配置events块配置和网络链接相干的配置http块配置代理、缓存、日志记录、虚拟主机等配置server块配置虚拟主机的相干参数，一个http快中能够有多个server块location块配置申请的路由，以及各种页面的解决状况配置层级图如下所示。 1.2 配置文件示例一个比拟全的配置文件示例如下。 # 以下是全局段配置#user administrator administrators; #配置用户或者组，默认为nobody nobody。#worker_processes 2; #设置过程数，默认为1#pid /nginx/pid/nginx.pid; #指定nginx过程运行文件寄存地址error_log log/error.log debug; #制订日志门路，级别：debug|info|notice|warn|error|crit|alert|emerg# events段配置信息events { accept_mutex on; #设置网路连贯序列化，避免惊群景象产生，默认为on multi_accept on; #设置一个过程是否同时承受多个网络连接，默认为off #use epoll; #事件驱动模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport worker_connections 1024; #最大连接数，默认为512}# http、配置申请信息http { include mime.types; #文件扩展名与文件类型映射表 default_type application/octet-stream; #默认文件类型，默认为text/plain #access_log off; #勾销服务日志 log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定义格局 access_log log/access.log myFormat; #combined为日志格局的默认值 sendfile on; #容许sendfile形式传输文件，默认为off，能够在http块，server块，location块。 sendfile_max_chunk 100k; #每个过程每次调用传输数量不能大于设定的值，默认为0，即不设下限。 keepalive_timeout 65; #连贯超时工夫，默认为75s，能够在http，server，location块。 upstream mysvr { server 127.0.0.1:7878; server 192.168.10.121:3333 backup; #热备 } error_page 404 https://www.baidu.com; #谬误页 # 第一个Server区块开始，示意一个独立的虚拟主机站点 server { keepalive_requests 120; #单连贯申请下限次数。 listen 4545; #监听端口 server_name 127.0.0.1; #监听地址 location ~*^.+$ { #申请的url过滤，正则匹配，~为辨别大小写，~*为不辨别大小写。 #root path; #根目录 #index vv.txt; #设置默认页 proxy_pass http://mysvr; #申请转向mysvr 定义的服务器列表 deny 127.0.0.1; #回绝的ip allow 172.18.5.54; #容许的ip } }}1.3 locat门路映射解说1.3.1格局：location [ = | ~ | ~ | !~ | !~ | @ ] uri {...} ...

本文介绍如何装置podman，并创立podman容器环境Centos8装置podmanPodman 是一个容器环境，首先在主机上安装 Podman。执行上面命令来装置podman：[root@localhost ~]# yum -y install podman而后批改一下用户命名空间的大小：[root@localhost ~]# echo "user.max_user_namespaces=28633" >> /etc/sysctl.d/userns.conf[root@localhost ~]# sysctl -p /etc/sysctl.d/userns.confuser.max_user_namespaces = 28633上面创立一个podman容器来看一下吧，上面应用的是RHEL的UBI镜像：[root@localhost ~]# podman run ubi8/ubi cat /etc/os-releaseResolved "ubi8/ubi" as an alias (/etc/containers/registries.conf.d/001-rhel-shortnames.conf)Trying to pull registry.access.redhat.com/ubi8/ubi:latest...Getting image source signaturesChecking if image destination supports signaturesCopying blob ce3c6836540f done Copying blob 63f9f4c31162 done Copying config cc06568478 done Writing manifest to image destinationStoring signaturesNAME="Red Hat Enterprise Linux"VERSION="8.5 (Ootpa)"ID="rhel"ID_LIKE="fedora"VERSION_ID="8.5"PLATFORM_ID="platform:el8"PRETTY_NAME="Red Hat Enterprise Linux 8.5 (Ootpa)"ANSI_COLOR="0;31"CPE_NAME="cpe:/o:redhat:enterprise_linux:8::baseos"HOME_URL="https://www.redhat.com/"DOCUMENTATION_URL="https://access.redhat.com/documentation/red_hat_enterprise_linux/8/"BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"REDHAT_BUGZILLA_PRODUCT_VERSION=8.5REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"REDHAT_SUPPORT_PRODUCT_VERSION="8.5" ...

原文作者：Dave McAllister of F5 原文链接：OpenTelemetry 正在扭转咱们跟踪和设计利用的形式 转载起源：NGINX 官方网站 NGINX 惟一中文官网社区 ，尽在 nginx.org.cn 可观测性是运行云原生利用的要害，而云原生利用的性能依赖于在多个地位运行的大量微服务之间的交互。微服务利用的涣散耦合性可能意味着每个微服务都在以本人的形式报告本人的流动状况。全程跟踪申请的处理过程对于故障排除至关重要，然而如果没有一款适合的工具来编译和关联这些遥测数据，跟踪会变得十分之艰难——即使没有到不可能的境地。 通过多番考量，NGINX 古代利用参考架构 (MARA) 我的项目团队从一泛滥性能可观测性工具中选中了 OpenTelemetry。咱们的 OSS 团队抉择 MARA 这个新兴我的项目也激发了咱们的钻研趣味。在GlueCon 2022大会上，我与 F5 CTO 办公室的架构师 Granville Schmidt 一起探讨了 OpenTelemetry 的现状以及将来值得期待的一些亮点。请观看下方咱们的对话视频，深刻理解为何 OpenTelemetry 是云原生应用领域的重要资产。 OpenTelemetry 赋能 Observability 2.0自 2019 年在巴塞罗那 KubeCon 大会上首次亮相以来，OpenTelemetry曾经吸引了少量热心的贡献者。从奉献数量来看，它是云原生计算基金会 (CNCF) 的第二大热门我的项目，其贡献率在近六个月来达到了历史最高。这么多的贡献者表明，OpenTelemetry 曾经成熟，开始从晚期的采纳者（违心尝鲜）向实用主义者（想要成熟的产品）遍及。 OpenTelemetry 的外围是数据 —— 具体来说是更好地了解、排障和改善利用所需的数据和数据流（遥测）。数据只有能在大规模聚合、剖析和可视化的状况下才有用。尽管 OpenTelemetry 并没有提供数据可视化的方向，但它让咱们不再担心能够取得哪些数据，而是能够专一于应用数据发明的价值。 OpenTelemetry 可能实现这些数据源之间的天然关联，而不是冀望咱们本人尝试这种关联。OpenTelemetry 这种跨利用关联事件的能力催生了 Observability 2.0（可观测性 2.0） —— 一种掂量云端利用流动的新基准。关联好的数据加强了咱们对利用的理解。以前咱们只晓得利用是否正在运行，而当初有哪些申请流经咱们的利用、它们的门路是什么 —— 咱们都一清二楚。 在 OpenTelemetry 之前有两个驰名的开源我的项目：OpenTracing (OT)和OpenCensus (OC)，两者都着力于解决数据跟踪格局的标准化问题，目标是让咱们可能轻松获取必要的信息并理解这些信息对古代利用的影响。尽管它们有着相似之处，但也难免会抢夺资源，公司往往只能从中筛选一个。2019 年 3 月，为了对立跟踪数据的生成形式和格局，OpenTracing 和 OpenCensus 发表合并，OpenTelemetry 就此诞生。OpenTelemetry 我的项目进一步定义了通过与 Traces（链路跟踪）雷同的遥测信道获取其余类别的可观测性数据（Metrics 指标和Logs日志）的规范，从而实现更高水平的集成和清晰度。 ...

筹备工作1、创立用户和配置环境参数(1)、创立用户和创立所需目录[root@nginx ~]# groupadd nginx[root@nginx ~]# useradd -d /home/nginx -g nginx -m nginx[root@nginx ~]# chmod 755 /home/nginx[root@nginx ~]# mkdir -p /home/nginx/software[root@nginx ~]# mkdir -p /home/nginx/yunwei[root@nginx ~]# chown -R nginx:nginx /home/nginx[root@nginx ~]# mkdir -p /data/nginx[root@nginx ~]# chown -R nginx:nginx /data/nginx2、下载https://jaist.dl.sourceforge.net/project/libpng/zlib/1.2.11/z...https://www.openssl.org/source/openssl-1.1.1h.tar.gzhttps://ftp.pcre.org/pub/pcre/pcre-8.44.tar.gzhttp://nginx.org/download/nginx-1.22.0.tar.gzhttps://codeload.github.com/vozlt/nginx-module-vts/tar.gz/v0.1.183、部署(1)、解压安装包并备份配置文件[nginx@nginx ~]$ tar -zxvf $HOME/software/zlib-1.2.11.tar.gz -C $HOME/software/[nginx@nginx ~]$ tar -zxvf $HOME/software/openssl-1.1.1h.tar.gz -C $HOME/software/[nginx@nginx ~]$ tar -zxvf $HOME/software/pcre-8.44.tar.gz -C $HOME/software/[nginx@nginx ~]$ tar -zxvf $HOME/software/nginx-1.22.0.tar.gz -C $HOME/software/[nginx@nginx ~]$ tar -zxvf $HOME/software/nginx-module-vts-0.1.18.tar.gz -C $HOME/software/[nginx@nginx ~]$ cd $HOME/software/nginx-1.22.0[nginx@nginx software/nginx-1.22.0]$ ./configure --prefix=$HOME/nginx-1.22.0 --with-http_ssl_module --with-pcre=$HOME/software/pcre-8.44 --with-zlib=$HOME/software/zlib-1.2.11 --with-openssl=$HOME/software/openssl-1.1.1h --with-http_stub_status_module --add-module=$HOME/software/nginx-module-vts-0.1.18[nginx@nginx software/nginx-1.22.0]$ make[nginx@nginx software/nginx-1.22.0]$ make install[nginx@nginx software/nginx-1.22.0]$ cp $HOME/nginx-1.22.0/conf/nginx.conf $HOME/nginx-1.22.0/conf/nginx.conf_init(2)、创立所需目录[nginx@nginx ~]$ mkdir -p /data/nginx/nginx-1.22.0/logs[nginx@nginx ~]$ mkdir -p $HOME/nginx-1.22.0/conf/conf.d[nginx@nginx ~]$ mkdir -p $HOME/nginx-1.22.0/html/operation_workspaces4、调整配置文件(1)、依据理论状况调整nginx.conf配置文件[nginx@nginx ~]$ vi $HOME/nginx-1.22.0/conf/nginx.conf#user nobody;worker_processes 2;#error_log logs/error.log;error_log /data/nginx/nginx-1.22.0/logs/error.log warn;#error_log logs/error.log notice;#error_log logs/error.log info;#pid logs/nginx.pid;pid /data/nginx/nginx-1.22.0/logs/nginx.pid;events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; vhost_traffic_status_zone; vhost_traffic_status_filter_by_host on; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" $request_time'; #access_log logs/access.log main; access_log /data/nginx/nginx-1.22.0/logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; # 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; # } #} # 导入子配置文件，这里援用*，示意所有的.conf文件都会被调用 include conf.d/*.conf;}(2)、依据理论状况调整default.conf子配置文件[nginx@nginx ~]$ vi $HOME/nginx-1.22.0/conf/conf.d/default.confserver { listen 8000; server_name localhost; charset utf-8; #charset koi8-r; access_log /data/nginx/nginx-1.22.0/logs/default.access.log main; location / { root html; index index.html index.htm; } location /status { vhost_traffic_status_display; vhost_traffic_status_display_format html; } #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; #}}5、起停服务与创立对应脚本(1)、 创立启动服务脚本[nginx@nginx ~]$ vi $HOME/yunwei/nginx-1.22.0_start.sh#!/bin/bashcd $HOME/nginx-1.22.0/sbin ./nginx -c $HOME/nginx-1.22.0/conf/nginx.conf(2)、 创立进行服务脚本[nginx@nginx ~]$ vi $HOME/yunwei/nginx-1.22.0_stop.sh#!/bin/bashcd $HOME/nginx-1.22.0/./sbin/nginx -s stop(3)、 创立平滑重起服务脚本[nginx@nginx ~]$ vi $HOME/yunwei/nginx-1.22.0_reload.sh#!/bin/bashcd $HOME/nginx-1.22.0/./sbin/nginx -s reload

session问题在零碎验证码登录的时候，咱们在获取验证码时候，将code设置再session外面，而后咱们再登录的时候从session外面获取验证码，发现获取的验证码为null。在本地的确能够，由此想到nginx配置代理的时候必定出问题了。 原来配置: location /ccas { proxy_pass http://127.0.0.1:8003/ccas; proxy_redirect default; }批改后配置: location /ccas { proxy_pass http://127.0.0.1:8003/ccas; 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_set_header X-Forwarded-Proto $scheme; proxy_redirect default; }

1. 问题 首次执行home目录下的文件，拜访呈现 解决：排查方向，能够看下nginx.conf的用户组，是否容许其余用户拜访。如果配置了user的话，须要看下别的，我的是本次增加user 到创立的用户，解决 2. 首次nginx、php装置,拜访呈现nginx 呈现，有人说是文件权限问题，我也一度狐疑过是我的php-fpm启动问题，但最终发现，是php-fpm中的用户权限问题，（折磨了我两天的问题呀，最终我灵光一闪，尝试了一下解决） 解决： 批改php-fpm中的用户组权限，才能够拜访， 摘要装置须要的软件、诸如nginx、 PHP、mysql等，其实大部分是应用root用户去装置的， 但这时候会有个问题，一般来说，我集体是不会针对比方nginx专门创立一个nginx用户组，而是会间接创立个相似mosheng的用户组，在mosheng下实现我所有的开发工作，以前开发始终是失常，但可能这次是我配置的权限问题，导致呈现了如此问题。 上文的问题其实很简略，就是mosheng的用户组拜访不到nginx和php-fpm用户组的问题，导致失败，所以只须要批改成对应的用户组，在去拜访既可。

记录nginx不同拜访门路和代理的配置，留神有加斜杠和不加的区别 以下展现不同状况下的配置：location门路、root门路、alias门路、proxy_pass代理门路。通过这几个配置门路地址比照，倡议location前面都带上斜杠。# 过程数量worker_processes 1;events { # 最大连贯数量 worker_connections 1024;}http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # 演示如何强制http跳转https server { listen 80; server_name test.com; # http强制跳转到https rewrite ^(.*)$ https://$server_name$1 permanent; } # 演示如何配置微信领取的校验文件 server { listen 80; server_name localhost; # 默认根门路 location / { root index.html; } # 微信领取校验文件，能够间接配置拜访名称 location ^~/MP_verify_2g3uEjrB5B2LIbNl.txt { alias /home/MP_verify_2g3uEjrB5B2LIbNl.txt; } # 微信领取校验文件，也能够通过正则配置 location ~^/MP_verify_[a-zA-Z0-9]*\.(txt)$ { root /home/; rewrite ^/home/(.txt)$ /home/$1 last; } } # 演示root和alias两种配置动态资源的区别 server { listen 80; server_name localhost; # 用root形式，location中的门路会拼加到root的地址前面 # 申请门路为：http://localhost:8080/files/index.jpg 理论拜访为：/home/files/index.jpg location ~^/files/ { root /home/; index index.html index.htm; } # 用alias形式，location中的门路不会拼加到alias的地址前面 # 这申请门路为：http://localhost:8080/files/index.jpg 理论拜访为：/home/index.jpg location ~^/files/ { alias /home/; index index.html index.htm; } } # 演示申请后盾接口代理配置 server { listen 8080; server_name localhost; #################### 第一种场景（代理地址不加斜杠） #################### # 申请门路为：http://127.0.0.1:8080/api/getUser 理论代理为：http://127.0.0.1:8000/api/getUser location ^~/api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $http_host; #后盾能够获取到残缺的ip+端口号 proxy_set_header X-Real-IP $remote_addr; #后盾能够获取到用户拜访的实在ip地址 } # 申请门路为：http://127.0.0.1:8080/api/getUser 理论指向为：http://127.0.0.1:8000/api/getUser location ^~/api { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $http_host; #后盾能够获取到残缺的ip+端口号 proxy_set_header X-Real-IP $remote_addr; #后盾能够获取到用户拜访的实在ip地址 } #################### 第二种场景（代理地址+斜杠） #################### # 申请门路为：http://127.0.0.1:8080/api/getUser 理论代理为：http://127.0.0.1:8000/getUser location ^~/api/ { proxy_pass http://127.0.0.1:8000/; proxy_set_header Host $http_host; #后盾能够获取到残缺的ip+端口号 proxy_set_header X-Real-IP $remote_addr; #后盾能够获取到用户拜访的实在ip地址 } # 申请门路为：http://127.0.0.1:8080/api/getUser 理论代理为：http://127.0.0.1:8000//getUser location ^~/api { proxy_pass http://127.0.0.1:8000/; proxy_set_header Host $http_host; #后盾能够获取到残缺的ip+端口号 proxy_set_header X-Real-IP $remote_addr; #后盾能够获取到用户拜访的实在ip地址 } #################### 第三种场景（代理地址+后缀） #################### # 申请门路为：http://127.0.0.1:8080/api/getUser 理论代理为：http://127.0.0.1:8000/user/getUser location ^~/api { proxy_pass http://127.0.0.1:8000/user; proxy_set_header Host $http_host; #后盾能够获取到残缺的ip+端口号 proxy_set_header X-Real-IP $remote_addr; #后盾能够获取到用户拜访的实在ip地址 } # 申请门路为：http://127.0.0.1:8080/api/getUser 理论代理为：http://127.0.0.1:8000/usergetUser location ^~/api/ { proxy_pass http://127.0.0.1:8000/user; proxy_set_header Host $http_host; #后盾能够获取到残缺的ip+端口号 proxy_set_header X-Real-IP $remote_addr; #后盾能够获取到用户拜访的实在ip地址 } #################### 第四种场景（代理地址+后缀+斜杠） #################### # 申请门路为：http://127.0.0.1:8080/api/getUser 理论代理为：http://127.0.0.1:8000/user/getUser location ^~/api/ { proxy_pass http://127.0.0.1:8000/user/; proxy_set_header Host $http_host; #后盾能够获取到残缺的ip+端口号 proxy_set_header X-Real-IP $remote_addr; #后盾能够获取到用户拜访的实在ip地址 } # 申请门路为：http://127.0.0.1:8080/api/getUser 理论代理为：http://127.0.0.1:8000/user//getUser location ^~/api { proxy_pass http://127.0.0.1:8000/user/; proxy_set_header Host $http_host; #后盾能够获取到残缺的ip+端口号 proxy_set_header X-Real-IP $remote_addr; #后盾能够获取到用户拜访的实在ip地址 } } # 演示前端我的项目如何部署nginx server { listen 8090; server_name localhost; # 默认拜访 # 部署门路：/home/web/my_demo # 拜访门路为：http://localhost:8090/ location / { try_files $uri $uri/ /index.html; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; root /home/web/my_demo/; index index.html index.htm; } # 带前缀的拜访 # 部署门路：/home/web/my_demo # 拜访门路为：http://localhost:8090/my_demo/ # 如果location门路最初没有配置斜杠，则浏览器输出拜访地址后，门路最初会主动拼一个斜杠 location ^~/my_demo/ { try_files $uri $uri/ /my_demo/index.html; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; root /home/web/; index index.html index.htm; } }}

原本是只想学习Nginx的，然而想来只学Nginx学过来有些狭隘，因为当初反向代理服务器什么是代理？作为一个沪漂程序员，听到代理这个词，我下意识的想到了中介，当初在上海曾经很少能找到房东看房子了，基本上都是从中介那里看房，从这个角度来说中介代理了房东的局部职责，带你看房。在汉语词典中也是这么阐释的，待别人处理事务。那咱们给代理后面加上正向这个词呢，这也就成为了计算机领域内的专有名词，正向代理。 什么是正向代理？那什么是正向代理呢，我想起大学的上机课，为了让咱们好好学习，上机课的电脑是无奈看到一些娱乐网站的, 比方知乎、腾讯游戏。因为有同学的确在课上打游戏，丝毫不听课。学校如同意识到了问题的不对，加上了限度，再一次上课的咱们，就发现一些娱乐网站上不了了。是通过网络白名单来进行的限度，那有什么办法可能绕开这个限度呢，答案就是代理，上网的时候，流量先达到咱们的代理服务器，获取到内容之后，再给咱们。像上面这样: 这是代理服务器的第一个用途，绕开浏览限度，一些学校和其余组织应用防火墙来使用户拜访受限制的互联网。 代理服务器能够用于绕开这些限度，因为它们使用户能够连贯到代理服务器，而不是间接连贯到它们正在拜访的沾点。与之绝对，咱们也能够应用代理服务器来组织特定用户群拜访某些站点，比方学校网络可能配置为通过启动内容筛选规定的代理连贯到Web，不在白名单的，回绝转发响应。某些场景下，互联网用户也心愿爱护本人的在线身份，在一些状况下，互联网用户心愿加强其在线匿名性，比方不想显示本人的实在ip，如果咱们用代理服务器来拜访互联网，发表评论的时候就更难追溯到实在ip。这是正向代理，咱们能够认为正向代理，代理的是人。 什么是反向代理?那反向代理呢，反向代理代理的则是服务器，有的时候咱们并不违心将咱们的服务端利用残缺的裸露进来，这会增大服务端被攻打的危险，这也就是反向代理服务器，如下图所示： 图片来自ByteByteGo。反向代理服务器能够帮忙咱们爱护服务端，同时也能够帮咱们做负载平衡，缓存动态资源，加密和解密SSL申请。本篇咱们的重头戏就是反向代理服务器。 反向代理服务器想我刚实习的时候，因为会的比拟少，感觉本人用的技术比拟没有逼格，听到Nginx、Redis这些名词的时候，心里总是有几分敬畏，觉得很有感觉。那反向代理服务器有哪些呢？ 比拟出名的是Nginx，网站用的什么服务器解决申请，有些网站能够在响应中看到，咱们首先看下掘金有没有申明本人用的是什么服务器解决的申请: 是Nginx，原本我认为反向代理服务器会应用一个，我扒了扒其余申请，发现不是: 这个Tengine是啥，咱们搜寻一下: 原来是基于Nginx的HTTP服务器，咱们进他的官网看看: 在原来Nginx的根底上，针对大访问量网站的需要，增加了很多高级性能和个性。那能够了解为Nginx Plus嘛，那咱们天然就会有一个问题，既然Tengine比Nginx更弱小，为什么没有取代Nginx呢? 写到这里，忽然想起一句话，物竞天择，适者生存。不是更弱小的齐全就能齐全取代弱的，适合的，适宜环境的，天然可能生存下来。 bing还贴心的搜出了上面这个问题: 既然 Tengine 比 Nginx 更弱小，为什么没有取代 Nginx 呢？这个问题来自于知乎，上面节选一下我认为比拟不错的答复: 开源软件的模式从来不是谁取代谁，而是百花齐放，博采众长。若意见不合，也欢送自立门户。写到这里，想起知乎之前看到的一个问题: Cloudflare弃用NGINX，改用Rust编写的Pingora，你怎么看？还真是白花齐放哈，又来了一个Pingora，对于Pingora，咱们目前就权且了解到另一个反向代理服务器吧，对于Cloudflare为什么用Pingora取代Rust，参看上面这篇文章: https://blog.cloudflare.com/zh-cn/how-we-built-pingora-the-pr...。 在下面的知乎问答中，我又看到了其余方向代理服务器: BFEBFE (Beyond Front End) 是百度开源的现代化、企业级的七层负载平衡零碎。 应用Go编写。对应的文章参看: 为什么BFE能够取代Nginx：十问十答 https://zhuanlan.zhihu.com/p/533272410 HigressHigress 是基于阿里外部两年多的 Envoy Gateway 实际积淀，以开源 Istio 与 Envoy 为外围构建的下一代云原生网关。Higress 实现了平安防护网关、流量网关、微服务网关三层网关合一，能够显著升高网关的部署和运维老本。这些只做理解，咱们的重头戏还在Nginx上。 Nginx 入门本篇的定位是入门，会简略应用即可。下面的的理解是从宏观上意识的Nginx，当初让咱们走进Nginx官网，去看看Nginx。 nginx [engine x] is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server, originally written by Igor Sysoev. For a long time, it has been running on many heavily loaded Russian sites including Yandex Mail.Ru , VK , and Rambler . According to Netcraft, nginx served or proxied 21.23% busiest sites in February 2023 . Here are some of the success stories: Dropbox , Netflix, Wordpress.com, FastMail.FM ...

记录nginx部署前端我的项目所需配置前端router history模式server { listen 443; # 监听本机所有ip上的 443 端口 server_name aax.xxx.com; # 域名地址 root /xxx/xxx/xxx; # 新建日志文件 access_log /xxx/xxx/xxx/xxx/xxx/access.log main; location / { index index.html index.htm; try_files $uri $uri/ /index.html; } error_page 500 502 503 504 /502.html; location = /50x.html { root html; } }

明天我就来手把手教小伙伴们部署 TienChin 我的项目，一起把这个我的项目跑起来，看看到底是个什么样的我的项目。 小伙伴们晓得，对于这种前后端拆散的我的项目，咱们在理论部署的时候，能够依照前后端拆散的形式来部署，也能够依照前后端不分的形式来部署。接下来两种不同的部署形式我都和小伙伴们来分享一下。 1. 前后端拆散部署1.1 部署架构图前后端拆散部署的话，咱们个别是须要一个 Nginx 服务器，我先画一个简略的部署示意图给大家参考下： 简略解释一下就是这样： 浏览器发出请求。申请首先达到 Nginx 服务器，Nginx 服务器，由 Nginx 服务器进行申请散发。如果是一个动态资源申请，则 Nginx 将之转发到动态资源服务器上，个别可能由 Nginx 本人专任动态资源服务器，也就是间接从 Nginx 本人硬盘上将数据读取进去。如果是一个动静资源，则 Nginx 将之转发到 Tomcat 上，对于咱们这里就是咱们的 Spring Boot 服务上了，当然，如果你没有这么多服务器，咱们能够将 Nginx 和 Spring Boot 部署到同一台服务器上。好了，这就是咱们的大抵的一个部署架构图了，很简略。 1.2 筹备工作接下来有几个事件是须要咱们提前准备的。 首先咱们先在服务器上安装好 MySQL 和 Redis，这个具体怎么装置我这里就不啰嗦了，基操而已。 MySQL 倡议大家用 Docker 装置，省事。如果不懂 Docker，能够在公众号后盾回复 Docker 有松哥写的入门教程；Redis 能够间接装置，松哥在之前的 vhr 系列教程中蕴含有 Redis 教程，能够公众号后盾回复 vhr 查看详情。这样咱们的筹备工作就实现了。 1.3 开始部署1.3.1 拉取我的项目首先咱们须要从 GitHub 上拉取咱们的我的项目，TienChin 我的项目的源代码是开源的，大家能够间接 Clone： https://github.com/lenve/tienchin间接执行 git clone 即可。 拉取下来之后，有两个文件夹： ...

原文作者：Owen Garrett of F5 原文链接：在 Kubernetes 中部署利用交付服务（第 1 局部） - NGINX 转载起源：NGINX 官方网站NGINX 惟一中文官网社区 ，尽在 nginx.org.cn 本文是以下系列博文中的一篇： 在 Kubernetes 中部署利用交付服务（第 1 局部）（本文）解释了为什么因分治而重复使用的应用服务反而能够进步整体效率：因为 NetOps 和 DevOps 团队有不同的要求，所以他们会抉择最适宜他们特定需要的工具。在 Kubernetes 中部署利用交付服务（第 2 局部）以 WAF 为例，就利用交付服务在 Kubernetes 环境中的部署地位提供了领导。您能够依据本人的需要，以基于每个 Service 或基于每个 POD 的形式，将 WAF 部署在 Kubernetes 环境的“前门” 或 Ingress Controller上。如果要说随同 Kubernetes 和云原生架构的增长而产生的最大扭转，那就是 DevOps 团队和利用所有者可能更间接地管制利用的部署、治理和交付形式。 古代利用依赖一套日益成熟的配套“利用交付服务”以确保其在生产环境中胜利运行。利用与其配套服务之间的界线曾经含糊，DevOps 工程师慢慢发现他们须要本人左右或治理这些服务。 咱们通过几个具体的例子理解一下： 灰度和蓝绿部署 —— DevOps 团队将利用推动到生产环境中，有时每天会推送屡次。他们踊跃应用负载均衡器或利用交付控制器 (ADC) 的流量导向性能，先应用大量流量验证新的利用实例，而后再将所有流量从旧实例切换到新实例。DevSecOps 流水线 —— DevOps 团队间接将安全策略构建到 CI/CD 流水线中，例如 Web 利用防火墙 (WAF) 规定集。这些策略被当作又一个利用工件来解决，被主动部署到测试、预生产及生产环境中。尽管 SecOps 团队能够定义安全策略，但 DevOps 执行在生产环境中的理论部署。这些例子都与咱们所说的“利用交付服务”无关 —— 不属于利用的功能性需要，但却是确保利用胜利运行不可或缺的重要能力。这些性能可能是缓存、负载平衡、身份验证、WAF 和拒绝服务（DoS）措施，目标是提供杰出的可扩展性、性能减速或平安防护。 ...

X-Frame-Options头次要是为了避免站点被他人劫持、iframe引入,当被其它网页当做iframe嵌入时，浏览器显示回绝连贯一些提醒，能够通过设置X-Frame-Options解决。配置能够放入到nginx的 http 或者 server 中，nginx配置模式如下: add_header X-Frame-Options ALLOWALL; #容许所有域名iframeadd_header X-Frame-Options DENY; #不容许任何域名iframe,包含雷同的域名add_header X-Frame-Options SANEORIGIN; #容许雷同域名iframeadd_header X-Frame-Options ALLOW-FROM uri; #容许指定域名iframe的uri,如有多个逗号隔开a.com,b.com

依赖一个内置的with-http_stub_status_module模块 配置启用的时候只须要配置server块当中加上一小段拜访url即可获取到 location /status { stub_status on; }docker实现目前采纳nginx:alpine作为镜像，实现拜访http://127.0.0.1/status获取到服务状态信息 因为须要批改/etc/nginx/conf.d/default.conf文件，所以咱们能够抉择挂载一个文件或者从新构建一个镜像 上面咱们创立一个Dockerfile，该文件次要是在default.conf文件应用sed查找server_name localhost;并且在前面退出一段location FROM nginx:alpineRUN sed -i '/server_name localhost;/a\ location /status {\n stub_status on;\n }' /etc/nginx/conf.d/default.conf创立compose.yaml文件如下 services: nginx: container_name: demo-nginx image: demo-nginx build: . restart: always ports: - "80:80"开始构建镜像 $ docker compose build启动容器 $ docker compose up -d查看容器外部nginx配置确认location /status块存在 $ docker exec demo-nginx cat /etc/nginx/conf.d/default.confserver { listen 80; server_name localhost; location /status { stub_status on; } #access_log /var/log/nginx/host.access.log main; location / { root /usr/share/nginx/html; index index.html index.htm; }....后果验证浏览器拜访地址http://127.0.0.1/status获取返回数据如下 ...

前言在文章-腾讯云申请收费SSL证书中, 咱们曾经申请好了SSL证书. 那么当初, 咱们就要配置全站SSL了! 这次的工作次要是NGINX的配置, 同时会有一些我的博客自身的配置. 博客自身配置更改包含: (这篇文章就先不细说了) 网页内链接全副从http改为https(其实配置下SITEURL, 工具会主动生成好) 并从新公布. (特地要留神, 如果有的站内css, js等没有用https就难堪了, 会被各类浏览器拦挡掉, 并提醒"不平安的脚本")网站有用到的第三方工具(如拨测), 把网站的地址改为 https结尾的.NGINX配置首先, 创立并上传筹备好的证书文件到指定目录: (crt和key文件) $ sudo mkdir -p /etc/pki/nginx/# 通过sftp上传到该目录进行nginx.conf 的ssl配置, 本次次要波及到server块的配置更改, 如下: (具体的指令作用见正文) server { listen 80; server_name www.ewhisper.cn; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name www.ewhisper.cn; root /usr/share/nginx/html; # 动态博客的寄存地位 ssl_certificate "/etc/pki/nginx/1_www.ewhisper.cn_bundle.crt"; # 证书门路 ssl_certificate_key "/etc/pki/nginx/2_www.ewhisper.cn.key"; # 证书密钥门路 ssl_session_cache shared:SSL:50m; # ssl session cache调配50m空间, 缓存ssl session ssl_session_timeout 1d; # ssl session 超时工夫为1天 ssl_session_tickets off; # ssl session ticket 机制, 局部版本有bug, 视状况开启. ssl_protocols TLSv1.2; # ssl 协定版本 ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; # ssl ciphers ssl_prefer_server_ciphers on; # 偏向于应用server端的ciphers # HSTS 6 months add_header Strict-Transport-Security max-age=15768000; # 增加个http header, 通知浏览器间接转到https, 此性能有危险, 谨慎抉择. # (比方你的证书过期遗记续了, 那么用户想转到http都没方法) ssl_stapling on; # 启用ssl OCSP stapling性能, 服务端被动查问OCSP后果, 进步TLS效率 ssl_stapling_verify on; # 开启OCSP stapling 验证 # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; # 我的博客的location在这里配置 #location / { #} error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50X.html; location = /50X.html { } } 阐明: ...

原文作者：Amir Rawdat of F5原文链接：NGINX Ingress Controller 在动静 Kubernetes 云环境中的性能测试转载起源：NGINX 官方网站NGINX 惟一中文官网社区 ，尽在 nginx.org.cn 随着越来越多的企业在生产环境中运行容器化利用，Kubernetes 将继续坚固其作为规范容器编排工具的位置。与此同时，在疫情中崛起的居家办公模式放慢了互联网流量的增长，导致云计算需要提前几年暴发。目前很多公司都在紧锣密鼓地降级基础架构，帮忙客户解决正在面临的重大网络中断和过载问题。 为了在基于云的微服务环境中达到所需的性能程度，您须要应用疾速、齐全动静的软件来开释下一代超大规模数据中心的可扩展性和性能后劲。许多应用 Kubernetes 治理容器的企业和机构都依赖基于 NGINX 的 Ingress Controller 来实现利用交付。 在这篇博客中，咱们针对在互联网中客户端连贯的提早状况，提供了三种 NGINX Ingress Controller 在实在多云环境中的性能测试后果。这三种控制器别离为： 基于 NGINX 开源版的NGINX Ingress Controller，由 Kubernetes 社区保护。咱们在之前的博客中称之为_“社区版 Ingress Controller”_，本篇文章也将沿用这个说法。咱们从Google Container Registry中提取了其 0.34.1 版本的镜像，用于此次测试。NGINX 开源版 Ingress Controller1.8.0，由 NGINX 保护。NGINX Plus Ingress Controller1.8.0，由 NGINX 保护。测试方法和收集的指标咱们使用性能测试程序 wrk2 模仿了一个客户端，在规定的时间段内收回间断的 HTTPS 申请。被测试的 Ingress Controller（社区版 Ingress Controller、NGINX 开源版 Ingress Controller 和 NGINX Plus Ingress Controller）将申请转发到部署在 Kubernetes Pods 中的后端利用，并将利用生成的响应返回给客户端。咱们生成了稳固的客户端流量，并应用这些流量对 Ingress Controller 进行压力测试，收集了以下性能指标： ...

原文作者：Frances Fedoriska of F5 原文链接：如何应答突发的流量激增和服务器过载问题 转载起源：NGINX 官方网站 NGINX 惟一中文官网社区 ，尽在 nginx.org.cn 在新冠疫情的冲击下，许多零售商的客户都扭转了他们假日购物的渠道和形式。因为人们无奈去实体店购物，线上购物迎来了前所未有的新高潮——2020 年美国的电子商务销售额飙升至 1,890 亿美元，比 2019 年增长了 33%。当初购物狂欢节还有不到六个月的工夫，[LK1] 咱们在此提供了几种利用 NGINX 帮忙您为突发的流量顶峰做好筹备的办法。 第 1 步：知己知彼在调整堆栈之前，最好先理解您须要在多大程度上优化您的网站性能，能力在购物狂欢季有最佳（而不是勉强合格）的体现。先从收集竞争对手网站的性能数据开始吧。页面加载工夫可能是最重要的指标，因为现在许多用户都没有急躁，只有网页加载工夫超过三秒，他们就会来到。测量加载工夫的工具有很多，并且大多都是收费的。您无妨参考一下Geekflare 最近测评的 11 款测试工具。 您可思考测量以下页面的加载工夫： 主页产品搜寻页面产品详情页面点击“购买”按钮后呈现的确认页面测试几个竞争对手和您本人的网站的要害页面只需几个小时。（在测量下载工夫之前，请务必应用Shift+Refresh革除浏览器缓存。）有测量后果的加持，您接下来须要做的是： 制订总体性能指标。对不同的网站来说，从头到尾的整个流程（拜访、搜寻及购买）共须要多长时间？确定优劣势。找出您的网站有劣势、有竞争力或拖后腿的中央。留神性能差别。竞争对手如何通过额定的性能晋升购物体验？您的网站提供了哪些性能来打造独特的用户体验？制订打算。如果您的网站在一个或多个方面远远落后于竞争对手，那么您须要致力达到他们的均匀响应工夫；如果您已领有很强的竞争力，则致力成为第一名吧。第 2 步：应用 NGINX，就像那些寰球最忙碌的网站一样2021 年的早些时候，NGINX在互联网 Web 服务器排名中荣登第一宝座。咱们很荣幸有这么多网站信赖咱们，应用咱们的产品交付网站和利用，同时咱们也十分欢迎您的退出。然而，NGINX 不仅仅是一个 Web 服务器，它还是一个一体化的软件反向代理、负载均衡器、高速缓存和API 网关。 NGINX 最重要的劣势之一是它能够大大优化进入您网站的流量。您能够将 NGINX 看作是在商店门前治理人流的看门人。它可能对购物者的操作（HTTP 申请）进行排队和受权，就像把人行道上凌乱的人群变成商店内顺畅有序的结账队列。它可能将购物者疏导至购物清单上商品的特定地位，确保流量均匀分布，且所有资源都失去平均应用。 NGINX 次要应用两种开箱即用的技术来实现这一点： 通过应用 keepalive 连贯进行 HTTP 卸载，目标是缓冲迟缓达到的 HTTP 申请，并等到它们准备就绪后再将其转发到后端服务器。相比远端客户端，从 NGINX（位于疾速的本地网络）发动的事务的实现速度要快得多。具备多种算法的成熟的负载平衡，目标是优化流量散布，并尽可能高效地应用服务器资源。除了优化流量外，NGINX 还提供了以下四种形式帮忙您优化网站，并避免流量激增期间呈现服务器过载问题。 浏览详情： 通过高速缓存缩短网页响应工夫通过流量管制治理访客流量通过按需弹性扩大减少弹性通过内置平安防护爱护客户数据通过高速缓存缩短网页响应工夫很多性能都会减少在线交易的胜利几率，比方点击珍藏、线高低单并线下取货，甚至客户领取选项等。NGINX 的内容缓存性能与 Web 流量有着相似的成果。NGINX 会主动存储它发送给客户端的每个文件，并间接利用缓存来解决给定文件的后续申请。高速缓存不仅能够放慢对用户的响应速度，而且还能够缩小上游服务器上的负载，因为对于雷同的申请，它们不用总是从头开始重复进行解决。内容缓存能够将外部流量缩小 100 倍，从而缩小服务利用所需硬件的解决能力（具体取决于利用）。 无关高速缓存和示例配置的更多详情，请参阅咱们的博文《高速缓存和微缓存站点内容》和《NGINX 和 NGINX Plus 高速缓存指南》。 ...

背景前端工夫上线我的项目的时候，因为第一次上线没有教训。报了几个谬误。 405 Not allowed过后的nginx.conf配置 server { listen 80 default_server; listen [::]:80 default_server; access_log /var/log/nginx/host.access.log main; location / { root /usr/share/nginx/html; index index.html index.htm; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://gitlabwebhooktogithub-api:8088/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } #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 /usr/share/nginx/html; }}405 报错服务器上应用 nginx 启动的时候 并拜访如下时，报了 405 Not allowed 异样 ...

原文作者：汤炜涛原文链接：分享实录 | NGINX QUIC & HTTP/3 最新进展转载起源：NGINX 开源社区NGINX 惟一中文官网社区 ，尽在 nginx.org.cn 编者按——本文为 NGINX Sprint China 2022 年度线上大会的分享实录，点击文末此处收费观看大会残缺视频回放。 Internet 从未进行过后退的脚步。早在 2015 年 HTTP/2 标准化之前，QUIC 的相干工作就曾经开始了，而在之后 QUIC 成为了 HTTP/3，当然，演变之路并不是那么轻松。现在 QUIC 和 HTTP/3 协定倒退到何种水平？本次分享汤炜涛老师回顾 HTTP 协定的倒退历程。 介绍 QUIC 和 HTTP/3 协定，HTTP/3 协定的长处以及为什么须要 HTTP/3 协定。介绍 NGINX 对 QUIC 和 HTTP/3 协定的反对，解说版本要求和配置办法。 HTTP协定的倒退 首先简短回顾一下 HTTP 协定倒退历程。HTTP 协定最早诞生在欧洲核子核心，目前咱们把在 HTTP/1.0 正式公布之前的所有协定统称为 HTTP/0.9，最后的 HTTP/0.9 是一个非常简单的协定，仅有 GET 一种办法，直到 HTTP/1.0 才倒退成了大家当初所相熟的 HTTP 协定，当初为止 HTTP/1.0 仍然在宽泛的应用。 HTTP/1.1 以 HTTP/1.0 为根底进行了一些优化，是目前为止互联网应用最多的协定。它最大的优化在于引入了会话机制，当咱们的客户端和服务器之间间断申请多个资源时，并不会像 HTTP/1.0 一样，每申请一个资源就建设一个 TCP 连贯，而是保留一个 TCP 会话连贯，后续的资源都能够用已有的 TCP 连贯来去进行传输，减少了 TCP 连贯的应用效率。 ...

谷歌外部应用了许多不同的操作系统平台，其中包含 Linux。15 多年前，谷歌抉择基于 Ubuntu LTS 构建外部 Linux 发行版 Goobuntu，次要是看中了 Ubuntu 具备用户敌对、易于应用的个性，以及提供了许多优良性能。谷歌外部应用了许多不同的操作系统平台，其中包含 Linux。15 多年前，谷歌抉择基于 Ubuntu LTS 构建外部 Linux 发行版 Goobuntu，次要是看中了 Ubuntu 具备用户敌对、易于应用的个性，以及提供了许多优良性能。此外，LTS 会取得 Canonical 提供 2 年以上的安全更新。依据官网介绍，Goobuntu 是谷歌长期以来始终应用的 Linux 发行版。不过 Ubuntu LTS 的两年更新周期意味着谷歌必须在操作系统 EOL 之前，对超过 10 万台设施中的每台机器进行降级。这是一项十分艰难且耗时的工作，毕竟每两年让所有工程师从头开始配置他们的工作空间，这对生产力是重大的打击，并且从经济角度来看也是一个不负责任的选项。在每个操作系统应用周期内，谷歌还面临软件包重大版本升级的挑战，因为这可能须要对软件配置进行重大扭转。为了让这个过程自动化，谷歌工程师编写了一个无人值守的降级工具来解决很多常见的问题。这种 “自动化降级” 意味着大多数谷歌员工无需通过重新安装机器，并从新创立所有配置来手动降级。不过为了实现这一点，谷歌须要对降级过程进行全面测试，并查看所有已更改的次要软件包是否持续运行（在 Ubuntu 中，次要版本之间的降级可能多达数千个软件包）。有时，在产生软件包弃用且工程师必须决定如何推动的状况下，很难提供自动化。据称，谷歌实现所有 Goobuntu 的降级通常要花费一年的工夫，整个过程对于团队来说是一个微小的压力。而且很多时候他们遇到的一些 bug 曾经在上游被修复了，但这些改良却从未被合并到所应用的 LTS 版本。因而谷歌转向了滚动更新发行版，不过它没有抉择出名的滚动更新发行版 Arch Linux，而是基于 Debian 测试分支构建了 gLinux Rodete (Rolling Debian Testing)。抉择 Debian 是因为它有着宏大的社区和软件库，还能够应用 Debian 格局的现有外部软件包和工具。而且 Ubuntu 也是基于 Debian，迁徙过来更容易顺畅。Debian 稳固分支也是差不多两年公布一次大更新，但其测试分支是滚动更新的。滚动更新意味着须要尽可能避免新版本对现有工作流程造成毁坏，为了治理从源代码构建所有上游软件包的所有这些简单工作，谷歌构建了一个名为 Sieve 的工作流零碎。通过运行一个虚拟化测试套件，确保外围组件和开发者工作流程都不会被新版本软件包毁坏。谷歌示意，Goobuntu 最初一个版本基于 Ubuntu 14.04 LTS（代号 Trusty）。Rodete 的开发始于 2015 年，2017 年，谷歌开始将机器迁徙到 Rodete，并在 2018 年底实现所有迁徙。2019 年初敞开了最初一批运行 Goobuntu 的机器。2020 年中，Rodete 齐全跟上了 Debian Bullseye 的公布工夫。将来谷歌打算与上游 Debian 更严密地单干，并奉献更多的外部补丁来保护 Debian 软件包生态。 ...

Calibre 开源我的项目是 Calibre 官网出的电子书管理工具。它能够查看，转换，编辑和分类所有支流格局的电子书。Calibre 是个跨平台软件，能够在 Linux、Windows 和 macOS 上运行。Calibre 6.3 正式公布，此次更新内容如下：新性能电子书阅览器：容许应用新的 "Nearby words" 搜寻模式来搜寻左近的字Calibredb：新的 fts_search 和 fts_index 命令，能够从命令行执行全文搜寻。图片浏览弹出窗口：容许应用 Ctrl+plus/minus 的规范快捷键进行缩放谬误修改修复了 calibre 6.0 中的一个回归，该回归会毁坏对某一列之前排序程序的记忆修复了 calibre 6.0 中的一个回归，它毁坏了对高分辨率图像的解决全文搜寻：修改当应用限度搜寻的书籍和超过 900 本书籍存在于搜寻列表中的谬误电子书查看器：修复带有 @supports 规定的 CSS 款式解析不工作的问题电子书阅览器：放慢书籍的初始渲染Google 图书元数据下载：修复段落不被辨认的问题内容服务器：修复光明模式下评论编辑器的浅色背景内容服务器：修复浏览非白 / 黑配色的书籍时边缘和注释背景色彩不匹配的问题内容服务器：修复在笔记编辑区长点鼠标时不正确地扭转高亮范畴的问题Google 搜索引擎：修复葡萄牙的 Google 服务器应用的不同 URL 编码

微软将于往年7月底正式完结为期一年的Windows 10收费降级流动，如果你以后正用着Windows7/8.1，还请务必抓住最初几个月的机会。不过对于运行Windows XP或Vista的老用户来说，想要破费较少的代价降级至最新的Windows 10操作系统，就只剩下购买受权这条路了。侥幸的是，在7月29号之前，你仍可通过网络渠道和曲折的战术，破费10美元降级至Windows 10。你所须要做的，就是去购买一个便宜的Windows 7产品密钥。根本的步骤是：（1）在网上搜寻“收费的”Windows 7产品密钥（购买一个）；（2）在计算机上安装Windows 7；（3）将零碎直升至Windows 10。如此一来，你就省下了购买Windows 10家庭版所需的119美元（110欧）。或者有人感觉找一个便宜Windows 7受权并非易事，但事实截然相同。在万能的eBay等C2C平台上，有不少用户（甚至零售商）在抛售便宜的Windows 7产品密钥，有些甚至低至数美元。最初对那些正在应用Windows 7/8.1的用户说一句，尽管Windows 10当初还并不完满，但大不了给旧零碎做个备份，收费降级到Windows 10后再降回来，先把收费的Win10拿到手再说，今后用任何形式重装Win10都会主动联网激活。

如果你想取得平安的体验，你可能不会再持续应用 32 位 Linux 内核。咱们有很多 为 32 位零碎定制的 Linux 发行版。那么，为什么我想要不激励应用 32 位，而降级到 64 位 Linux 呢？有几个起因，其中一个最大的起因，在本周引发了很多关注。32 位：古老的电子垃圾硬件？没错，与其余操作系统不同的是，Linux 发行版容许你从新利用旧硬件。你可能将一个老机器转换为 媒体服务器、存储服务器，等等。在这里，我并不是要给你一些如何奉献更多的电子垃圾的思路。尽可能长地利用你的硬件，而不更换它们总是好的。然而，不应用 32 位零碎的理由可能比以往更有说服力。要害的问题是在平安和保护方面。利用 64 位 Linux 进步安全性2018 年，危险的处理器平安问题 Spectre 破绽引发了热议。尽管英特尔和 AMD 对这个破绽进行了修复，但状况并不乐观。可怜的是，一个新的破绽 Retbleed，它是 Spectre 的一个变种，正在影响英特尔和 AMD 芯片。你能够在上面由发现它的钻研人员分享的视频中看到它的状况。此处应有视频，地址： https://img.linux.net.cn/stat...因而，咱们天然须要适当的措施来解决这个新的安全漏洞的修复问题。令人震惊的事件来了。64 位 Linux 内核曾经收到了对它的修复，以爱护无关的英特尔/AMD 的处理器。然而，正如 Phoronix 所报道的，Linux 32 位内核依然容易受到 Retbleed 破绽的影响。英特尔的 Pawan Gupta 在 内核邮件列表 中回应了这些担心，他提到：英特尔不晓得还有谁在 Skylake 那一代的 CPU 上应用 32 位模式的生产环境。所以这不应该是一个问题。另外，很少看到为 32 位保护所做的任何致力。所以，这应该不算什么意外。因而，如果你应用你的零碎进行任何可能受到平安问题影响的工作，你应该避开 32 位内核。当然，如果你有一个齐全离线的环境能够算做例外。所以，你能够这样做，但不倡议这样做。不关怀平安问题？即便你认为得不到像 Retbleed 这样的要害平安修复没有关系，2022 年的 32 位零碎也会有更多的麻烦。软件维护者们最终会放弃对 32 位零碎上的工具和 Linux 发行版的更新。因而，你的 32 位 Linux 零碎可能很快就不会再有踊跃保护的程序了。因而，当初进行转换（和降级）将是一个好主见。你还在应用 32 位的 Linux 吗？你对此有什么认识？在上面的评论中分享你的想法。 ...

背景：有/www/wwwroot/example-h5/www/wwwroot/example-pc两个目录， 须要依据用户端， 响应不同的页面 解决方案依据用户UA不同， 响应正确的页面给用户 # 默认响应挪动端动态资源set $root_dir /www/wwwroot/example-h5;# !~* 是一条正则表达式，!示意取反， ~*示意不辨别大小写 if ($http_user_agent !~* "(mobile|nokia|iphone|ipad|android|samsung|htc|blackberry)") { # 非挪动端UA， 响应PC动态资源 set $root_dir /www/wwwroot/example-pc;}location / { # root 应用下面定义的变量 root $root_dir; try_files $uri $uri/ /index.html =404; #index index.html;}

工作环境中不能随便往服务器上传文件，或者嫌用rz/sz命令太慢，能够试试用nginx。 编译nginx： ./configure --prefix=../nginx --with-http_dav_modulemake -j 2make install参考配置： #user nobody;worker_processes auto;error_log logs/error.log;#error_log logs/error.log notice;#error_log logs/error.log info;pid logs/nginx.pid;events { worker_connections 256;}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 uplsrv; #charset koi8-r; client_body_buffer_size 128k; client_max_body_size 1G; access_log logs/uplsrv.access.log main; location / { root /home/work/upl; autoindex on; } location ~ "/upl/([0-9A-Za-z.-_]*)$" { alias /home/work/upl/$1; dav_methods PUT DELETE; dav_access group:rw all:r; client_body_temp_path /tmp/upl; #create_full_put_path on; } }}应用Postman测试： ...

原文作者：Amir Rawdat of F5 原文链接：应用 NGINX 在 Kubernetes 中对 TCP 和 UDP 流量进行负载平衡 转载起源：NGINX 官方网站NGINX 惟一中文官网社区 ，尽在 nginx.org.cn 除了 HTTP 流量之外，NGINX Ingress Controller 还能够负载 TCP 和 UDP 流量，因而您能够应用它来治理基于以下协定的各种利用和实用程序的流量，它们包含： MySQL、LDAP 和 MQTT—— 许多风行利用应用的基于 TCP 协定的利用DNS、syslog 和 RADIUS—— 边缘设施和非事务性利用应用的基于 UDP 协定的实用程序在以下状况下，应用 NGINX Ingress Controller 进行 TCP 和 UDP 负载平衡也是一种将网络流量分发给 Kubernetes 利用的无效解决方案： 您正在应用端到端加密 (EE2E)，并且让利用（而非 NGINX Ingress Controller）来解决加密和解密您须要对基于 TCP 或 UDP 的利用施行高性能负载平衡在将现有网络 (TCP/UDP) 负载均衡器迁徙到 Kubernetes 环境时，您心愿尽量减少更改NGINX Ingress Controller 自带两个反对 TCP/UDP 负载平衡的 NGINX Ingress 资源： ...

有时候咱们的我的项目不可能都是同一个PHP版本，须要每个我的项目都配置不同版本的PHP，宝塔和PHPStudy就是通过以下配置实现的： Nginx切割conf（非选）在nginx.conf增加 include vhosts/*.conf;这样Nginx会主动引入当前目录->vhosts目录下的所有*.conf文件，不便每个我的项目独自治理Nginx配置文件 配置多版本PHP在conf文件中减少 server { listen 80; server_name localhost; root "D:/WWW"; location / { index index.php index.html; include D:/WWW/nginx.htaccess; autoindex on; } location ~ \.php(.*)$ { fastcgi_pass 127.0.0.1:9010; fastcgi_index index.php; fastcgi_split_path_info ^((?U).+\.php)(/?.+)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; include fastcgi_params; }}fastcgi_pass是PHP执行IP+端口fastcgi_index默认PHP文件fastcgi_split_path_info是正则fastcgi_param是PHP所在目录（Nginx会主动获取赋值给$fastcgi_script_name）假如咱们有两个PHP版本，一个PHP5，一个PHP7，那么能够将他们别离运行在不同的端口上，而后通过设置fastcgi_pass参数来实现每个我的项目不同PHP版本 Apache切割conf（非选）在httpd.conf增加 Include conf/vhosts/*.conf这样Apache会主动引入Apache装置目录->conf->vhosts目录下的所有*.conf文件，不便每个我的项目独自治理Apache配置文件 配置多版本PHP在conf文件里增加 FcgidInitialEnv PHPRC "D:/Extensions/php/php8.2.2-nts" AddHandler fcgid-script .php FcgidWrapper "D:/Extensions/php/php8.2.2-nts/php-cgi.exe" .php指定对应目录即可

在nginx中配置vue我的项目的时候，相似于location /XXX {}这种，会呈现很多问题，比方404，403，刷新404等等状况，还是没有搞懂什么起因，不过却找到了解决办法，记录一下，避免遗记！ 批改vue我的项目中vue.config.js文件中的 publicPath在生产环境中的子门路。 publicPath: process.env.NODE_ENV === "production" ? "/子门路" : "/",在vue我的项目中router目录下index.js文件中 export default new Router{}的节点中增加或者批改base: 子门路属性。 export default new Router({ mode: 'history', // 去掉url中的# base: process.env.BASE_URL, //获取 publicPath的值，这里获取依据环境不同获取不同的publicPath ...其余配置 })如上配置，就会在生产环境中拜访我的项目时，在域名前面会主动加上 /子门路，例如： http://XXXX.com/子门路/index在nginx中配置 location /子门路 { alias E:/workspace/theFrontEnd/a/dist; #autoindex on; try_files $uri $uri/ /子门路/index.html; index index.html index.htm; }须要留神的点：[location /子门路{}] 中的子门路必须要与vue我的项目中的子门路雷同，并且在[try_file $uri $uri/ /子门路/index.html;]中的子门路也必须要与vue我的项目中的子门路雷同。还有就是 [alias E:/workspace/theFrontEnd/a/dist;]这行要应用alias不要应用 root。 5.反思nginx学的不是太好，是不是 nginx通过 location代理 vue我的项目的打包门路，如果location的门路为 / 还好，会间接拜访vue打包门路中的文件，如果 location 的门路不是 / 而是 /XXX,那么通过nginx拜访vue我的项目时，就会在门路上增加 /XXX 这个子门路，所以就404了。所以要在vue我的项目中增加子门路，保障vue我的项目中的子门路跟nginx中location门路保持一致！

引言 晚期的业务都是基于单体节点部署，因为后期拜访流量不大，因而单体构造也可满足需要，但随着业务增长，流量也越来越大，那么最终单台服务器受到的拜访压力也会逐渐增高。工夫一长，单台服务器性能无奈跟上业务增长，就会造成线上频繁宕机的景象产生，最终导致系统瘫痪无奈持续解决用户的申请。 从下面的形容中，次要存在两个问题： ①单体构造的部署形式无奈承载日益增长的业务流量。②当后端节点宕机后，整个零碎会陷入瘫痪，导致整个我的项目不可用。因而在这种背景下，引入负载平衡技术可带来的收益： 「零碎的高可用：」 当某个节点宕机后能够迅速将流量转移至其余节点。「零碎的高性能：」 多台服务器独特对外提供服务，为整个零碎提供了更高规模的吞吐。「零碎的拓展性：」 当业务再次出现增长或萎靡时，可再退出/缩小节点，灵便伸缩。OK~，既然引入负载平衡技术可给咱们带来如此微小的益处，那么又有那些计划可供选择呢？次要有两种负载计划，「「硬件层面与软件层面」」 ，比拟罕用的硬件负载器有A10、F5等，但这些机器动辄大几万乃至几十万的老本，因而个别大型企业会采纳该计划，如银行、国企、央企等。而老本无限，但仍旧想做负载平衡的我的项目，那么可在软件层面实现，如典型的Nginx等，软件层的负载也是本文的重点，毕竟Boss们的准则之一就是：「「能靠技术实现的就尽量不花钱。」」 性能怪兽-Nginx概念深入浅出Nginx 是目前负载平衡技术中的支流计划，简直绝大部分我的项目都会应用它，Nginx 是一个轻量级的高性能HTTP反向代理服务器，同时它也是一个通用类型的代理服务器，反对绝大部分协定，如TCP、UDP、SMTP、HTTPS等。 Nginx与Redis雷同，都是基于多路复用模型构建出的产物，因而它与Redis同样具备 「「资源占用少、并发反对高」」 的特点，在实践上单节点的Nginx同时反对5W并发连贯，而理论生产环境中，硬件根底到位再联合简略调优后的确能达到该数值。 先来看看Nginx引入前后，客户端申请解决流程的比照： 本来客户端是间接申请指标服务器，由指标服务器间接实现申请解决工作，但退出Nginx后，所有的申请会先通过Nginx，再由其进行散发到具体的服务器解决，解决实现后再返回Nginx，最初由Nginx将最终的响应后果返回给客户端。 理解了Nginx的基本概念后，再来疾速搭建一下环境，以及理解一些Nginx的高级个性，如动静拆散、资源压缩、缓存配置、IP黑名单、高可用保障等。 Nginx环境搭建❶首先创立Nginx的目录并进入： [root@localhost]# mkdir /soft && mkdir /soft/nginx/ [root@localhost]# cd /soft/nginx/ ❷下载Nginx的安装包，能够通过FTP工具上传离线环境包，也可通过wget命令在线获取安装包： [root@localhost]# wget https://nginx.org/download/nginx-1.21.6.tar.gz 没有wget命令的可通过yum命令装置： [root@localhost]# yum -y install wget ❸解压Nginx的压缩包： [root@localhost]# tar -xvzf nginx-1.21.6.tar.gz ❹下载并装置Nginx所需的依赖库和包： [root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ gcc-c++ [root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ pcre pcre-devel4 [root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ zlib zlib-devel [root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ openssl openssl-devel 也能够通过yum命令一键下载（举荐下面哪种形式）： ...

1. nginx配置https拜访1.1 应用 nginx -V产看编译参数中是否含有 --with-http_ssl_module ,如果没有则持续操作，如果有则跳到1.6步。留神：nginx如果曾经装置了其余模块，在装置新模块编译时，必须也要带上其余模块的编译参数，不然会抛弃掉其余模块！ 编译参数就是通过nginx -V查看的！1.2 装置 OpenSSL yum -y install openssl openssl-devel1.3 在nginx的安装包目录下从新编译,留神不是 /usr/local/nginx/目录下，这是装置目录，不是安装包目录，编译要在安装包目录下进行，当然，装置目录下也没有configure这个可执行文件。 ./configure --prefix=/usr/local/nginx --with-http_ssl_module1.4 持续在安装包目录下执行make命令进行编译，留神为了保险起见，不要执行 make install这样会重新安装nginx，尽管很多人说执行没有关系，不会笼罩 nginx.conf文件，然而防着点总归没有错。 make1.5 在make完之后，先停掉nginx服务。在安装包目录中有一个objs目录（跟configure可执行文件平级），将objs目录下的nginx文件复制到 /usr/local/nginx/sbin/目录下，笼罩掉其中的nginx可执行文件（当然，这里重名或者备份之后再删除，做好备份），命令如下： # 将编译实现的 nginx可执行文件 复制到 nginx的装置目录下的 sbin中，笼罩掉其中的nginxcp /nginx安装包目录/objs/nginx /usr/local/nginx/sbin/1.6 将SSL证书复制到 /usr/local/nginx/conf/目录中，如下名称： 证书名称.pem证书名称.key1.7 批改/usr/local/nginx/conf/nginx.conf文件 server { listen 443 ssl; server_name 证书对应的域名; charset utf-8; ssl_certificate 证书名称.pem; ssl_certificate_key 证书名称.key; ssl_session_cache shared:SSL:1m; ssl_session_timeout 5m; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; ...上面是配置 location 内容}1.8 启动nginx，应用https拜访。1.9 将http申请转为 https申请 # 在申请形式为 http的server中，所有的location下面增加如下代码rewrite ^(.*) https://$server_name$1 permanent;# 如果http申请端口不是80，则用上面的rewrite ^ https://$server_name$request_uri? permanent;2. 一个server中配置多个动态资源的location时留神的问题上面两个是动态资源的location,启动nginx没有问题，拜访 https://XXXX/a.png 也没有问题，然而拜访 https://XXXX/other/c.jpg 就呈现问题了，拜访不到。 ...

书接上文：HTTPS 根底原理和配置 - 2，接下来介绍： 配置 NGINX后端 HTTPS查看配置配置 HSTSOCSP Stapling重要局部来了。如何应用这些选项并配置NGINX? 一、NGINX 的 HTTPS 配置这里有一些根本的原语（或叫做指令），你能够应用:ssl_certificate、ssl_certificate_key、ssl_protocols 和ssl_ciphers。 1.1 NGINX 配置参数（OpenSSL）在开始之前: NGINX 解决 TLS 的形式是应用 OpenSSL，我置信你曾经在新闻中据说过这个库。它因 Heartbleed 和其余一些破绽而闻名。它的确是最宽泛应用的内置加密库。这是 NGINX 用于加密的。 因而，在服务器上要做的一件事是查看正在应用的 OpenSSL 版本。你可能不想应用 0.9.8 之类的版本。你心愿在1.0.1p 或 1.0.2 范畴内应用，因为多年来他们曾经修复了许多 bug。你永远不晓得下一个 OpenSSL 破绽什么时候呈现，但至多当初它是十分牢靠的(1.0.1p)。它还领有所有古代加密算法。 1.2 NGINX 配置证书链和私钥所以，当你在 NGINX 中设置你的服务器局部时，ssl_certificate 就是你的证书链。这是你的证书加上所有的信赖链始终到根证书。而后你还须要提供你的私钥。 ssl_certificate_key 就是你的私钥。 server { listen 443 ssl http2; listen [::]:443 ssl http2; ssl_certificate /path/to/signed_cert_plus_intermediates; ssl_certificate_key /path/to/private_key; ssl_session_timeout 1d; ssl_session_cache shared:MozSSL:10m; # about 40000 sessions ssl_session_tickets off; # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam ssl_dhparam /path/to/dhparam; # intermediate configuration ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on;}1.3 额定选项你还能够增加一些与会话复原无关的额定选项。如前所述，当你第一次建设 TLS 连贯时，须要额定的两次往返，因为你必须实现整个握手和替换证书。如果你以前连贯过一个客户端，并且他们曾经缓存了会话传输所应用的密钥，那么你能够只复原该会话。这是一个称为会话复原的个性。 ...

说实话，如果古希腊的西西弗斯是一个在2016年编写开源代码的开发者，那他会有宾至如归的感觉。驰名的西西弗斯处罚，是神话流传下来的，他被迫推一块微小的石头上山，当登顶之后，只能眼睁睁看着它滚下去，周而复始直到永远。悄无声息的，寰球的开发者在过来的几年里，也在承受相似的处罚。而且巨石还在一直变大。美国国会图书馆领有约2400万本各种类型的图书。它是人类有史以来，发明的书写人类常识最大的宝库。2009年，Github成立。它当初领有超过3500万软件库或信息库，有着几十万亿行代码。钻研表明，这一数额以指数速度增长，每14个月左右还会双倍增长。凋谢源代码是毫无疑问明天编程技术的前沿，是人类常识最大的、性能最弱小、最先进的宝库。那么，为什么90％-98％的开放式源代码，12个月后会被摈弃？细节处见代码咱们先来看一组惊人的数字：明天写的代码，明年今日，90％以上将永远不会被再次应用。它们变得有效、过期，在工夫的流沙中被忘记。在2015年考察中，Stack Overflow发现，每个开发者在工作之外一周均匀破费大概7小时来编程。 GitHub的报告指出超过1200万用户在开源我的项目工作。数百万聪慧的人花了数百万个小时的工作就这样被人们束之高阁了。最疯狂的一部分是仿佛没有人问“为什么？”。为什么绝大多数凋谢源代码被埋葬，被遗记了？为什么咱们每一天一遍又一遍地编写雷同的代码，而同一时间该代码简直能够必定就在开源平台的某处， 在期待被咱们应用的？这种事产生的次要起因是，因为人们只是把信息库作为存储库。开发者都晓得AngularJS，或JQuery的或React，但很少有人晓得超过10个开源软件包。这就是让人疯狂的局部，因为人们不晓得、或者不应用整个开源软件包，所以没有人应用其中的代码。写于2015年的软件包可能对一个人来说不是整体都有用，但兴许它恰好就蕴含了所需的性能。最有用的局部不总是整个包，有时是其中的一段代码。比方说，有人正在寻找一个JavaScript的性能以在数组中洗牌元素，或不同的性能来创立随机的字符串。这些小的代码片段在开源平台有几百个雷同的。然而，没有人晓得他们的存在，即便他们晓得，也没有人晓得如何找到它们。因而，这些有价值的常识被抛弃或忘记，只是因为它们难以获得。切实太扯了，对所有人而言都没益处。整顿所有代码，并使其不便找到那么，咱们要如何解决这个烂摊子？答复这个问题很容易，做起来就很难，你须要做三件事件：从性能方面整顿所有凋谢的源代码，对它们进行具体分类建设一个模型来示意这些不同代码的理论性能创立一个容易简略的办法来搜寻和查找这些代码片段。这就是咱们建设Cocycles的起因。Cocycles满足上述所有的条件，同时还在持续欠缺。它的算法能够解决大量的开源代码，浏览和了解每一条不同的代码的性能。而后，它能够让人们应用简略的英文来搜寻代码。例如，用户只须要输出“洗牌阵列”或“创立随机字符串”，而后它们会用各种凋谢源代码执行、文档、用法示例和更多的形式出现。它甚至会提供生成的蕴含所有的从属和子性能的有用片段。在将来的几年后，人工智能软件兴许可能用它来寻找和学习新的代码；不断完善和扭转代码。

原文作者：Rich Burroughs of F5 原文链接：利用混沌工程进步微服务的弹性 转载起源：NGINX 官方网站 NGINX 惟一中文官网社区 ，尽在 http://nginx.org.cn/ 微服务备受服务开发和部署团队的欢送。在微服务架构下，开发人员能够应用更小、更具针对性的代码库，并且在服务部署的工夫和形式上领有更大的独立性。与单体架构相比，这些劣势很显著。 然而，世上没有收费的午餐。随着从单体架构过渡到微服务，复杂性并不会隐没，只是地位稍有转移。较小的代码库有助于更轻松地开发单个微服务，然而在生产中来操作微服务的时候复杂性会成倍的减少。 在应用微服务构建的零碎中，可能运行着更多的主机和/或容器——更多的负载均衡器、更多的防火墙规定等。您可能会依据不同的微服务将 NGINX 用于不同的目标（Web 服务、反向代理、负载平衡）。随着服务数量从数十扩大到数百甚至数千，理解零碎和预测零碎行为变得愈发艰难。此外，这些服务都通过网络互相通信，而不是通过单体架构外部的模块间调用。 咱们如何验证基于微服务的零碎不仅可能在失常条件下按设计运行，而且还可能应答环境中的意外故障或性能降落问题呢？混沌工程是一种不错的验证办法。混沌工程实际可帮忙团队更好地治理生产环境中运行的利用并进步零碎弹性。 什么是混沌工程？咱们将混沌工程定义为三思而行、计划周密的试验，旨在发现零碎缺点。咱们常常将混沌工程比作疫苗接种，疫苗接种是将潜在的有害物质注射到体内，以防将来产生感化。在混沌工程试验中，咱们被动将“故障”注入零碎，以测试零碎的弹性。咱们采纳迷信无效的试验办法：提出假如，发展试验，而后察看是否验证了假如。 可注入零碎的故障类型包含敞开主机或删除容器、减少 CPU 负载或内存压力，以及减少网络提早或丢包等。这些只是举例说明，当然还有其余可注入的故障类型。 提出假如混沌工程试验的第一步是提出假如。依据注入的故障，咱们会对系统可能产生的影响做出一个预期，这个就是假如。请记住，咱们的目标是测试零碎的弹性。一般来说，咱们假如零碎可能应答咱们注入的故障类型。但有时咱们会发现假如有误，这时咱们能够利用取得的信息来改善零碎的弹性。 举例来说，假如有一个无状态 HTTP 服务在 NGINX 上运行，后者将一个 REST API 裸露给了其余一些服务。该服务的一个实例同时在生产环境中的 10 台主机上运行，能够确保在以后业务负载下，不会耗尽每台主机的 CPU 资源。咱们可通过被动敞开一台主机，测试咱们的零碎是否足够强壮。 在这种状况下，咱们的假如是“零碎可能应答一台主机的故障，不会对其余服务或应用该零碎的人员产生影响。”接下来咱们就能够通过试验，来确认咱们的假如是否正确。 爆炸半径、量级和停止条件在布局试验时要牢记三个重要概念：爆炸半径、量级和停止条件。上面咱们来具体理解一下这三个概念。 爆炸半径—— 是咱们试验所用主机（或容器）的占比。这是一个十分重要的概念，即便在非生产环境中，咱们也须要最大限度缩小试验对用户的潜在影响。咱们先从较小的爆炸半径开始（比方一台主机或一个容器），而后随着对试验的理解及掌控水平越来越深，逐步减少爆炸半径。量级—— 是咱们给各个主机（或容器）施加的压力大小或故障水平。举例来说，如果咱们要测试一个 CPU 攻打对 NGINX Web 服务器的影响，咱们可能会在试验一开始多施加 20% 的 CPU 负载（量级），之后随着工夫的推移一直减少。咱们能够察看减少 CPU 负载对响应工夫等服务指标的影响，从而确定零碎在性能解体之前能够接受多大的攻打。停止条件—— 是导致咱们中断试验的条件。最好能提前晓得当零碎承受不住试验无奈持续时，会呈现哪种类型（或水平）的影响。可能是错误率或提早的减少，也可能是监控软件生成的某个警报。您能够依据须要定义停止条件，能够依据理论的试验环境而不同。爆炸半径、量级和停止条件可能让咱们平安地进行混沌工程试验。在制订混沌工程试验打算时，务必将零碎用户始终牢记在心，防止对系统用户造成负面影响。咱们必须着眼于用户，努力提高零碎弹性并改善用户体验。 应用黑洞攻打验证依赖项从单体架构迁徙到微服务后，复杂性加剧的体现之一是依赖项减少。单体利用中蕴含了零碎的所有业务逻辑，而迁徙到微服务后则会变成多项服务依赖共存。您的微服务还可能依赖其余内部服务，例如来自云提供商的 API，或用作基础架构一部分的 SaaS 服务。 当这些内部或外部依赖项呈现故障时会产生什么？您在代码中施行的保护措施是否缓解这些故障？超时和重试等逻辑是否针对零碎在生产环境中的理论运行形式进行了调优？ 黑洞攻打是测试您是否解决好故障依赖项的好办法。黑洞攻打会拦挡主机或容器对特定主机名、IP 地址和/或端口的拜访，模仿资源不可用时会产生的情景。这种办法可能无效模仿网络或防火墙相干中断以及网络分区。 在存在内部依赖项的状况下，假如咱们正在运行一个应用 Twilio API 向客户发送短消息的服务。咱们晓得，咱们与 Twilio 的通信随时都有可能中断，因而咱们将微服务设计为读取队列中的音讯，并且只在这些音讯通过 Twilio API 胜利发送到 Twilio 后才将它们从队列中删除。 ...

转发申请时须要两个性能, 一个是去掉 querystring 上特定的字段, 一个是替换掉一个字段的值. 参考两篇文章失去一个可用的计划, https://itecnotes.com/server/...https://zzyongx.github.io/blo... 次要的思路是通过正则, 对 $args 重复进行替换, 失去本人想要的后果, upstream myhost { server myupstream.com:443;}# 强制 log 输入到 stdoutaccess_log /dev/stdout;error_log /dev/stderr info;server { listen 5555; location /my/api { # 目前接口都转发到该域名 set $target_host "myupstream.com"; # set $target_host REPLACED_HOST; set $target_data "REPLACED_DATA"; # set $target_data "dev"; # 正则解决的不是数据结构, 各种组合须要手动遍历 # 去掉后边的 extraKey if ( $args ~* ^(.*)&extraKey=[\w\d]+(.*)$ ) { set $args $1$2; } # 去掉结尾的 extraKey if ( $args ~* ^extraKey=[\w\d]+(.*)$ ) { set $args $2; } # 革除 myData if ( $args ~* ^(.*)&myData=\w+(.*)$ ) { set $args $1$2; } # 革除结尾的 myData if ( $args ~* ^myData=\w+(.*)$ ) { set $args $1; } # 革除后设置一个指定一个参数 set $arg_myData "$target_data"; proxy_set_header Host $target_host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # proxy_set_header X-Real-IP $remote_addr; proxy_pass_request_headers on; # HTTP 转 HTTPS 用 proxy_ssl_server_name on; set $args "$args&myData=$arg_myData"; # 调试用 # return 200 "$target_host/api$uri$is_args$args&myData=$arg_myData"; proxy_pass https://myhost/api$uri$is_args$args; }}留神 $arg_myData 尽管是从 querystring 解析进去的 field, 然而批改了只会减少, 而不是替换. 间接减少可能呈现两个 myData 的申请, 不能保障服务器解析和解决都是对的. 所以应该是先革除, 再本人加上. ...

转发申请时须要两个性能, 一个是去掉 querystring 上特定的字段, 一个是替换掉一个字段的值. 参考两篇文章失去一个可用的计划, https://itecnotes.com/server/...https://zzyongx.github.io/blo... 次要的思路是通过正则, 对 $args 重复进行替换, 失去本人想要的后果, upstream myhost { server myupstream.com:443;}# 强制 log 输入到 stdoutaccess_log /dev/stdout;error_log /dev/stderr info;server { listen 5555; location /my/api { # 目前接口都转发到该域名 set $target_host "myupstream.com"; # set $target_host REPLACED_HOST; set $target_data "REPLACED_DATA"; # set $target_data "dev"; # 正则解决的不是数据结构, 各种组合须要手动遍历 # 去掉后边的 extraKey if ( $args ~* ^(.*)&extraKey=[\w\d]+(.*)$ ) { set $args $1$2; } # 去掉结尾的 extraKey if ( $args ~* ^extraKey=[\w\d]+(.*)$ ) { set $args $2; } # 革除 myData if ( $args ~* ^(.*)&myData=\w+(.*)$ ) { set $args $1$2; } # 革除结尾的 myData if ( $args ~* ^myData=\w+(.*)$ ) { set $args $1; } # 革除后设置一个指定一个参数 set $arg_myData "$target_data"; proxy_set_header Host $target_host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # proxy_set_header X-Real-IP $remote_addr; proxy_pass_request_headers on; # HTTP 转 HTTPS 用 proxy_ssl_server_name on; set $args "$args&myData=$arg_myData"; # 调试用 # return 200 "$target_host/api$uri$is_args$args&myData=$arg_myData"; proxy_pass https://myhost/api$uri$is_args$args; }}留神 $arg_myData 尽管是从 querystring 解析进去的 field, 然而批改了只会减少, 而不是替换. 间接减少可能呈现两个 myData 的申请, 不能保障服务器解析和解决都是对的. 所以应该是先革除, 再本人加上. ...

一、nginx常用命令 cd usr/local/nginx/sbin 启动 或者./nginx nginx -s quit 优雅进行nginx，有连贯时会等连贯申请实现再杀死worker过程 nginx -s reload 优雅重启，并从新载入配置文件nginx.conf nginx -s reopen 从新关上日志文件，个别用于切割日志 nginx -v 查看版本 nginx -t 查看nginx的配置文件 nginx -h 查看帮忙信息 nginx -V 具体版本信息，包含编译参数 nginx -c filename 指定配置文件 ps -ef|grep nginx 查看过程 nginx -t -c /etc/nginx/nginx.conf 或者 nginx -t 查看对nginx.conf文件的批改是否正确二、 nginx defalut.conf跨域配置worker_processes 1; client_max_body_size 600m;events { worker_connections 1024;}http { include mime.types; default_type application/octet-stream; server { listen 9292; server_name localhost; add_header Access-Control-Allow-Credentials true; add_header Access-Control-Allow-Origin http://101.200.198.179:8106; add_header Access-Control-Allow-Methods 'POST,GET,OPTIONS,PUT,DELETE'; add_header Access-Control-Max-Age 3600; #容许脚本拜访的返回头 add_header Access-Control-Allow-Headers 'x-requested-with,content-type,Cache-Control,Pragma,Date,x-timestamp'; #容许自定义的头部，以逗号隔开,大小写不敏感 add_header Access-Control-Expose-Headers 'WWW-Authenticate,Server-Authorization'; location / { root html; # 本地文件的门路 index index.html index.htm; # 拜访index首页的文件 try_files $uri $uri/ /index.html #避免页面刷新404 #limit_rate 1280k; #限度速度 } location web1/apis { rewrite ^.+apis/?(.*)$ /$1 break; proxy_pass http://101.200.198.179:8106; } location web2/apis { rewrite ^.+apis/?(.*)$ /$1 break; proxy_pass http://101.200.198.179:8106; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }}ps:配置文件：装的nginx配置文件在/etc/nginx/conf.d/dafalut.conf可在 location / { root /root/zg; # 本地文件的门路 index index.html index.htm; # 拜访index首页的文件 } 中自定义首页面路劲https://www.zhihu.com/tardis/sogou/art/64125000 ...

Nginx装置与服务部署nginx装置a.装置编译工具及库文件 yum -y install make wget gcc-c++ libtool openssl openssl-devel zlib zlib-develb.下载PCRE mkdir -p /data/softwarecd /data/softwarewget http://downloads.sourceforge.net/project/pcre/pcre/8.35/pcre-8.35.tar.gztar zxvf pcre-8.35.tar.gzc.装置Nginx wget http://nginx.org/download/nginx-1.10.2.tar.gztar -zxvf nginx-1.10.2.tar.gzcd nginx-1.10.2./configure --prefix=/data/liang/nginx-upload-main \ --pid-path=/data/logs/nginx-upload-main/nginx.pid \ --lock-path=/data/liang/nginx-upload-main/nginx.lock \ --error-log-path=/data/logs/nginx-upload-main/error.log \ --http-log-path=/data/logs/nginx-upload-main/access.log \ --http-client-body-temp-path=/data/temps/nginx-upload-main/client_body_temp \ --http-proxy-temp-path=/data/temps/nginx-upload-main/proxy_temp \ --http-fastcgi-temp-path=/data/temps/nginx-upload-main/fastcgi_temp \ --http-uwsgi-temp-path=/data/temps/nginx-upload-main/uwsgi_temp \ --http-scgi-temp-path=/data/temps/nginx-upload-main/scgi_temp \ --with-http_stub_status_module \ --with-http_ssl_module \ --with-pcre=/data/software/pcre-8.35 \ --with-http_auth_request_modulemakemake install配置服务vim /data/liang/nginx-upload-main/conf/nginx.conf user root;worker_processes 1;error_log /data/logs/nginx-upload-main/error.log;#error_log logs/error.log notice;#error_log logs/error.log info;pid /data/logs/nginx-upload-main/nginx.pid;events { worker_connections 1024;}http{ access_log /data/logs/nginx-upload-main/access.log; underscores_in_headers on; upstream auth-server { server 127.0.0.1:8080; } upstream upload-server { hash $http_x_liang_uid; server 192.168.1.8:80; server 192.168.1.9:80; } upstream check-server { server 192.168.1.8:8080; server 192.168.1.9:8080; } server { listen 80; client_max_body_size 100m; location ~/media/file/\S+/checksum{ auth_request /auth; auth_request_set $auth_status $upstream_status; proxy_pass http://check-server; } location ~/media/file/\S+/upload { auth_request /auth; auth_request_set $auth_status $upstream_status; proxy_pass http://upload-server; } location = /auth { internal; proxy_pass http://auth-server; proxy_set_header Content-Length ""; } }

现今有越来越多的企业开始驳回云原生理念进行利用架构转型。而 K8s 和微服务是云原生的两大支柱，随着云原生浪潮而被广泛应用。 对少数利用而言，提供对外服务的使命并不会扭转，相比于原来的单体利用，微服务架构下的利用的服务进口更多，治理更繁琐，微服务网关也应运而生；而 K8s 也提供了多种形式来裸露利用的服务，各种 Ingress 实现百花齐放。面对泛滥技术计划，咱们如何做出正当的抉择，躲避潜在危险，本文将给出一些选型倡议，供大家参考。 云原生网关根本概述K8s 中服务对外拜访的形式对于部署在云服务器上的利用，通常应用负载平衡软件或服务（如 SLB）来提供高可用的服务。K8s 提供了基于 Service 的服务发现机制，用户通过将一批雷同个性的 Pod 绑定到一个 Service，能够提供稳固的 VIP（虚构IP）或域名供集群内拜访，并由 kube-proxy 组件基于 ipvs 或 iptables 实现 Pod 拜访的负载平衡。当须要提供服务对外拜访时，须要应用 NodePort 或 LoadBalancer 类型的 Service。 默认状况下，NodePort 会为服务在每个 K8s 集群的节点上调配一个节点端口，应用节点的 IP 地址和指定的节点端口能够从集群内部拜访到服务后端的 Pod。用 NodePort 的形式裸露服务时，因为客户端配置的是节点的 IP 地址和端口，即便 Service 提供了负载平衡的能力，其稳定性也会受对应节点的影响。在客户端拜访服务时，设置多个 K8s 集群节点的 IP 和服务 nodePort 端口，并配置适合的负载平衡和重试策略，才可能防止单点故障。 K8s 同时提供了 LoadBalancer 的 Service，客户端应用 LoadBalancer 的服务端点，能够无效躲避掉节点单点故障危险。LoadBalancer 类型 Service 基于 NodePort 实现，云厂商 CCM 组件将依据 Service 创立负载平衡监听端口，并将 K8s 集群中各节点和 nodePort 端口增加到负载均衡器后端，由云上负载均衡器实现服务负载平衡能力。 ...

前言最近看到了几个事件，一个是某保险零碎，为了疾速上线，全量上云，后果生产正式运行后每月账单高达几十万。相干业务总扛不住这个收入，又劳师动众，让上面的项目经理、开发、运维、架构师花了3个月把业务全量从私有云迁徙下来。相干人员被折磨的半死不活，而且大大拖慢了零碎的迭代速度。 另一个是某个电商的案例，上云后刚开始费用账单也是很高，每月靠近 20 万，通过「降本增效」优化后，费用大幅度降低，每月费用降到了 4 万左右，服务质量反而还有晋升。 这 2 个故事通知咱们，云时代的滚滚浪潮扑面而来，咱们也应该依据私有云的个性（如：弹性、灵便、多种计费形式等），在不升高服务质量的状况下，最大限度地优化老本。 以下是一些最佳实际。 最佳实际整体首选私有云服务而非自建私有云除了提供 IaaS（计算、存储、网络等）外，也会提供 PaaS（微服务、中间件、数据库、大数据、开发套件等）和 SaaS 服务。 在私有云提供的服务（如 MySQL 数据库）能够满足需要的前提下，倡议首选私有云上的 MySQL 数据库服务，而非自建。 理由简略阐明如下： 比照项老本性能伸缩性保护方可靠性监控易用性自建高低弱我方低无难云上服务中高高云提供商高有易用老本： 自建，须要人员保护和优化的老本，须要自行思考高牢靠（可能须要购买多台服务器）和高性能（可能须要购买高性能存储），使得老本偏高。云上服务，通过规模效应、资源池化、参数调优等实现老本绝对不高。性能： 自建，不肯定晓得所有的参数优化项，也不肯定同价位能买到专用的高性能硬件。云上服务，性能明码标价，按需抉择适宜本人的性能配置。伸缩性 自建，伸缩较麻烦，要不手动，要不通过 历经测验的 DevOps 脚本，伸缩性弱。云上服务，很多PaaS类服务能够一键升配。保护方 自建，我方自行兜底云上服务，云提供商提供 SLA 兜底。可靠性 自建，不肯定能实现该组件的集群模式或高可用模式的全副最佳实际。云上服务，会做好网络高可用（甚至是跨AZ的高可用）、存储多正本、计算跨物理服务器/机架/AZ甚至region、服务监控及自愈、备份等多种措施保障可靠性。监控： 自建，要不没监控，要不监控须要从头（采集端）到尾（告警告诉）实现一遍云上服务，监控具备，且和私有云监控无缝对接。易用性： 自建：个别没有 Web 界面，须要通过线下或流程平台或 CLI 来申请和操作云上服务：有易用的 web 界面，能够在 web 界面上实现大部分性能。比方云数据库： 运维架构： 存储的数据规模及前期扩大，采纳的高可用架构；异样切换硬件及根底环境部署 抉择什么配置的服务器，服务器型号及对应磁盘阵列；操作系统环境及内核设置；数据库装置及优化 数据库版本装置部署及配置；数据库配置参数调优；SQL 语句优化； 慢查问，对 SQL 语句及索引做优化数据库日常备份及复原。 备份；热备还是冷备？物理备份还是逻辑备份？备份策略、周期、频率应用云数据库，这些步骤云数据库都帮你做了。其余 PaaS（中间件、大数据、微服务、DevOps等）也相似。 做好平安防护私有云最大的危险就是数据泄露。所以肯定要做好平安防护。这个平安防护是多方面的。具体见 平安 局部。 云的劣势是「分布式」如果比照单台服务器，可能云主机的性能差一些。「分布式」是云计算的最大劣势。在实践中，不要只谋求单台机器的性能，而是要通过分布式的设计思维来保障业务的高性能。最佳实际举荐，服务器标配 4C8G，低配也能够采纳 2C4G 的配置。通过分布式充沛压迫了单台服务器的资源，从而最大限度地保障了最终的低成本。所以，在云上，个别状况下应用服务器的抉择条件是：更多的低配的云服务胜于更少的高配的云服务器。所以，在云上，对于数据库来说，如果数据量十分大，也举荐应用「分布式数据库」，而非在云上自建 Oracle。 云的劣势是「弹性」所以，在云上，不要依照业务峰值购买全量的资源，而是举荐： 买满足日常需要的资源顶峰时，再提前购买一些弹性的资源，弹性扩容。另外，不仅仅是服务器资源，对于网络也实用，如果您的零碎常常搞流动，网络负载差距很大，那么举荐：「大带宽按量付费」而不是「固定带宽固定计费」。 动静拆散动态：放 CDN + 对象存储上，或者放 NGINX 服务器上也好，不要间接用应用服务器（如tomcat或nodejs）来解决动态资源。（节约，术业有专攻）动静：典型架构是 LB - NGINX - 应用服务器 - redis - 数据库。 ...

前文链接高可用系列文章之一 - 概述 - 东风微鸣技术博客 (ewhisper.cn)高可用系列文章之二 - 传统分层架构技术计划 - 东风微鸣技术博客 (ewhisper.cn)四 NGINX 高可用实施方案高可用的施行, 次要步骤概述如下: NGINX 的装置及根底配置负载平衡层高可用: NGINX + Keepalived配置应用服务层高可用: NGINX -> 应用服务层 转发配置零碎软 硬件具体配置清单 依据制造业高可用架构设计, 以及业务需要, 部署模型倡议配置如下: 负载平衡服务器(即 NGINX + Keepalived): 2台, 操作系统 Linux. 配置倡议如下:名称规格备注CPU2 core 内存4 GB 硬盘50 GB 操作系统SUSE12 64位及补丁 网卡至多1块网卡, 反对VRRP 技术 软件运行配置环境:软件规格 NGINX1.16.1 Keepalived2.0.10 4.1 NGINX 装置及配置4.1.1 分区及目录倡议至多分为以下3个区: 分区及目录大小备注主分区( /)默认nginx程序及配置文件位于该分区(/etc/nginx)日志分区(/var/log/nginx)10G-20G 程序目录分区(/usr/share/nginx/html)10G可选, nginx用作web server时须要用到此目录.4.1.2 程序及依赖版本程序组件安装包名版本md5nginxnginx-1.16.1-1.sles12.ngx.x86_64.rpm1.16.1396A359F26DD0100CD59545BAFFAFE854.1.3 NGINX程序标准nginx程序目录： /etc/nginx执行程序门路： /usr/sbin/nginx主配置文件门路：/etc/nginx/conf/nginx.conf各个利用零碎转发配置文件目录：/etc/nginx/conf.d/日志目录：/var/log/nginx各个利用零碎动态文件目录：/usr/share/nginx/html4.1.4 零碎级别配置优化 留神: 须要 root 用户执行. ...

前文链接高可用系列文章之一 - 概述 - 东风微鸣技术博客 (ewhisper.cn) 三 技术计划3.1 概述单点是零碎高可用最大的危险和敌人，应该尽量在零碎设计的过程中防止单点。 保障系统的高可用, 方法论上，高可用保障的准则是「集群化」(或 「冗余」), 只有一个单点，该单点宕机所有服务都会受影响而不可用；如果有冗余或备份，其中一个点宕机还有其余冗余或备份节点可能提供服务。 保证系统高可用，架构设计的外围准则是：冗余。 有了冗余之后，还不够，每次呈现故障须要人工染指复原势必会减少零碎的 MTTR。所以，又往往是通过「主动故障转移」来实现零碎的高可用。 在上面的技术计划中，具体介绍了如何通过冗余+主动故障转移来保证系统的高可用个性。 3.2 制造业零碎的典型架构制造业零碎个别采纳分层架构, 最简略的典型架构的展现如下: 备注: 数据库以 MySQL 为例. 常见的零碎架构如上, 分为: 客户端层: 典型调用形式浏览器(browser) 和客户端(client)应用服务层: 实现外围应用逻辑, 通常是 HTTP 协定或 TCP 协定. 这一层细分, 往往还包含: 表示层: 次要是 web 浏览页面;业务逻辑层: 对具体问题进行逻辑判断和执行操作, 同时也是表示层和数据层的桥梁可选: 服务层: 如果实现了服务化, 如 SOA 或微服务化, 就会有这一层;数据拜访层: 实现对数据的增删改查等操作, 并将后果反馈到业务逻辑层可选: 数据缓存层: 缓存减速拜访存储数据库层: 数据库固话数据存储.整个零碎的高可用, 是通过对每一层的冗余+主动故障转移来综合实现的. 备注: 通过更加细化和粗疏的分层, 也能够进步可用性. 如将以上架构细化为: 客户端层;可选新增: 反向代理层可选新增: 表示层(Web Server)层应用服务层(App Server)层可选新增: 服务调用层可选新增: 缓存层数据库层本文暂不波及这一内容. ...

一 概述可用性是零碎运行品质的重要指标. 随着数字化和智能化的过程, 零碎的可用性愈发重要。例如，制造业流水线须要高可用性的 MES 零碎来保障流水线的失常运行。 本文为高可用相干的技术文档, 从以下几个方面对高可用在制造业的利用和施行进行详细描述。 1.1 可用性(Availability)定义GB/T3187-97 对可用性的定义： 在要求的内部资源失去保障的前提下，产品在规定的条件下和规定的时刻或工夫区间内处于可执行规定性能状态的能力。它是产品可靠性、维修性和培修保障性的综合反映。 可用性计算公式: Availability = MTBF / (MTBF + MTTR) 对于 Availability 这个计算公式, 通常大家习惯用 N 个 9 来表征零碎可用性，如 99.9%（3-nines availability），99.999%（5-nines availability）。 一句话概括: 可用性 ─ 每次拜访都能收到非错响应宕机工夫(DownTime): 定义: 机器呈现故障的停机工夫。这里之所以会提 Downtime，是因为应用每年的宕机工夫来掂量零碎可用性，更合乎直觉，更容易了解. 可用性(Availability)和宕机工夫(Downtime)的对应关系: 可用性宕机工夫90%36.5 天/年99%3.65 天/年99.9%8.76 小时/年99.99%52 分钟/年99.999%5 分钟/年99.9999%31 秒/年1.2 高可用(High Availablility)定义高可用性定义: 高可用性(HA)是零碎的一个个性，它的指标是确保一个约定的运行性能程度(通常是失常运行工夫)高于失常工夫。 如果用户不能拜访零碎，从用户的角度来看，零碎是不可用的。通常，停机工夫指的是零碎不可用的工夫。 1.3 高可用性实现形式有两种反对高可用性的模式: 故障转移（fail-over）和冗余（redundant）。在通常的高可用计划中, 这2种是联合起来应用. 故障转移: 定义: 在计算和网络等相干技术中，故障转移是指在先前流动的应用程序、服务器、零碎、硬件组件或网络产生故障或异样终止时，切换到冗余或备用计算机服务器、零碎、硬件组件或网络。 故障转移又具备多种实现形式, 其中罕用的一种为: 主用到备用切换（Active-passive）对于主用到备用的故障切换流程是，主用服务器发送周期信号给待机中的备用服务器。如果周期信号中断，备用服务器切换成工作服务器的 IP 地址并复原服务。 宕机工夫取决于备用服务器处于「热」待机状态还是须要从「冷」待机状态进行启动。只有主用服务器解决流量。 主用到备用的故障切换也被称为主从切换。 知识点: ...

最近一段时间，我在做一件乏味的事件，让一个 Nginx C module 通过 Go 代码来拜访 gRPC 服务。不得不感叹 Go 真的很风行，让人无奈回绝。之前我做 wasm-nginx-module 时就试图把 tinygo 跑在 Nginx 外面，这次则是把正宗的 Go 跑在 Nginx 外面。这就是无奈回避的命运吗？！ 作为一个想要挑战 C 语言历史位置的后起之秀，Go 提供了和 C 的紧密结合的性能，不便用户更好地过渡到新世界当中。这个性能有个奢侈的名字，就是 CGO。当然，因为 Go 本人的野望，它并不甘心于复用 C 的那一套，后果就是 CGO 的调用性能不如人意。当然本文不是关乎调用性能和细节的，而是讲讲 Nginx C module 整合 Go 时遇到的一些挑战。 一开始，我打算通过动态链接把 Go 代码间接编译到 Nginx 外面，这样就不须要额定再打包代码了。编译是胜利了，然而在开发过程中，我发现对应的 Go 代码并没有执行。通过 dlv 查看发现，goroutine 是创立进去了，却没有被调度到。花了些工夫查找材料，我这才发现因为 Go 是多线程利用，而在 fork 之后，子过程并不会继承父过程的所有线程，后果到了子过程那里就没有线程能够调度 goroutine 了。对于个别的 C 我的项目可能不是大问题，但不巧的是 Nginx 是 master-worker 架构的。如果走动态链接的形式， master 上的 Go 线程将无奈复制到 worker 上。为了解决这个问题，我把 Go 代码编译成动态链接库，再在 worker 过程上实现加载。 ...

业务场景有两个零碎A、B，A、B两零碎均有独立域名，但对外只想裸露A域名。须要实现通过 A域名+B零碎子路由 拜访 零碎B的子页面，图示如下。 浏览器拜访一个页面，须要1、动态资源文件，须要2、发送申请获取服务端数据，那么如果须要实现在A域名下拜访B页面，A零碎至多须要别离实现1、2两局部的申请转发。即：1、将申请B零碎动态资源文件的申请，转发到B零碎前端2、将申请B零碎后端服务数据(api)转发到B零碎后端。 对系统A (www.asystem.com)，零碎B(www.bsystem.com)，想要实现达到B零碎的申请经由A零碎转发到B，首先B零碎的申请要能被A零碎所辨认。 如果有两个雷同子路由www.asystem.com/admin www.bsystem.com/admin 对应A、B两零碎的页面，那A代理B必定做不到。 所以要在子路由层面对A、B两零碎做个辨别，域名之后，子路由最前部，加个前缀(须要别离对A、B两零碎前端进行革新)。如：www.asystem.com/a/adminwww.bsystem.com/b/admin 同理，对A、B两零碎的申请，也要有所辨别，咱们别离增加前缀api/a、api/b (也是革新A、B两零碎前端；如果前端同学nginx用的好，前端nginx写rewrite配置，后端能够不改，但这事儿即便前端能够做，也不应该麻烦前端做，否则前端nginx配置会写的很冗余，可读性差，不容易保护。api的革新工作后端要配合，即后端别离改为api/a前缀、api/b前缀，改个对立前缀对后端来说不麻烦)。 革新工作实现后，下一步，通过配置A的nginx来实现1、拜访www.asystem.com/b/ 等价于拜访www.bsystem.com/b/2、/api/b结尾的申请转发到B零碎的服务端 外围的nginx配置如下图 做到下面这两点，百里之行已过六成，剩下的是解决：1、认真解决登录问题；2、实现A->B零碎的第一次跳转；3、想好未鉴权间接拜访B零碎，B零碎的行为，实现它。 下面列出的123也须要前后端配合，要干的工作须要急躁，调试起来挺麻烦的，缓缓尝试吧同学们。 完结。 同步更新到本人的语雀https://www.yuque.com/diracke...

一、基本概念负载平衡大型网站都要面对宏大的用户量，高并发，海量数据等挑战。为了晋升零碎整体的性能，尽力将网络流量均匀散发到多个服务器上，以进步零碎整体的响应速度和可用性主从配置主从复制，是用来建设一个和主数据库齐全一样的数据库环境，称为从数据库。在赋值过程中，一个服务器充当主服务器，而另外一台服务器充当从服务器。简略来说，数据库主从配置是为了解决读写拆散，从而进步数据库性能的一种优化形式。读写拆散大多数互联网业务，往往读多写少，这时候，数据库的读会首先称为数据库的瓶颈，这时，如果咱们心愿可能线性的晋升数据库的读性能，打消读写锁抵触从而晋升数据库的写性能，那么就能够应用“分组架构”（读写拆散架构）二、实现原理 如上图所示，用户拜访网站，首先由负载均衡器接管，而后依据负载平衡算法，将流量平衡的调配给代理的web服务器以均衡各个服务器的负载压力，此时用户拜访数据库时，通过读写拆散调配给不同的服务器，当有写入操作时，主服务器通过复制的形式将数据同步到从服务器，从而实现主从服务器的数据对立。 三、环境搭建理解完基本概念和实现原理后咱们开始进行试验环境搭建，咱们须要有1个负载平衡服务器，2个web应用服务器，2个数据库服务器。试验环境为树莓派4B 1、docker装置和国内镜像配置curl -sSL https://get.daocloud.io/docker | shsudo yum-config-manager \ --add-repo \ http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo2、镜像拉取拉取nginx镜像docker pull nginx:latest拉取mysql镜像docker pull mysql:latest 3、启动容器首先咱们创立平衡服务器容器，映射容器80端口到宿主机8111端口上,把容器/etc/nginx/conf.d目录挂载到宿主机/data/nginx/conf.d目录 docker run --name nginx_balance -p 8111:80 -v /data/nginx/conf.d/:/etc/nginx/conf.d/ -itd nginx再创立两个web服务器容器来承载业务,映射出8112和8113端口 docker run --name nginx_web1 -p 8112:80 -itd nginxdocker run --name nginx_web2 -p 8113:80 -itd nginx最初再创立两个mysql服务器容器 docker run -p 8114:3306 --name mysql_master -e MYSQL_ROOT_PASSWORD=123456 -itd mysqldocker run -p 8115:3306 --name mysql_salve -e MYSQL_ROOT_PASSWORD=123456 -itd mysql创立实现之后通过docker ps命令查看创立的容器列表 4、web服务器和负载平衡服务器配置批改nginx_web1 和 nginx_web2 服务器默认nginx输入页面来用来辨别负载平衡服务器拜访了哪个web服务器 批改web服务器默认页面 进入nginx_web1容器外部，批改默认页面内容 ...

server { listen 8082; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; location / { root /home/a8082/dist/; index index.html index.htm; try_files $uri $uri/ /index.html; } #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; } }

# 装置certbotyum install certbot python2-certbot-nginx -y# 主动配置, --nginx-server-root指定nginx配置文件目录certbot --nginx --nginx-server-root /usr/local/nginx/conf# 主动续约certbot renew --dry-run执行完后nginx.conf会主动加上SSL相干配置

Nginx 1.14.2 移植指南（openEuler 20.03 LTS SP1）介绍简要介绍Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，其特点是占有内存少，并发能力强，反对FastCGI、SSL、Virtual Host、URL Rewrite、gzip等性能，并且反对很多第三方的模块扩大。 开发语言：C 一句话形容：Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器 倡议的版本倡议应用版本为“Nginx 1.14.2”。 阐明： 本文档实用于Nginx 1.14.2版本，其余版本的Nginx移植步骤也可参考本文档。 环境要求硬件要求硬件要求如表1所示。表1 硬件要求 我的项目阐明服务器TaiShan 200服务器（型号2280）CPU鲲鹏920 5250处理器磁盘分区对磁盘分区无要求操作系统要求操作系统要求如表2所示。表2 操作系统要求 我的项目版本版本查看命令openEuler20.03 LTS SP1cat /etc/openEuler-releaseKernel4.19.90 uname -r配置编译环境配置Yum源阐明：如果组网环境处于外网受限状况下，服务器yum命令无奈通过外界获取依赖包时，可参考本节内容进行本地源配置。 将操作系统镜像文件openEuler-20.03-LTS-everything-aarch64-dvd.iso文件拷贝到每台服务器的“/root”目录下。镜像文件挂载。 a. 将“/root”目录下的openEuler操作系统对应iso文件挂载到“/mnt”目录下。 mount /root/openEuler-20.03-LTS-SP1-everything-aarch64-dvd.iso /mnt 阐明： 该操作单次失效，重启后生效。若须要配置开机启动主动挂载镜像（可选），可参考上面步骤。 关上fstab文件。 vi /etc/fstab编辑fstab文件，在文件开端增加如下信息： /root/openEuler-20.03-LTS-SP1-everything-aarch64-dvd.iso /mnt iso9660 loop 0 0保留并退出fstab文件。增加本地源文件。 a. 进入“/etc/yum.repos.d”目录。 cd /etc/yum.repos.d 阐明： 此时，倡议将此目录下的*.repo文件移到任意其余备份目录下。 b. 创立local.repo文件。 关上local.repo文件。 vi local.repo编辑local.repo文件，在local.repo文件中增加如下内容： [local]name=local.repobaseurl=file:///mntenabled=1gpgcheck=0阐明： 其中，baseurl中file门路为镜像挂载门路，与镜像文件挂载中的目录“/mnt” 对应。 保留并退出local.repo文件。失效本地源。 yum clean allyum makecacheyum list装置依赖包下载并装置依赖包 yum -y install gcc gcc-c++ make libtool zlib zlib-devel pcre pcre-devel pcre2-devel perl-devel perl-ExtUtils-Embed openssl openssl-devel获取源码本文应用源码编译装置，因而须要获取到Nginx。 ...

上面是Nginx服务一键脚本，应用source或者. 执行脚本即可#!/bin/bash#脚本阐明：编译装置nginx服务#留神：应用前请将nginx-1.12.0.tar.gz放入/opt目录下#敞开防火墙systemctl stop firewalldsystemctl disable firewalldsetenforce 0#装置所需开发包和编译环境、编译器yum -y install pcre-devel zlib-devel openssl-devel gcc gcc-c++ make#创立程序用户，便于精确管制拜访useradd -M -s /sbin/nologin nginx#解压安装包cd /opttar zxvf nginx-1.12.0.tar.gz -C /opt/#编译装置nginx；指定装置门路、指定用户名、组名、启用模块以反对统计状态cd /opt/nginx-1.12.0/./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module --with-file-aio --with-http_gzip_static_module --with-http_flv_module --with-http_ssl_modulemake && make install#软链接便于零碎辨认nginx操作命令ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin/#增加nginx零碎服务echo '[Unit]Description=nginxAfter=network.target[Service]Type=forkingPIDFile=/usr/local/nginx/logs/nginx.pidExecStart=/usr/local/nginx/sbin/nginxExecrReload=/bin/kill -s HUP $MAINPIDExecrStop=/bin/kill -s QUIT $MAINPIDPrivateTmp=true[Install]WantedBy=multi-user.target' > /lib/systemd/system/nginx.service#赋权及开启服务、开启开机自启chmod 754 /lib/systemd/system/nginx.servicesystemctl restart nginx.servicesystemctl enable nginx.service参考 web服务之Nginx网站服务

简介高性能的 HTTP 和反向代理服务器软件架构由内核 和 一系列模块组成 内核 提供 web 服务的基本功能如启用网络协议、创立运行环境、接管和调配客户端申请、解决模块之间的交互模块 从构造上分为外围模块、根底模块和第三方模块外围模块： HTTP 模块、EVENT 模块和 MAIL 模块根底模块： HTTP Access 模块、HTTP FastCGI 模块、HTTP Proxy 模块和 HTTP Rewrite 模块第三方模块： HTTP Upstream Request Hash 模块、Notice 模块和 HTTP Access Key 模块及用户本人开发的模块装置# 以centos为例sudo yum install -y nginx # 启动sudo systemctl start nginx# 查看配置文件 默认是/etc/nginx/nginx.confsudo nginx -t守护过程nginx 启动后 运行 守护过程守护过程 由 一个 master 过程 和 若干个 worker过程 组成(这里worker过程的数量由配置文件中字段worker_processes映射的值决定)master过程的工作: 读取并验证配置信息创立、绑定及敞开套接字；启动、终止 worker 过程及保护 worker 过程的个数；毋庸停止服务而重新配置工作；管制非中断式程序降级，启用新的二进制程序并在须要时回滚至老版本；从新关上日志文件；编译嵌入式 Perl 脚本worker过程次要实现如下工作：接管、传入并解决来自客户端的连贯提供反向代理及过滤性能nginx 任何能实现的其它工作优化次要通过设置/etc/nginx/nginx.conf来实现 顶层配置 ...

nginx rewrite语法 rewrite regex replacement [flag];regex: 是 PCRE 语法格局的正则表达式,用于匹配字符串。replacement: 是重写 URI 的改写规定。当改写规定以"http://""https://"或"$scheme"结尾时，Nginx 重写该语句后将进行执行后续工作，并将改写后的 URI 跳转返回客户端。flag: 是执行该条重写指令后的操作控制符。操作控制符有如下 4 种： break: 执行完以后重写规定跳转到新的 URI 后不再执行后续操作。不影响用户浏览器 URI 显示。last: 执行完以后重写规定跳转到新的 URI 后继续执行后续操作。redirect: 返回响应状态码 302 的长期重定向，返回内容是重定向 URI 的内容，但浏览器网址仍为申请时的 URI；返回响应状态码 301 的永恒重定向，返回内容是重定向 URI 的内容，浏览器网址变为重定向的 URI。上面一个例子将本地63561代理到nginx代理80端口上，并且所有URL上增加/prefix前缀。 location /prefix/ { rewrite ^/prefix/(.*)$ /$1 break; proxy_pass http://localhost:63561; }原来URL http://localhost:63561/aaa => localhost/prefix/aaa尽管在nginx增加了如下配置，可不肯定失效哦，这里就要讲下nginx URI 匹配规定 URI 匹配规定location Modifier pattern { ... }Modifier为location的修饰语，定义URI的匹配规定。pattern 为匹配项，能够是字符串或正则表达式 没有修饰符: 从指定模式开始，只反对字符串 location /abc{ root text; }上面规定都匹配:http://localhost/abc/sdssdhttp://localhost/abc?page=1&s...http://localhost/abcdhttp://localhost/abc/ =: 齐全匹配 URI 中除拜访参数以外的内容，Linux 零碎下会辨别大小写，Windows 零碎下则不会。 ...

原文作者：NGINX 中文社区官网团队 of F5 原文链接：NGINX Sprint 年度线上会议：报名通道已开启，立刻预约您的 NGINX 深潜之旅 转载起源：NGINX 官方网站带上您的潜水服、调节器、潜水电脑表和水下摄像机，追随咱们在 NGINX Sprint China 2022 年度线上会议期间，一起深潜到 NGINX 的斑斓世界吧！ 12 月 1 日，在一年一度的NGINX Sprint China 2022 线上大会中理解最热的行业趋势以及 NGINX 的最新动静，并摸索 NGINX 及其周边生态的应用案例、技术解析和运维实际，您还将有机会与 NGINX 官网团队、行业大咖以及社区中的开发者和技术爱好者独特探讨交换。 对于 NGINX Sprint China 2022NGINX Sprint China 2022 是一年一度 NGINX Sprint 寰球线上大会的本地分支版本，也是 F5 NGINX 中国区全年最隆重的旗舰会议。在去年的 Sprint 大会中，咱们曾一起遨游太空，而往年正如您所见——咱们将一起深潜到海底。 此次会议将于 2022 年 12 月 1 日（周四）在线举办。在为期一天密集的会议议程中，咱们将与您分享最热门的行业趋势以及 NGINX 的最新动静，并且探讨与 NGINX 以及更多热门开源我的项目相干的行业案例和最佳实际。 在此次深潜之旅期间，多位社区大咖和资深用户将与您分享他们的教训和见解，与您一起摸索 NGINX 的有限可能。同时 NGINX 官网团队也将借此机会与社区进行深刻交换，期待听到您的声音和反馈。 为何要退出此次 NGINX 深潜之旅？海底世界并非惊涛骇浪，危险往往暗藏在不经意之间。即便是最优良的潜水员，在观赏斑斓的海底世界的同时都须要时刻打起精神，随时筹备迎接挑战。 ...

Mac下装置nginx装置工具: homebrew装置步骤:brew update // 更新brew装置命令: brew install nginx装置完查看装置信息 brew info nginx 其中/opt/homebrew/etc/nginx/nginx.conf 是配置文件 通过 which nginx能够查看nginx理论装置地位 nginx // 启动nginx浏览器拜访 localhost:8080 能显示如下页面即为启动胜利 常用命令:nginx // 启动命令nginx -s stop // 疾速进行命令nginx -s quit // 安稳退出命令nginx -s reload // 从新加载配置文件命令nginx -t // 查看配置文件正确性ps -ef | grep nginx // 查问nginx主过程号kill -QUIT 主过程号 // 失常进行kill -TERM 主过程号 或 kill -INT 主过程号 // 疾速进行kill -9 主过程号 // 强制进行

下载Nginx 源码下载：http://nginx.org/en/download.html ，抉择 Stable version 稳定版即可 下载编译工具 Zlib ：http://zlib.net/ 下载编译工具 PCRE：http://www.pcre.org/ 本文撰写时最新版本别离为：nginx-1.23.2、zlib-1.2.13、pcre2-10.40 若版本不同，留神下文波及版本的命令 装置解压下载的三个压缩包： $ tar zxvf zlib-1.2.13$ tar zxvf pcre2-10.40$ tar zxvf nginx-1.23.2编译装置： $ cd nginx-1.23.2$ ./configure --prefix=/usr/local/nginx --with-pcre=../pcre2-10.40 --with-zlib=../zlib-1.2.13$ make$ sudo make install局部罕用装置指令阐明： --prefix=path nginx装置目录，默认为 /usr/local/nginx --with-pcre=path 指定PCRE库的资源门路 --with-zlib=path 指定zlib库的资源门路，ngx_http_gzip_module 须要该模块 应用配置文件默认地址为： /usr/local/nginx/conf/nginx.conf $ cd /usr/local/nginx/sbin$ ./nginx -vnginx version: nginx/1.23.2 # 示意装置实现为方便使用，可软链接 nginx 命令到全局： $ sudo ln -s /usr/local/nginx/sbin/nginx /usr/local/bin/nginx常用命令： # 启动$ sudo nginx# 重启$ sudo nginx -s reload# 敞开$ sudo nginx -s stop参考： Building nginx from Sources ...

原文作者：Liam Crilly of F5 原文链接：将 NGINX 部署为 API 网关，第 3 局部：公布 gRPC 服务 转载起源：NGINX 官方网站 本文是“将 NGINX 开源版和 NGINX Plus 部署为 API 网关”系列博文的第三篇。 第 1 局部具体阐明了 NGINX 开源版和 NGINX Plus 作为基于 HTTP 的 RESTful API 的 API 网关的一些用例。第 2 局部对这些用例进行了扩大，探讨了一系列可用于爱护生产环境中后端 API 服务的安全措施。本文解释了如何将 NGINX 开源版和 NGINX Plus 部署为 gRPC 服务的 API 网关。文章最后公布于 2018 年，随着 NGINX Plus Release 23中引入了对原生 gRPC 健康检查协定的反对，特此更新，以不便大家充分利用 NGINX 开源版和 NGINX Plus。更新详情请参阅下文“施行健康检查”一节。注：除非另有阐明，否则本文中的所有信息都实用于 NGINX Plus 和 NGINX 开源版。为了便于浏览，当探讨内容同时实用于两个版本时，下文将它们统称为“NGINX”。 近年来，介绍微服务利用架构的概念和劣势的文章十分多，其中以NGINX 博文居首。微服务利用的外围是 HTTP API，本系列博文的前两篇文章应用了一个假如的 REST API 来阐明 NGINX 如何解决此类利用。 ...

原文作者：NGINX 原文链接：立刻降级 NGINX 以应答破绽危险 转载起源：NGINX 开源社区 今日，咱们公布了针对 NGINX Plus、NGINX 开源版、NGINX 企阅版以及 NGINX Ingress Controller 的更新，以应答最近在 NGINX 模块 ngx\_http\_mp4\_module 及 ngx\_http\_hls\_module 中发现的破绽—— 这两个模块用于以 MP4 以及 Apple HTTP Live Streaming (HLS) 格局进行视频流媒体解决。 根本信息已发现的破绽均曾经上报到通用破绽披露（CVE），F5 的平安应急小组（SIRT）也已依据通用破绽评分零碎（CVSS v3.1）对这些破绽进行评分。 下列在 MP4 流媒体模块（ngx\_http\_mp4_module）中的破绽影响到 NGINX Plus、NGINX 开源版以及 NGINX 企阅版。 CVE-2022-41741 (Memory Corruption) – CVSS score 7.1 (High)CVE-2022-41742 (Memory Disclosure) – CVSS score 7.0 (High)下列在 HLS 流媒体模块（ngx\_http\_hls_module）中的破绽只对 NGINX Plus 产生影响。 CVE-2022-41743 (Memory Corruption) – CVSS score 7.0 (High)针对以上破绽的相干补丁蕴含在以下软件版本中： ...

原文作者：Liam Crilly of F5 原文链接：将 NGINX 部署为 API 网关，第 2 局部：爱护后端服务 转载起源：NGINX 官方网站 本文是将 NGINX 开源版和 NGINX Plus 部署为 API 网关系列博文的第二篇。 第 1 局部提供了几个用例的具体配置阐明。本文对这些用例进行了扩大，探讨了一系列可用于爱护生产环境中后端 API 服务的安全措施： 限流限定申请办法利用细粒度的访问控制管制申请大小验证申请注释本文最后公布于 2018 年，现进行了更新，以反映 API 配置的以后最佳实际——即应用嵌套的location块路由申请，而不是重写规定。 第 3 局部解释了如何将 NGINX 开源版和 NGINX Plus 部署为 gRPC 服务的 API 网关。注：除非另有阐明，否则本文中的所有信息都实用于 NGINX 开源版和 NGINX Plus。为了便于浏览，下文将 NGINX 开源版和 NGINX Plus 统称为“NGINX”。 限流与基于浏览器的客户端不同，单个 API 客户端就可能给您的 API 造成微小的负载，甚至会耗费大量的系统资源，以至其余 API 客户端因而被“排斥”。不仅歹意客户端会形成这种威逼，行为异样或存在缺点的 API 客户端也可能会重复压垮后端。为了防止出现这种状况，咱们用限流来确保每个客户端正当应用 API 并爱护后端服务的资源。 NGINX 能够依据申请的任何属性利用限流。通常应用客户端 IP 地址，但如果为 API 启用身份验证，则通过身份验证的客户端 ID 将是更为牢靠和精确的属性。 ...

有任何问题都能够留言征询。 罕用的几种负载平衡办法1、round-robin轮询办法。默认的负载平衡办法。 顾名思义就是循环的一个个来。 把应用程序的申请，循环的散发到不同的服务器。 2、least-connected这个办法指的是，把下一个申请散发到流动连接数起码的服务器。 3、ip-hash把特定的客户端申请，都固定散发到特定的服务器中。 nginx会依据客户端的IP地址，把来自该IP地址的申请，都对立散发到固定的服务器中。 4、weighted加权。 比方当应用轮询办法的时候，有一台高可用的服务器，那能够通过该参数来把更多的申请散发到这台服务器中。 文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对。 示例解说1、round-robin此时，当拜访http://xxx.com:8080的时候，就会看到页面，循环的显示8091、8092和8093文案。 详情 请查看：毛毛虫的小小蜡笔

配置示例， 能够配置在http、server、location内 # 启用动态压缩， 能够提前将文件压缩好， 放在同目录下，如index.html.gzgzip_static on;# 启用gzip压缩gzip on;gzip_buffers 32 4K;gzip_comp_level 6;gzip_min_length 2K;gzip_types text/plain application/x-javascript text/css application/xml text/javascript application/javascript application/json;# 对代理文件进行压缩, nginx个别是作为反向代理, 这个就是通知nginx对它反代的服务器文件进行压缩gzip_proxied any;

原文作者：Amir Rawdat of F5 原文链接：更新：为NGINX配置收费的Let's Encrypt SSL/TLS 证书 转载起源：NGINX 官方网站 家喻户晓，网站的 SSL/TLS 加密会为您的用户带来更靠前的搜寻排名和更杰出的安全性。但目前有许多阻碍妨碍了网站所有者采纳 SSL。 其中两个最大阻碍是证书获取老本昂扬和所涉人工流程繁琐。而当初，有了 Let's Encrypt，这些都不再是问题。Let's Encrypt 反对所有人收费应用 SSL/TLS 加密。 Let's Encrypt 是一家收费、凋谢、自动化的证书颁发机构 (CA)。是的，没错Let's Encrypt颁发的 SSL/TLS 证书是收费的。现今的大多数浏览器都信赖 Let's Encrypt 颁发的证书，包含旧版浏览器，例如 Windows XP SP3 上的 Internet Explorer。此外，Let's Encrypt 实现了证书颁发和更新的全自动化。 NGINX 对于成为 Let’s Encrypt 的赞助者之一感到十分自豪。 本文介绍了如何应用 Let's Encrypt 客户端生成证书，以及如何主动配置 NGINX 开源版和 NGINX Plus 以应用这些证书。 Let's Encrypt 的工作原理在颁发证书之前，Let's Encrypt 会验证域名的所有权。在您的主机上运行的 Let's Encrypt 客户端将创立一个临时文件（一个令牌），其中蕴含所需的信息。而后，Let's Encrypt 验证服务器会收回 HTTP 申请以检索文件并验证令牌，从而验证您域名的 DNS 记录是否解析到运行 Let's Encrypt 客户端的服务器。 ...

有任何问题都能够留言征询。 概述nginx会依据虚拟主机，也就是server_name的值来解决申请。虚拟主机对应的是申请头的host字段的值。 也就是nginx会依据申请的端口，首先匹配listen中的值。 而后再依据申请中的host字段，匹配server_name中的值。 分几种状况详解下1、只配置了一个server，该server中只有一个server_name，且值为域名那只有该域名的拜访能力胜利。其余域名或者IP拜访，都不会胜利。 比方上面的配置： server { listen 80; server_name test.com; return 200 "xxx";}此时，只有test.com拜访能力胜利，其余拜访都不行。 详情 请查看：毛毛虫的小小蜡笔

本篇介绍如何在Nginx服务器中装置锐安信ssl证书，使Nginx服务器反对HTTPS平安拜访。 一、获取证书1、锐成提供的证书文件（.zip）压缩包中当中蕴含四种证书格局如：Tomcat、Nginx、IIS、Apache；Nginx服务器上须要用到Nginx文件夹内的证书。2、关上Nginx文件夹能够看到3 个文件。包含公钥，私钥和RSA格局的私钥。 二、装置证书1、 筹备好证书文件 XXX.crt 和私钥文件 XXX.key。（个别Nginx服务器应用一般的私钥即可）2、将证书文件和 KEY 文件都上传到服务器（举荐放到 /etc/nginx/cert目录）3、批改 nginx 配置文件nginx.conf如下(默认配置文件个别是在/etc/nginx/目录下)：# 以下属性中以 ssl 结尾的属性代表与证书配置无关，其余属性请依据本人的须要进行配置。 server { listen 443 ssl; server_name racent.com; #这里换成本人的域名，多个域名用空格隔开 ssl_certificate /etc/nginx/cert/1.crt; # ssl证书文件地址 ssl_certificate_key /etc/nginx/cert/1.key; # ssl证书私钥件地址 ssl_session_timeout 5m; #缓存有效期 ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; #加密算法 ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3; #平安连贯可选的加密协议 ssl_prefer_server_ciphers on; #应用服务器端的首选算法 location / { root /usr/share/nginx/html; index index.html index.htm; }}4、保留 nginx.conf 文件后退出。 三、重启 Nginxsystemctl restart nginx 四、测试 SSL 证书在浏览器地址栏输出绑定ssl证书的域名，如racent.com，测试您的 SSL 证书是否装置胜利。如果胜利，则浏览器地址栏会显示一个平安锁标记，点击可查看证书信息。也能够看视频学习Nginx服务器装置ssl证书。学习更多服务器证书配置教程，可参考SSL证书装置指南。

有任何问题都能够留言征询。 前提nginx个别是用来起个web服务器，寄存前端动态资源。从而实现前端的轻量部署。 同时，nginx也能够通过proxy_pass，设置一个反向代理，代理后端服务。 个别用于接口申请，反向代理到后端真正的服务接口。 但location和proxy_pass的门路匹配问题，也有须要留神的中央。 文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对，谢谢。 location和proxy_pass的门路匹配问题首先，启动一个服务，端口是9091。通过配置proxy_pass来拜访。 server { listen 9091; add_header Content-Type 'text/html;charset=utf-8'; location / { return 200 '这是proxy_pass反向代理拜访的另一个服务。以后拜访门路是：==>> /'; } location /v1 { return 200 '这是proxy_pass反向代理拜访的另一个服务。以后拜访门路是：==>> /v1'; } location /v1/ { return 200 '这是proxy_pass反向代理拜访的另一个服务。以后拜访门路是：==>> /v1/'; }}详情 请查看：毛毛虫的小小蜡笔

原文作者：NGINX 中文社区官网团队 of F5原文链接：议题征集：NGINX Sprint China 2022 线上大会转载起源：NGINX 官方网站 带上您的潜水服、调节器、潜水电脑表和水下摄像机，追随咱们在 NGINX Sprint China 2022 年度线上会议期间，一起深潜到 NGINX 的斑斓世界吧！ NGINX Sprint China 2022 是一年一度 NGINX Sprint 寰球线上大会的本地分支版本，也是 F5 NGINX 中国区全年最隆重的线上旗舰会议。 本次会议预计将于 2022 年 12 月初举办，咱们将分享最热门的行业趋势以及 NGINX 的最新动静，并且探讨与 NGINX 以及更多热门开源我的项目相干的行业案例和最佳实际。NGINX 官网团队也会借此机会与社区进行深刻交换，期待听到您的声音和反馈。 咱们十分心愿有更多的 NGINX 用户参加到会议中来——您能够在 20 分钟的演讲工夫内分享任何与 NGINX 相干的内容，并与社区中的开发者和技术爱好者独特探讨交换。 议题方向包含但不限于： 应用教训及用户案例技术干货及深刻解析实际分享及运维调优行业趋势及周边生态参加到本次流动，意味着您将参加到一个观看量将过万，宣传曝光量在 10 万以上的线上会议。2022 年 10 月 30 日前提交您的议题，一旦内容入选，您还将取得 NGINX 独家定制的精美大礼一份！ 立刻点击此处提交议题。有任何问题或是倡议，请通过 [email protected] 与咱们取得联系。咱们期待着与您相约 NGINX Sprint China 2022 线上大会，一起畅游 NGINX 的斑斓世界！ 更多资源想要更及时全面地获取 NGINX 相干的技术干货、互动问答、系列课程、流动资源？请返回 NGINX 开源社区： ...

模块名称形容开启选项SSL反对HHTTPS/SSL--with-http_ssl_moduleGzip Precompression压缩动态文件--with-http_gzip_static_moduleMP4反对MP4--with-http_mp4_module

有任何问题都能够留言征询。 nginx的pid是什么pid是process id的简称，过程id的意思。 在linux下，很多程序都会启动多个过程，而过程间互相发信号的时候，就须要晓得pid，以此向特定的过程发出信号。 文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对，谢谢。 问题：nginx: [error] open() "/run/nginx.pid" failed (2: No such file or directory)个别在启动nginx后，通过stop命令进行，而后再reload，发现会报找不到nginx.pid文件的问题。 起因是这样的：nginx启动后，会在/run/目录下生成nginx.pid文件，并把nginx的过程id写进去。 详情 请查看：毛毛虫的小小蜡笔

1.kill掉主线程后，reload和restart会找不到线程。从新挂载配置会提醒端口已绑定。因而须要将其余worker线程一并kill掉。如下命令： kill $(ps aux | grep nginx | awk '{print $2}')2.之后从新挂载配置文件即可启动胜利。nginx -c /.../nginx.conf 3.留神配置文件是否正确。4.nginx会存在一个master线程和多个worker线程（依据配置或cpu外围数来）。当运行中的worker线程挂掉后，会有新的顶上去，因而须要杀掉所有的worker线程。5.留神配置文件是否正确。小心关掉之后无奈重启，影响失常服务。

原文作者：Rob Whiteley of F5原文链接：NGINX 的将来：回到开源的初心转载起源：NGINX官方网站编者按： 本文公布于 2022 年 NGINX 寰球 Sprint 线上大会期间，其中不仅回顾了 NGINX 在过来获得的成就，同时面向来年提出了三项重大承诺和三项重要公布。 NGINX Sprint China 2022 是 NGINX Sprint 寰球线上大会的本地分支版本，也是 F5 NGINX 中国区全年最隆重的线上旗舰会议。本次会议预计将于 2022 年 12 月初举办，咱们将分享最热门的行业趋势以及 NGINX 的最新动静，并且探讨与 NGINX 以及更多热门开源我的项目相干的行业案例和最佳实际。NGINX 官网团队也会借此机会与社区进行深刻交换，期待听到您的声音和反馈。 咱们十分心愿有更多的 NGINX 用户参加到会议中来，您能够在 20 分钟的演讲工夫内分享任何与 NGINX 相干的内容。欢迎您点击通过表单提交议题，咱们期待着与您相约 NGINX Sprint China 2022 线上大会！ 欢快的时光总是过得飞快，难以置信 NGINX 至今已走过 18 个年头。回顾过去，咱们与 NGINX 社区独特获得了诸多成就。最近咱们又达到了一个重要里程碑——截至本文撰写时，55.6% 的网站由 NGINX 提供反对（通过 NGINX 自有软件或基于 NGINX 构建的产品）。NGINX Web 服务器的市场份额排名第一 。咱们为此深感骄傲，并衷心感谢 NGINX 社区长期以来对咱们的高度信赖。 与此同时，咱们越发意识到开源软件将持续扭转世界，愈来愈多的利用将应用开源代码构建。从彭博终端和新闻、华盛顿邮报，再到 Slack、爱彼迎、 Instagram、 Spotify，寰球成千上万的知名品牌和企业都依附 NGINX 开源版来反对其网站。就我集体而言，我白天应用 Zoom 召开工作会议，早晨观看 Netflix ，每天大概 80% 的工夫都花在了基于 NGINX 构建的利用上。 ...

本文将解说一下内容： 1、Nginx 的过程模型剖析 2、Nginx 实现高并发原理剖析 这篇文章首先会解说一下 Nginx 的过程模型，只有先了解了 Nginx 过程模型，能力深刻了解 Nginx 实现高并发的原理。 1、Nginx 过程模型介绍Nginx 的过程模型也是采纳 Master/Worker 模式。当 Nginx 启动时，会先创立一个 Master 过程，Master 过程会 fork 出若干个 Worker 子过程（具体是多少个子过程能够在 Nginx 的配置文件中来配置） Master 过程的作用如下： Master 过程次要是接管外界信号（如重载配置等），传递给 Worker 过程 监听 Worker 过程的运行状态，负责 Worke 过程的创立和销毁 Worker 过程的作用如下： 解决 Master 过程传递过去的信号 解决网络事件，比方客户端申请 这种过程模型看似跟 PHP-FPM 的解决形式相似，它们之间的区别在哪里呢？ 答复这个问题，就要从两者的定位动手了。Nginx 是一个 HTTP 服务器，负责转发申请，不负责解决具体的业务。PHP-FPM 须要解决具体的业务，特地是有些是耗时的业务场景。在 Nginx+PHP-FPM 的架构中，Nginx 的 Worker 过程将申请转发给 PHP-FPM 后，并没有停下来期待 PHP-FPM 返回数据，而是设置了一个回调事件，而后就去解决请他申请了。当 PHP-FPM 业务逻辑解决完后，会执行 Nginx 中 Worker 过程设置的回调事件，这时 Nginx 的 Worker 过程就会停下手中的工作，开始解决回调函数的返回值，直到数据返回给用户端。 ...

有任何问题都能够留言征询。 问题明天拜访服务器的页面，发现拜访不到。 文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对，谢谢。 剖析过程端口不通想起之前是操作过nginx的降级，但降级完后服务是始终开着的。所以不太明确为啥拜访不到。 而后在本地ping和telnet，发现能ping通，但telnet不通。 那就是端口不通，端口有问题了。

前端微服务 Tips：能够将多个零碎交融成一个零碎，无技术壁垒，能够像iframe一样实现性能组合● qiankun （阿里反对）● micro-app （京东反对）● wujie （腾讯反对）自己举荐 应用微服务会导致跨域问题 Tips：跨域就是非同源网站发动申请，浏览器安全策略爱护机制导致的● 文件跨域：html页面，动态资源跨域等● 接口跨域：get，post等等申请跨域 跨域问题解决 Tips：这里以Nginx 配置为例Nginx 配置详解，例子内要害行都有正文； 跨域遵循谁被援用，配置谁的准则 listen 8088; server_name 10.72.159.133; location / { root /jur; index index.html index.htm; try_files $uri $uri/ /index.html; # 使得html文件能够在跨域拜访 add_header Access-Control-Allow-Origin *; } location /api/ { # 因为跨域申请会先发动option(预检)申请，而预检申请要通知客户端哪些货色能通过因而要害配置option申请即可 if ($request_method = 'OPTIONS') { # 使得申请从哪其余地位来能够通过 add_header 'Access-Control-Allow-Origin' $http_origin; # 使申请能够携带cookie add_header 'Access-Control-Allow-Credentials' 'true'; # 通知客户端哪些申请能够通过 add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PATCH, PUT'; # 设置申请最大值 add_header 'Access-Control-Max-Age' 1728000; add_header 'Content-Type' 'text/plain; charset=utf-8'; # add_header 'Content-Type' 'application/json;charset=UTF-8'; # 容许自定义authorization申请头通过 add_header 'Access-Control-Allow-Headers' 'authorization,Content-Type,XFILENAME,XFILECATEGORY,XFILESIZE'; # 不限度内容长度 add_header 'Content-Length' 0; # 返回通过code return 204; } # 申请转发 proxy_pass http://xx.xxx.xxx.xxx:8000/api/; proxy_redirect default; proxy_cookie_path ~*^/.* /; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header REMOTE-HOST $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 18000; proxy_send_timeout 18000; proxy_read_timeout 18000; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }如果Ngnix是通过docker启动的 Tips：docker启动Nginx 须要配置docker-componse.yml文件docker-componse.yml须要配置文件/目录/端口等映射关系，否则基于docker启动的Nginx无法访问 ...

原文作者：Elijah Zupancic of F5 和 Jason Schmidt of F5原文链接：古代利用参考架构之 OpenTelemetry 集成停顿报告转载起源：NGINX 官方网站去年秋天咱们在 Sprint 2.0 上介绍 NGINX 古代利用参考架构 (MARA) 我的项目时，就曾强调过这不是一个随随便便的架构，咱们的初衷是打造一款“稳固牢靠、通过测试且能够部署到在 Kubernetes 环境中运行的实时生产利用”的解决方案。对于这样一个我的项目来说，可观测性工具能够说是必不可少。MARA 团队的所有成员都曾亲自体验过，不足状态和性能洞察会让利用开发和交付变得如许艰难。咱们很快就达成了共识，即 MARA 必须增加能够在生产环境中进行调试和跟踪的工具。 MARA 的另一项领导准则是首选开源解决方案。本文形容了咱们对多功能开源可观测性工具的谋求是如何使咱们将眼光转向 OpenTelemetry 的，而后具体介绍了其中的利弊衡量和设计决策，以及采纳了哪些技术将 OpenTelemetry 与应用 Python、Java 和 NGINX 构建的微服务利用相集成。 咱们心愿咱们的教训能够帮忙您避开可能的陷阱，并放慢您对 OpenTelemetry 的采纳。请留神，本文是一份具备时效性的停顿报告 —— 咱们探讨的技术预计将在一年内成熟。此外，只管咱们指出了某些我的项目以后的不足之处，但咱们依然对所有曾经实现的开源工作深表感谢，并期待它们将来获得更好的停顿。 咱们的利用咱们抉择了 Bank of Sirius 作为集成可观测性解决方案的利用。Bank of Sirius 是咱们从 Google 提供的 Bank of Anthos 示例利用引出的分支，是一个具备微服务架构的 Web 利用，能够通过基础架构即代码进行部署。尽管咱们能够通过很多种形式来改良此利用的性能和可靠性，但它曾经足够成熟，能够被正当地认为是一种“棕地”利用。因而，咱们认为这是一个展现如何将 OpenTelemetry 集成到利用中的好例子，因为实践上分布式跟踪能够生成无关利用架构毛病的贵重洞察。 如图所示，反对利用的 service 绝对简略。 咱们是怎么抉择了 OpenTelemetry咱们抉择 OpenTelemetry 的路线相当波折，经验了几个阶段。 创立性能清单在评估可用的开源可观测性工具之前，咱们确定了哪些方面须要关注。依据过来的教训，咱们列出了以下清单。 日志记录 —— 顾名思义，这意味着从利用中生成经典的、以换行符分隔的音讯集；Bank of Sirius 利用会以 Bunyan 格局构建日志分布式跟踪 —— 整个利用中每个组件的Timing和元数据，例如供应商提供的利用性能治理 (APM)指标 —— 在一段时间内捕捉并以工夫序列数据的模式绘制的测量值/li>异样/谬误聚合和告诉 —— 一个聚合了最常见的异样和谬误的汇合，该汇合必须是可搜寻的，以便咱们能够确定哪些利用谬误是最常见的谬误健康检查 —— 发送给 service 的定期探针，用于确定它们是否在利用中失常运行运行时状态自检 —— 一组仅对管理员可见的 API，能够返回无关利用运行时状态的信息堆转储/外围转储 —— service运行时状态的综合快照；思考到咱们的目标，很重要的一点就是看在须要时或在 service 解体时获取这些堆转储的难易水平对照性能清单比拟工具性能当然，咱们并不指望一个开源工具或一种办法就能搞定所有性能，但至多它为咱们提供了一个比拟可用工具的现实根据。咱们查阅了每个工具的文档，确定了各个工具可反对七项性能清单中的哪些性能。下表对咱们的发现进行了总结。 ...

k8s常用命令汇合： 1、禁止|复原node节点调度： kubectl cordon(禁用)|uncordon(复原) <nodename>2、删除节点(慎用): kubectl drain <nodename> (驱除非零碎pod)kubectl delete <nodename> (删除节点)3、创立资源： kubectl create|apply -f test.yamlcreate：命令个别用于创立新资源。因而,如果再次运行该命令,则会抛出谬误,因为资源名称在名称空间中应该是惟一的。apply：命令个别用于更新资源配置。 如果资源不在那里,那么它将被创立。 kubectl apply命令能够运行更屡次,只有资源定义没变,资源将不会变动。4、查看资源列表： kubectl get node|pod|service|deployment|configmap|... -n namespace [-o wide] [-w]更多查看帮忙：kubectl get --help5、查看特定资源详情： kubectl describe pod <podname> -n namespace6、查看资源定义： kubectl get deploy <deployname> -n namespace -o yaml [>file(自定义文件名).yaml] 重定向到文件里,能够再次apply -f yaml7、编辑资源(只对spec字段下内容失效)： kubectl edit node|pod|service|deployment|configmap|... -n namespace8、删除资源(慎用)： kubectl delete pod <podname> -n namespace [--force --grace-period=0]强制删除grace-period示意过渡存活期,默认30s,在删除POD之前容许POD缓缓终止其上的容器过程,从而优雅退出,0示意立刻终止POD。9、pod扩缩容: 手动扩缩容：kubectl scale deployment <deployname> -n namespace --replicas=x；也可用kubectl edit对deployment进行编辑后apply10、pod降级与回滚： deployment：降级：kubectl set image deployment/<deplyname> -n namespce image=<imagename>:xxx; 也可用kubectl edit对deployment进行编辑后apply更新策略：Recreate: 更新时先杀掉正在运行的pod，而后创立新的podRollingUpdate： 滚动形式进行更新，参数maxUnavailable和maxSurge来管制滚动更新的过程回滚(不罕用）：kubectl rollout status|history deployment/<deployname> -n namespace [--to-revision=x]11、pod调度： ...

我租了一个服务器搭建了nginx，发现一个报错，前面我解决了，既然这样话，我就顺便把办法教给你们。 log_format compression '$remote_addr - $remote_user [$time_local] ' '"$request" $status $bytes_sent ' '"$http_referer" "$http_user_agent" "$gzip_ratio"';access_log /spool/logs/nginx-access.log compression buffer=32k;留神：compression为log_format前面的日志款式名称。这个日志对应的门路对启动nginx的用户须要有写权限nginx转发json log_format json '{"remote_addr":"$remote_addr","remote_user":"$remote_user",' '"request":"$request","status":"$status","remote_user":"$bytes_sent",' '"http_referer":"$http_referer","http_user_agent":"$http_user_agent"}';access_log /spool/logs/nginx-access.log json buffer=32k;留神：json 为log_format前面的日志款式名称。这个日志对应的门路对启动nginx的用户须要有写权限好用的变量变量名称 阐明示例 $arg_name 申请中的name参数$args 申请中的参数$body_bytes_sent 已发送的音讯体字节数$content_length HTTP申请信息里的"Content-Length"$content_type 申请信息里的"Content-Type"$host 申请信息中的"Host"，如果申请中没有Host行，则等于设置的服务器名$http_cookie cookie 信息$http_referer 援用地址$http_user_agent 客户端代理信息$http_via 最初一个拜访服务器的Ip地址。$http_x_forwarded_for 相当于网络拜访门路$is_args 如果申请行带有参数，返回“?”，否则返回空字符串$pid worker过程的PID$remote_addr 客户端IP地址$remote_port 客户端端口号$remote_user 客户端用户名，认证用request相干罕用的：变量名称 阐明示例 $request 用户申请$request_body 这个变量蕴含申请的次要信息。在应用proxy_pass或fastcgi_pass指令的location中比拟有意义$request_filename 以后申请的文件路径名，比方/opt/nginx/www/test.php$request_method 申请的办法，比方"GET"、"POST"等$request_uri 申请的URI，带参数server相干罕用的：变量名称 阐明示例 $scheme 所用的协定，比方http或者是https，罕用这个$server_addr 服务器地址，如果没有用listen指明服务器地址，应用这个变量将发动一次零碎调用以获得地址(造成资源节约)$server_name 申请达到的服务器名$server_port 申请达到的服务器端口号$server_protocol 申请的协定版本，“HTTP/1.0"或"HTTP/1.1”$uri 申请的URI，可能和最后的值有不同，比方通过重定向之类的如果须要服务器的话，能够后盾分割我

一、背景在工作当中常常会遇到，测试环境好用，本地不好用的状况，这种状况要么就是版本的问题，要么就是数据的问题然而怎么能debug调试咱们测试环境程序呢～ 二、解决方案⚠️：nginx实现的测试环境申请复制到本地，并进行debug调试间接上代码# 配置服务代理 location /thread-test/ { # 主机地址 #模仿nginx转发是测试后盾的服务 proxy_pass http://localhost:9902/thread-test/; # 流量复制 mirror /mirror; mirror_request_body on; }# 镜像站点 location /mirror{ internal; # 模仿本地的服务 proxy_pass http://localhost:9905$request_uri; proxy_pass_request_body on; proxy_set_header X-Original-URI $request_uri; }益处 既能解决debug调试的线上的测试环境，又不会阻塞线上环境的程序运行。这里只是放了一个用于测试的最原始的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 80; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; location / { root html; index index.html index.htm; }# 配置服务代理 location /thread-test/ { # 主机地址 proxy_pass http://localhost:9902/thread-test/; # 流量复制 mirror /mirror; mirror_request_body on; }# 镜像站点 location /mirror{ internal; proxy_pass http://localhost:9905$request_uri; proxy_pass_request_body on; proxy_set_header X-Original-URI $request_uri; } #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; # } #} include servers/*;}

一、后期筹备虚拟机：VMware16Linux：CentOS-7（能够先下载.torrent后缀的种子文件，再应用迅雷下载，下载速度会更快）二、装置centos7零碎1. 创立新的虚拟机菜单栏>找到文件>点击“新建虚拟机” 跟着提醒下一步就行了，始终到设置磁盘 2. 配置磁盘 3. 装置零碎编辑虚拟机设置>硬件>CD/DVD(IDE)>选中“应用ISO映像文件”>抉择你的CentOS零碎 启动虚拟机，点击“开启此虚拟机”。鼠标点击虚拟机空白处>用键盘的↑键选中“Install Cent0S 7”>按回车，进入系统配置界面； 设置日期和工夫，鼠标点击中国的地位\>City搜寻框输出“shanghai(上海)”按回车键，小红点会主动定位在上海坐标\>最初把工夫设置成24小时制 抉择零碎环境，这里虚拟机就抉择图形界面了，个别服务器是抉择默认最小装置 抉择磁盘 开启网络 设置root明码和设置用户 重启完之后先设置承受许可证，点击右下角的finish就进入下一步设置 接下来就是始终点右上角的next和skip就好了 记得最初要用root用户进入零碎，不然会有很多权限问题 4. 网卡配置终端输出ifconfig,查看网卡信息 查看网卡设施配置信息 vi /etc/sysconfig/network-scripts/ifcfg-ens*（*依据理论状况不同，这里为ens33，就是上图中箭头指向的网卡名称）默认的配置信息如下 TYPE="Ethernet"PROXY_METHOD="none"BROWSER_ONLY="no"BOOTPROTO="dhcp"DEFROUTE="yes"IPV4_FAILURE_FATAL="no"IPV6INIT="yes"IPV6_AUTOCONF="yes"IPV6_DEFROUTE="yes"IPV6_FAILURE_FATAL="no"IPV6_ADDR_GEN_MODE="stable-privacy"NAME="ens33"UUID="68c0ad50-b291-4ef9-aec0-24c5a6819005"DEVICE="ens33"ONBOOT="yes"批改网卡配置 //批改以下内容 BOOTPROTO=static  //启用动态IP地址 //增加以下内容IPADDR=192.168.19.130      //设置IP地址 这里地址和下面ifconfig图外面箭头指向的IP地址NETMASK=255.255.255.0   //子网掩码 GATEWAY=192.168.19.2   //设置网关 网关地址在点击虚拟机最上一排菜单 -> 编辑 -> 虚构网络编辑器 -> NAT设置查看DNS1=192.168.19.2 // DNS地址，和下面的网关地址统一批改结束后，按 esc 进入到 命令模式, 按住 shift + : 键, 接着再输出 wq, wq是保留并退出, q就是示意退出，最初重启网卡。 systemctl restart network然而我这重启网卡也没用，最初重启零碎了 三、装置nginx创立nginx目录mkdir nginx && cd nginx ...

将运行在一组 Pods 上的应用程序公开为网络服务的形象办法。应用 Kubernetes，你无需批改应用程序即可应用不相熟的服务发现机制。 Kubernetes 为 Pod 提供本人的 IP 地址，并为一组 Pod 提供雷同的 DNS 名， 并且能够在它们之间进行负载平衡。 Service的工作模式userspace 代理模式iptables 代理模式IPVS 代理模式多端口 Service,如以下示例：apiVersion: v1kind: Servicemetadata: name: my-servicespec: selector: app.kubernetes.io/name: MyApp ports: - name: http protocol: TCP port: 80 targetPort: 9376 - name: https protocol: TCP port: 443 targetPort: 9377内部服务Service在某些环境中，利用零碎须要将一个内部数据库作为后端服务进行连贯，或将另一个集群或Namespace中的服务作为服务的后端，这时能够通过创立一个无Label Selector的Service来实现。 apiVersion: v1kind: Servicemetadata: name: mysql-testspec: ports: - port: 3306(此时须要创立一个和该Service同名的Endpoint）。 apiVersion: v1kind: Endpointsmetadata: name: mysql-test namespace: defaultsubsets: - addresses: - ip: 120.25.128.30 ports: - port: 3306Headless Service在某些利用场景中，凋谢人员心愿本人管制负载平衡的策略，不应用Service提供的默认负载平衡的性能，或者应用程序心愿晓得属于同组的其余实例。 此种服务不为Service设置ClusterIP,仅通过Label Selector 找后端的Pod列表返回给调用的客户端。 ...

应用3A服务器搭建的centos零碎装置nginx教程在我的往期博客中1，nginx 指定配置文件 /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf 1-c 参数 指定了要加载的nginx配置文件门路1,从容进行Nginx：kill -QUIT 主过程号 2,疾速进行Nginx：kill -TERM 主过程号 3,强制进行Nginx：kill -9 主过程号 2，应用信号治理nginx 的master、worker过程立即进行服务：nginx -s stop 或者kill -SIGTERM $(cat /data/services/nginx/logs/nginx.pid) 优雅进行服务：nginx -s quit 或者kill -QUIT $(cat /data/services/nginx/logs/nginx.pid) 重载配置文件(master不退出，从新加载worker过程)：nginx -s reloadkill -SIGHUP $(cat /data/services/nginx/logs/nginx.pid) 从新开始记录日志文件：nginx -s reopen 或者kill -USR1 $(cat /data/services/nginx/logs/nginx.pid) 热降级nginx服务(次要是二进制nginx文件)：kill -USR2 old_master_process #将新的申请适度到新的master过程中去kill -WINCH old_master_process #优雅敞开所有work过程 nginx reload流程(1)向 master 过程发送 HUP 信号(reload命令)(2)master 过程校验配置文件语法是否正确(3)master 过程关上新的监听端口(4)master 过程用新配置启动新的 worker 子过程(5)master 过程向老 worker 子过程发送 QUIT 信号(6)老 worker 过程敞开监听句柄，解决完以后连贯后完结过程 ...