小组分享整理，nginx入门
nginx做了什么？
从开发一个简单的前端页面开始
<html>
<head>
<title>beauty</title>
</head>
<body>
<div id="foo">foo</div>
</body>
</html>
<!--index.html-->
上面我们写了一个美丽的index.html，记事本手撸代码，无需编译，点击运行，效果直观，前端就是这么简单！
好，我们想让用户访问到它，怎么办呢？丢到服务器上
我们买了一台阿里云，119.23.57.109，将index.html传上去
按照设想，当我们在浏览器里输入url http://119.23.57.109/index.html，浏览器返回我们编写的网页
如何做到呢？ 当然是使用web服务器啦
我们可以使用熟悉的tomcat，配置虚拟虚拟目录来实现，当然也可以使用今天的主角：nginx
nginx是什么
nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。
处理静态资源
书接上文，如何使用nginx来返回index.html呢
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
server {
listen 80;
location /page {
root /data/page;
}
lcoation /css {
alias /data/css/;
}
}
}
root和alias有什么区别呢？请看
http://119.23.57.109/page/index.html -> /data/page/page/index.html
http://119.23.57.109/css/index.css -> /data/css/index.css
- alias 后面必须要用 “/” 结束，否则会找不到文件，而 root 则对 ”/” 可有可无。
- alias 只能作用在location中，而root可以存在server、http和location中。
好，我们将配置修改一下：
server {
listen 80;
location / {
root /data/page;
}
lcoation /css {
alias /data/css/;
}
}
提前将我们敲好的index.html放到/data/page文件夹下
这样，访问 http://119.23.57.109/index.html 就可以在浏览器上看到成果了
我们又购买了一个域名：cabeza.cn，并做好dns解析
cabeza.cn -> 119.23.57.109
这样，我们就可以通过 http://cabeza.cn/index.html 访问了。
反向代理
现在，要在页面上展示服务器的CPU占用率
纯前端已经无法解决这个问题了，我们需要引入后台
我们用node撸了一个restful接口，/api/cpu-rate，监听8080端口，部署到119.23.57.109服务器上
expressApp.get('/api/cpu-rate', (req, res) => {
let r = cpuUtil.getRate();
res.json(r);
});
expressApp.listen(8080, () => {});
同时在index.html里，我们写上
<script>
ajax('http://cabeza.cn:8080/api/cpu-rate')
.then(res => $('#cpu-rate-num').text(res.data));
</script>
上面这段js有问题吗？当然有，端口不一致，会发生跨域。什么是跨域，这里不做展开了
为了避免跨域，我们的最终目的，是要可以直接通过请求 http://cabeza.cn/api/cpu-rate 就可以获得数据
那么要在nginx上做一些配置了
server {
listen 80;
location / {
root /data/page;
}
lcoation /css {
alias /data/css/;
}
location /api {
proxy_pass http://localhost:8080;
}
}
这段配置展示了nginx反向代理的能力，将访问80端口的请求，代理转发到8080端口，并返回结果
什么是反向代理？
正向代理：代理端代理的是客户端。
反向代理：代理端代理的是服务端。
正向代理隐藏真实客户端，反向代理隐藏真实服务端
负载均衡
随着我们网站的用户量越来越大，一台服务器已经不足以承载如此规模的请求，这个时候可以选择升级服务器，加内存加cpu核心
但无论如何，一台服务器的进程是有限的，我们不可能无限制的把一台服务器的CUP加到64个，把内存加到1T
因此，出现了均衡负载技术，通过将多台服务器组合成一组可以完成相同任务的服务器，当用户发出请求时，根据每台服务器的运行状态，让那些相对而言有富余的服务器来执行这个用户的请求
好，我们又买了三台服务器，分别是119.23.57.110，119.23.57.111，119.23.57.112
upstream myservers {
server 119.23.57.109:8080 weight = 2;
server 119.23.57.110:8080 weight = 3;
server 119.23.57.111:8080 down;
server 119.23.57.112:8080 backup;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
server {
listen 80;
location / {
root /data/page;
}
lcoation /css {
alias /data/css/;
}
location /api {
proxy_pass http://myservers;
}
}
}
在这一段配置中，我们定义了一个后端服务器组: myservers，并在下面的location中使用了它
其后四条server分别代表了四台服务器
upstream内置了三种负载均衡策略，分别是
-
round-robin，轮循（默认）
Nginx根据请求次数，将每个请求均匀分配到每台服务器
-
least-connected，最少连接
将请求分配给连接数最少的服务器。Nginx会统计哪些服务器的连接数最少。
-
ip-hash
绑定处理请求的服务器。第一次请求时，根据该客户端的IP算出一个HASH值，将请求分配到集群中的某一台服务器上。后面该客户端的所有请求，都将通过HASH算法，找到之前处理这台客户端请求的服务器，然后将请求交给它来处理。
在这里，我们没有指定负载均衡策略，那么它就是默认的round-robin
weight？
通过指定每台服务器的权重，我们可以进一步影响nginx的负载均衡算法 在上面的示例中，如果未配置服务器权重，这意味着所有指定的服务器都被视为具有同等资格的特定负载平衡方法。 注意，weight只能用在round-robin策略中
其余的一些配置
backup
将服务器标记为备份服务器。它将在主服务器不可用时处理请求。
down
将服务器标记为永久不可用。
白名单黑名单
页面+后台开发完毕了，因为页面中展示了一些敏感信息，所以希望只有一小部分人可以看到，而其他人无权访问，怎么做呢？
使用nginx中的ngx_http_access_module即可
location / {
allow 121.237.63.233;
allow 121.237.63.220;
deny all;
}
通过使用allow和deny这两个指令来实现
配合lua
至此，前台部署与后台对接完成，并且还实现了访问控制，事实上nginx的作用远不止于此，例如重定向、缓存等
配合上lua这门小巧的脚本语言，我们甚至可以在nginx里做一些业务处理了，诸如微信代理等。