本文是NGINX负载平衡实验的一些注释。
转发过程已经完成，并且已经尝试了一些负载平衡算法。本文对NGINX的负载平衡进行了一些简单的测试。一些实验是要回答作者与同事交流时引起的疑问。
本文中使用的程序是作者先前实施的转发程序，实际上，任何响应POST请求的程序都可以使用。
本文中的实验环境如下：虚拟机Linux运行容器。虚拟机Windows发送发布请求。
本文使用镜像进行测试。开始命令如下：
为了配置NGINX，需要根本权限，因此使用以下命令进入容器：
后端服务操作命令如下：
重新启动nginx命令如下：
NGINX配置文件如下：
配置文件主要设置上游服务的IP和端口。然后执行特定的URL映射，如下：
以下主要修改以用于使用不同算法实现实验目的的零件。
为了执行实验，需要开始几个终端进入容器，例如修改配置和重新启动NGINX，执行程序，观察日志等等。
以下请求命令在另一个终端（在Windows或Virtual Machines中）执行：
下面给出了配置和相应的日志和观察的现象。
默认旋转配置：
日志：
结论：9001和9002按顺序出现。
加权旋转配置：
日志：
结论：9001和9002出现了4次，一次。注意：测试后，Nginx的加权旋转查询本身是平稳且加权旋转的。为了证明，在这里，权重值扩大。
平滑的加权旋转配置：
日志：
结论：从重量的角度来看，9001、9002和9003保持配置中的值，即2、5和3次，从顺序的角度来看，重型服务器尚未集中，并且这三个查询是相对均匀的。从两轮实验的结果中判断，每轮查询，服务器的顺序似乎不同。
与以前的平滑算法的自我实施相比：下面：
可以看出，两者之间仍然存在差异。
IP_HASH旋转配置：
要模拟不同的IP访问，请在虚拟机，物理计算机和其他容器中发送发布请求以观察日志。
结论：NGINX所在的容器的本地IP是另一个容器，一个物理机器，虚拟机。从日志中，每个源IP从同一端口的服务中响应。但是，以某种方式不询问9001端口服务。
这是我一直想做的一些实验。
后端服务没有启动访问-Return 502仿真场合：尚未启动所有后端服务，但是在nginx配置文件中指定了后端服务。NGINX访问日志：
卷曲请求返回：
结论：返回502，请注意，所有后端服务都会在访问日志中返回502，猜测Nginx已经进行了询问。
突然 - 在服务处理中，当服务故障模拟场合：服务突然停止处理请求中的服务（例如段错误或关闭电源）。在模拟情况下，故意延迟睡眠请求，请延迟睡眠请求，请求4秒以促进停止服务。NGINX访问日志：
可以看出，响应超过3秒，因为作者在大约3秒钟内停止了后端服务。
卷曲请求返回：
结论：对于请求者，返回信息与以前的实验相同，但是当看到访问日志时，只有9001提示502，但是还有其他的后端服务正在运行。NGINX会找到普通的工作机器。
处理中的re -configure nginx - 将等待处理完成模拟场合：在多个背部 - 端服务中，需要停止和升级该零件，然后升级其他服务。首先扩大了两者的权重服务器，例如9001至10和9002至1，以确保将大多数请求转发到端口9001。在请求处理中，修改nginx配置，删除9001服务，然后重新启动nginx.observe。
结论：NGINX等待9001服务处理请求，并且随后的请求不会转发服务。结果，请确保可以处理处理中的请求。
设置超时响应时间配置：
注意：我不知道如何实验。由于杜松子酒框架实现了它，因此有一个相应的响应功能。输入后，您认为考虑了响应，并且不可能直接使用前睡眠模式。
无法在内部的IP地址中添加URL后缀。
您可以将相应的URL添加到地址，例如。
为了促进请求日志，您需要设置nginx日志。本文的配置如下：
我可以使用NGINX屏蔽客户端对真实Web服务器的直接访问吗？在Internet上似乎没有相关的解决方案。
很久以前，当观看分布式视频，负载平衡，雪花算法，内部引入了一致性哈希算法，作者睁开了眼睛。基于请求内容的重新启动工具，以对NGINX的负载平衡算法，基本上已经过去了一次。就其他知识而言，暂时没有计划。
2021年9月下旬的第一本手稿的第一本手稿。