Nginx反向代理
二级域名系统
顾名思义，我们有很多的这个不同的二级域名的用户来访问我们，比如说微博。它有一个主域名weibo.com。如果我叫一鸣,申请了一个微博，然后我就可以在微博这个主系统上申请一个二级域名来访问我微博的主页，具体实现需要在服务器上把域名的泛解析全部都解析到当前的一台nginx服务器上，nginx可以通过反向代理，把所有的请求转发到后端的另外一台业务服务器，业务服务器拿到这个域名拆解字符串，把这个二级域名取出来，再从数据库里去查询它的信息并展示相应的内容，当然这个域名在数据库里边要存储，并且它是唯一的。
短网址的实现
比如现在有短网址dwz.cn/dskn1267，当用户访问的时候，它会帮我们去跳转到一个真实的网址。短网址系统里先得有一个数据库。db会存储用户提交上来的短网址和真实地址的映射。
最简单来说，后缀可以用uuid。uuid返回作为key，真实的地址作为value。全部都存在数据库里。当用户访问到我们的系统的时候，访问到 nginx。nginx通过反向代理，把请求打到后端的应用服务器上。应用服务器获取到用户请求的完整的URL，取到之后我们拆分这串字符串，然后去数据库里去去匹配，拿到真实的地址之后，redirect用户访问的这个地址就被转向了
http DNS
http DNS一般来说不适合浏览器来使用，一般都是给手机的这个APP或者是基于CS架构的，比较适用于http dns，它可以在软件里边预埋几个IP地址，这几个IP地址就是我们的nginx服务器IP地址。在系统启动之后。APP会向这个IP去发起请求，请求某一个域名的真实的IP地址是什么。那我们的系统接到这个请求之后，参数读到域名返回这个IP地址。
Nginx隧道式模型 网关、代理与反向代理
反向代理
用户在访问我们的系统的时候，通过互联网，然后打到机房的这个网关路由上。他会把这个请求转发到具体的一台服务器上，在这个过程当中，我们的网关肯定是能把网络请求打到我们的 nginx 服务器上，它作为反向代理服务器的话，它需要把用户所有的请求全部转发到我们后端的应用服务器，相应的结果再反馈给 nginx在传递给用户，这样就叫反向代理。
正向代理
用户主动的想要去上网。透过这个代理服务器才能访问到我们的这个外网。那这个代理服务器就称之为叫正向代理服务器。比如socket 代理服务器，HTTP 代理服务器啊，
正向代理和反向代理对比起来的区别只是我们所在的角度不一样，
网关指的在我们去访问互联网的时候，假如说你拿手机连上了自己家里的路由器，那我就需要去把所有的数据包全部都发送给这个路由器。然后由路由器转发，请求给我们的这个下一跳的这个网络，那我们接触到的第一个呃路由就是我们家里这个路由器，就是我们的网关。
网关就是访问我们网络的入口
特点就是它所有的请求都得转发。都得经过网关.
应用场景
反向代理服务器在我们的系统架构当中的一些应用场景
这是传统项目当中的这个系统架构图，前面是用户，然后经过自己的网络，然后域名解析，经过互联网，然后打到机房内部的这个网关。到这个网关的时候，会中转请求在这里边呢，还会有防火墙。
那 nginx在这就起到了反向代理的作用，用户想要访问内网的任何资源，都必须得通过我这个反向代理服务器。
backend server 就是这个我们的后端的服务器，那 gateway server是网关路由服务器，在里边会有很多这种其他的业务服务器，比如说管理用户注册登录，管理这个商品。价格，管理库存，然后展示商品等等。有数据库服务器测试用的服务器文件，存储服务器，一些逻辑业务服务器，还有这个保证高可用的 ha server服务器，还有这个权限管理的服务器。这 gateway 服务器是把所有的这个业务服务器统一的管理起来，在中间起到了寻找的作用啊，
还有权限服务器,鉴权的作用并不是说所有的请求都能访问某些服务的，你需要经过这个 gateway路由服务器去做一次权限认证，也就是我们这个所有的业务逻辑是放在后端tomcat 上跑。然后这个 nginx 只做这个业务中转请求中转，所有的请求全都打到我们的后端服务器上，这是最简单的应用，也是最传统的应用技术架构，比较适合小型项目，传统项目以及这个传统的互联网项目，像传统项目的一些 ERP、 CRM 、CMS 等等，这些虽然看起来非常庞大，动不动的一个压缩包。就有一两个G大小的这种源代码，看起来非常庞大，但是它的这个并发量其实并不高，如果并发量并不是特别高的话。尤其是给一些内网用户使用的话啊，那我们这种直接代理过去就可以了。
在接触到这种中小型互联网项目的时候，nginx 作为反向代理服务器，它要起到更多的功能了，比如说我要帮我们去伪装一下当前访问的这个地址真实地址，比如想要请求这个item?serviceid=100，这请求呢 URL 打给本来是要给tomcat 的，你直接给了 nginxnginx 能把这个请求直接给我转发过去，让用户正常访问，这是没有问题的，
但是这种暴露 URL 的缺点,其实也是无关大雅的，但是有时候让人看起来好像并不是那么高级，那我们可以把它换成一种展现形式，
比如说/item/100，这 service 其实我没必要暴露给用户,不需要让他知道这是一个什么服务，
然后 ID也不需要让他去传递了，这样看起来更好记一些。
这是 URL rewrite 这个功能，可以把原本这个 URL 呢，给它变成这个/item/100，也就用户在请求这个请求这个 URL 的时候呢。通过 nginx 可以帮我们去转换成真实的 URL，然后把这真实的URL再转发给我们后端的服务器。
这样做还有另外一个好处，就是面向于一些搜索引擎，它可能会看起来你这是一个独立的页面。它权重会更高一些。
然后 nginx 在这里边不光是起到反向代理的作用，还可以起到一些额外的这些功能上，业务逻辑上的作用，比如说。转发一下这个请求，改变一下URL，那这是对于业务逻辑的这种转发，
业务的数据包不会特别大，比如说我就想要一个 json 数据。我就想是提交一下呃，我修改的密码，这份数据那几 k 大小也就够了，所以在这 nginx 比较能扛，它可能一台 nginx 后边对应了数十台这个业务逻辑服务器。
那 如果nginx 后边代理的是文件服务器，同样是业务逻辑转发，那转发到我们的 nginx 上之后， nginx 后边代理的是文件服务器，那这时候的 nginx 很明显就成了瓶颈了。
因为你后端的数据存储服务器的存储的是非常非常多的这种数据，而且数据非常大，比如说一些电影，一些软件啊非常大的这种数据包那它在传这个传递数据的时候，
nginx 就会成为网络的瓶颈。那么如果你想要用 nginx 做反向代理的话，那你就得多配一些 nginx，然后去分组去代理就可以了。
负载均衡
负载均衡就是访问到一个这个服务器，一旦它不可用的时候，它可以把故障转移到另外一台服务器。
反向代理
proxy_pass http://baidu.com;
location / {
proxy_pass http://baidu.com/;
# proxy_pass root 二选一
}
基于反向代理的负载均衡
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream httpds { # httpds 随意定义
server 192.168.1.102:80;
server 192.168.1.103:80;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://httpds;
# root vod;
# index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
负载均衡策略
轮询
默认情况下使用轮询方式，逐一转发，这种方式适用于无状态请求。
weight(权重)
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
upstream httpds {
server 127.0.0.1:8050 weight=10 down;
server 127.0.0.1:8060 weight=1;
server 127.0.0.1:8060 weight=1 backup;
}
down：表示当前的server暂时不参与负载
weight：默认为1.weight越大，负载的权重就越大。
backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。
ip_hash
根据客户端的ip地址转发同一台服务器，可以保持回话。
least_conn
最少连接访问
url_hash
根据用户访问的url定向转发请求
fair
根据后端服务器响应时间转发请求