• Babel 插件通关秘籍
  • Git 原理详解及实用指南
  • Nest 通关秘籍
  • React 通关秘籍
  • TypeScript 全面进阶指南
  • TypeScript 类型体操通关秘籍
  • 现代CSS
  • Babel 插件通关秘籍
  • Git 原理详解及实用指南
  • Nest 通关秘籍
  • React 通关秘籍
  • TypeScript 全面进阶指南
  • TypeScript 类型体操通关秘籍
  • 现代CSS
  • Nest 通关秘籍

    • 1.开篇词
    • 2.给你 5 个学习 Nest 的理由,你会心动么
    • 3.Nest 基础概念扫盲
    • 4.快速掌握 Nest CLI
    • 5.五种HTTP数据传输方式
    • 6.IoC 解决了什么痛点问题?
    • 7.如何调试 Nest 项目
    • 8.使用多种 Provider,灵活注入对象
    • 9.全局模块和生命周期
    • 10.AOP 架构有什么好处?
    • 11.一网打尽 Nest 全部装饰器
    • 12.Nest 如何自定义装饰器
    • 13.Metadata 和 Reflector
    • 14.ExecutionContext:切换不同上下文
    • 15.Module 和 Provider 的循环依赖怎么处理?
    • 16.如何创建动态模块
    • 17.Nest 和 Express 的关系,如何切到 fastify
    • 18.Nest 的 Middleware
    • 19.RxJS 和 Interceptor
    • 20.内置 Pipe 和自定义 Pipe
    • 21.如何使用 ValidationPipe 验证 post 请求参数
    • 22.如何自定义 Exception Filter
    • 23.图解串一串 Nest 核心概念
    • 24.接口如何实现多版本共存
    • 25.Express 如何使用 multer 实现文件上传
    • 26.Nest 如何使用 multer 实现文件上传
    • 27.图书管理系统:需求分析和原型图
    • 28.图书管理系统:用户模块后端开发
    • 29.图书管理系统:图书模块后端开发
    • 30.图书管理系统:用户模块前端开发
    • 31.图书管理系统:图书模块前端开发--图书搜索
    • 32.图书管理系统:图书模块前端开发--图书增删改
    • 33.图书管理系统:项目总结
    • 34.大文件分片上传
    • 35.最完美的 OSS 上传方案
    • 36.Nest 里如何打印日志?
    • 37.为什么 Node 里要用 Winston 打印日志?
    • 38.Nest 集成日志框架 Winston
    • 39.通过 Desktop 学 Docker 也太简单了
    • 40.你的第一个 Dockerfile
    • 41.Nest 项目如何编写 Dockerfile
    • 42.提升 Dockerfile 水平的 5 个技巧
    • 43.Docker 是怎么实现的?
    • 44.为什么 Node 应用要用 PM2 来跑?
    • 45.快速入门 MySQL
    • 46.SQL 查询语句的所有语法和函数
    • 47.一对一、join 查询、级联方式
    • 48.一对多、多对多关系的表设计
    • 49.子查询和 EXISTS
    • 50.SQL 综合练习
    • 51.MySQL 的事务和隔离级别
    • 52.MySQL 的视图、存储过程和函数
    • 53.使用 Node 操作 MySQL 的两种方式
    • 54.快速掌握 TypeORM
    • 55.TypeORM 一对一的映射和关联 CRUD
    • 56.TypeORM 一对多的映射和关联 CRUD
    • 57.TypeORM 多对多的映射和关联 CRUD
    • 58.在 Nest 里集成 TypeORM
    • 59.TypeORM 如何保存任意层级的关系?
    • 60.为什么生产环境要用 TypeORM 的 migration 迁移功能?
    • 61.Nest 项目里如何使用 TypeORM 迁移
    • 62.如何动态读取不同环境的配置?
    • 63.快速入门 Redis
    • 64.在 Nest 里操作 Redis
    • 65.为什么不用 cache-manager 操作 Redis?
    • 66.两种登录状态保存方式:JWT、Session
    • 67.Nest 里实现 Session 和 JWT
    • 68.MySQL + TypeORM + JWT 实现登录注册
    • 69.基于 ACL 实现权限控制
    • 70.基于 RBAC 实现权限控制
    • 71.基于 access_token 和 refresh_token 实现登录状态无感刷新
    • 72.单 token 无限续期,实现登录状态无感刷新
    • 73.使用 passport 做身份认证
    • 74.passport 实现 GitHub 三方账号登录
    • 75.passport 实现 Google 三方账号登录
    • 76.为什么要使用 Docker Compose ?
    • 77.Docker 容器通信的最简单方式:桥接网络
    • 78.Docker 支持重启策略,是否还需要 PM2
    • 79.快速掌握 Nginx 的 2 大核心用法
    • 80.基于 Nginx 实现灰度系统
    • 81.基于 Redis 实现分布式 session
    • 82.Redis + 高德地图,实现附近的充电宝
    • 83.用 Swagger 自动生成 api 文档
    • 84.如何灵活创建 DTO
    • 85.class-validator 的内置装饰器,如何自定义装饰器
    • 86.序列化 Entity,你不需要 VO 对象
    • 87.手写序列化 Entity 的拦截器
    • 88.使用 compodoc 生成文档
    • 89.Node 如何发邮件?
    • 90.实现基于邮箱验证码的登录
    • 91.定时任务 + Redis 实现阅读量计数
    • 92.Nest 的 3 种定时任务
    • 93.Nest 里如何实现事件通信?
    • 94.HttpModule + pinyin 实现天气预报查询服务
    • 95.如何记录请求日志
    • 96.短链服务?自己写一个
    • 97.Nest 实现 Server Sent Event 数据推送
    • 98.用 minio 自己搭一个 OSS 服务
    • 99.前端如何直传文件到 Minio
    • 100.基于 sharp 实现 gif 压缩工具
    • 101.大文件如何实现流式下载?
    • 102.Puppeteer 实现爬虫,爬取 BOSS 直聘全部前端岗位
    • 103.实现扫二维码登录
    • 104.Nest 的 REPL 模式
    • 105.实现 Excel 导入导出
    • 106.如何用代码动态生成 PPT
    • 107.如何拿到服务器 CPU、内存、磁盘状态
    • 108.Nest 如何实现国际化?
    • 109.会议室预订系统:需求分析和原型图
    • 110.会议室预订系统:技术方案和数据库设计
    • 111.会议室预订系统:用户管理模块-用户注册
    • 112.会议室预订系统:用户管理模块-配置抽离、登录认证鉴权
    • 113.会议室预订系统:用户管理模块-interceptor、修改信息接口
    • 114.会议室预订系统:用户管理模块-用户列表和分页查询
    • 115.会议室预订系统:用户管理模块-swagger 接口文档
    • 116.会议室预订系统:用户管理模块-用户端登录注册页面
    • 117.会议室预订系统:用户管理模块-用户端信息修改页面
    • 118.会议室预订系统:用户管理模块-头像上传
    • 119.会议室预订系统:用户管理模块-管理端用户列表页面
    • 120.会议室预订系统:用户管理模块-管理端信息修改页面
    • 121.会议室预订系统:会议室管理模块-后端开发
    • 122.会议室预订系统:会议室管理模块-管理端前端开发
    • 123.会议室预订系统:会议室管理模块-用户端前端开发
    • 124.会议室预订系统:预定管理模块-后端开发
    • 125.会议室预订系统:预定管理模块-管理端前端开发
    • 126.会议室预订系统:预定管理模块-用户端前端开发
    • 127.会议室预订系统:统计管理模块-后端开发
    • 128.会议室预订系统:统计管理模块-前端开发
    • 129.会议室预订系统:后端项目部署到阿里云
    • 130.会议室预订系统:前端项目部署到阿里云
    • 131.会议室预定系统:用 migration 初始化表和数据
    • 132.会议室预定系统:文件上传 OSS
    • 133.会议室预定系统:Google 账号登录后端开发
    • 134.会议室预定系统:Google 账号登录前端开发
    • 135.会议室预定系统:后端代码优化
    • 136.会议室预定系统:集成日志框架 winston
    • 137.会议室预定系统:前端代码优化
    • 138.会议室预定系统:全部功能测试
    • 139.会议室预定系统:项目总结
    • 140.Nest 如何创建微服务?
    • 141.Nest 的 Monorepo 和 Library
    • 142.用 Etcd 实现微服务配置中心和注册中心
    • 143.Nest 集成 Etcd 做注册中心、配置中心
    • 144.用 Nacos 实现微服务配置中心和注册中心
    • 145.基于 gRPC 实现跨语言的微服务通信
    • 146.快速入门 ORM 框架 Prisma
    • 147.Prisma 的全部命令
    • 148.Prisma 的全部 schema 语法
    • 149.Primsa Client 单表 CRUD 的全部 api
    • 150.Prisma Client 多表 CRUD 的全部 api
    • 151.在 Nest 里集成 Prisma
    • 152.为什么前端监控系统要用 RabbitMQ?
    • 153.基于 Redis 实现关注关系
    • 154.基于 Redis 实现各种排行榜(周榜、月榜、年榜)
    • 155.考试系统:需求分析
    • 156.考试系统:技术方案和数据库设计
    • 157.考试系统:微服务、Lib 拆分
    • 158.考试系统;用户注册
    • 159.考试系统:用户登录、修改密码
    • 160.考试系统:考试微服务
    • 161.考试系统:登录、注册页面
    • 162.考试系统:修改密码、试卷列表页面
    • 163.考试系统:新增试卷、回收站
    • 164.考试系统:试卷编辑器
    • 165.考试系统:试卷回显、预览、保存
    • 166.考试系统:答卷微服务
    • 167.考试系统:答题页面
    • 168.考试系统:自动判卷
    • 169.考试系统:分析微服务、排行榜页面
    • 170.考试系统:整体测试
    • 171.考试系统:项目总结
    • 172.用 Node.js 手写 WebSocket 协议
    • 173.Nest 开发 WebSocket 服务
    • 174.基于 Socket.io 的 room 实现群聊
    • 175.聊天室:需求分析和原型图
    • 176.聊天室:技术选型和数据库设计
    • 177.聊天室:用户注册
    • 178.聊天室:用户登录
    • 179.聊天室:修改密码、修改信息
    • 180.聊天室:好友列表、发送好友申请
    • 181.聊天室:创建聊天室、加入群聊
    • 182.聊天室:登录、注册页面开发
    • 183.聊天室:修改密码、信息页面开发
    • 184.聊天室:头像上传
    • 185.聊天室:好友∕群聊列表页面
    • 186.聊天室:添加好友弹窗、通知页面
    • 187.聊天室:聊天功能后端开发
    • 188.聊天室:聊天功能前端开发
    • 189.聊天室:一对一聊天
    • 190.聊天室:创建群聊、进入群聊
    • 191.聊天室:发送表情、图片、文件
    • 192.聊天室:收藏
    • 193.聊天室:全部功能测试
    • 194.聊天室:项目总结
    • 195.MongoDB 快速入门
    • 196.使用 mongoose 操作 MongoDB 数据库
    • 197.GraphQL 快速入门
    • 198.Nest 开发 GraphQL 服务:实现 CRUD
    • 199.GraphQL + Primsa + React 实现 TodoList
    • 200.如何调试 Nest 源码?

Nginx 是流行的服务器,一般用它对静态资源做托管、对动态资源做反向代理。

Docker 是流行的容器技术,里面可以跑任何服务。

那 Docker + Nginx 如何结合使用呢?

我们来试一下:

搜索 nginx(这一步需要科学上网,因为要访问 hub.docker.com 这个网站),点击 run:

输入容器名和要映射的端口:

这里把宿主机的 81 端口映射到容器内的 80 端口,点击 run。

这时候就可以看到 docker 容器跑起来了,并且打印了日志:

浏览器访问下 http://localhost:81 可以看到 nginx 欢迎页面:

这很明显是容器里跑的服务。

但是现在的页面是默认的,我想用 nginx 来托管我的一些静态 html 页面怎么做呢?

首先我们要知道现在的配置文件和页面都存在哪里。

在 files 面板可以看到容器内的文件:

里面的 /usr/share/nginx/html/ 目录下面就是所有的静态文件。

双击点开 index.html 看看:

和我们浏览器看到的页面一毛一样。

也就是说,这个目录就是保存静态文件的目录。

那我们在这个目录下放我们自己的 html 不就行了?

我们先把这个目录复制出来:

docker cp  nginx1:/usr/share/nginx/html ~/nginx-html

docker cp 这个命令就是用于在宿主机和容器之间复制文件和目录的。

比如我们把这个目录再复制到容器里:

docker cp  ~/nginx-html nginx1:/usr/share/nginx/html-xxx

可以看到容器内就多了这个目录:

然后我们在这个目录下添加两个 html 来试试看:

echo aaa > aaa.html

echo bbb > bbb.html

docker cp  ~/nginx-html nginx1:/usr/share/nginx/html

但当目标目录存在的时候,docker 会把他复制到目标目录下面:

我们需要先删除容器的这个目录,再复制:

docker cp  ~/nginx-html nginx1:/usr/share/nginx/html

这样就好了:

然后浏览器访问下试试:

现在就可以访问容器内的这些目录了。

也就是说只要放到 /usr/share/nginx/html 下的文件,都可以通过被访问到。

可是为什么呢?

这是因为 nginx 的默认配置。

我们看下 nginx 配置文件,也就是 /etc/nginx/nginx.conf。

复制出来看看:

docker cp  nginx1:/etc/nginx/nginx.conf ~/nginx-html

这是就是 nginx 的默认配置:

其实这个 nginx.conf 叫做主配置文件,里面一般做一些全局的配置,比如错误日志的目录等等。

可以看到 http 下面有个 include 引入了 /etc/nginx/conf.d/*.conf 的配置。

一般具体的路由配置都是在这些子配置文件里。

目录 conf.d 是 configuration directory 的意思。

我们把这个目录也复制出来看看:

docker cp  nginx1:/etc/nginx/conf.d ~/nginx-html

这里面就配置了 localhost:80 的虚拟主机下的所有路由。

虚拟主机是什么呢?

就是可以用一台 nginx 服务器来为多个域名和端口的提供服务。

只要多加几个 server 配置就可以。

这里我们就配置 localhost:80 这一个虚拟主机。

下面的 location 就是路由配置。

比如这个配置:

它就配置了 / 下的所有路由,都是在 root 指定的目录查找。

所以 http://localhost/aaa.html 就是从 /usr/share/nginx/html/aaa.html 找的。

location 支持的语法有好几个,我们分别试一下:

location = /111/ {
    default_type text/plain;
    return 200 "111 success";
}

location /222 {
    default_type text/plain;
    return 200 $uri;
}

location ~ ^/333/bbb.*\.html$ {
    default_type text/plain;
    return 200 $uri;
}

location ~* ^/444/AAA.*\.html$ {
    default_type text/plain;
    return 200 $uri;
}

把之前的 location / 删掉,添加这样几个路由配置。

具体这些配置都是什么意思待会再说。

把这个文件复制到容器内:

docker cp ~/nginx-html/conf.d/default.conf nginx1:/etc/nginx/conf.d/default.conf

然后在容器内的 terminal 执行:

nginx -s reload

重新加载配置文件。

然后来看第一条路由:

location 和路径之间加了个 =,代表精准匹配,也就是只有完全相同的 url 才会匹配这个路由。

不带 = 代表根据前缀匹配,后面可以是任意路径。

这里的 $uri 是取当前路径。

然后如果想支持正则,就可以加个 ~。

这里的正则语法不难看懂,就是 /333/bbb 开头,然后中间是任意字符,最后 .html 结尾的 url。

但是它是区分大小写的,比如这样就不行了:

换成小写就可以:

如果想让正则不区分大小写,可以再加个 *

试一下:

任意的大小写都是可以的。

此外,还有一种语法:

在配置文件加上这个配置:

location /444 {
    default_type text/plain;
    return 200 'xxxx';
}

然后复制到容器里,并 reload:

docker cp ~/nginx-html/conf.d/default.conf nginx1:/etc/nginx/conf.d/default.conf

这时候就有两个 /444 的路由了:

这时候浏览器访问,还是匹配上面的那个路由:

如果想提高优先级,可以使用 ^~

改成这样:

location ^~ /444 {
    default_type text/plain;
    return 200 'xxxx';
}

然后复制到容器里,并 reload:

docker cp ~/nginx-html/conf.d/default.conf nginx1:/etc/nginx/conf.d/default.conf

这时候同一个 url,匹配的就是下面的路由了:

也就是说 ^~ 能够提高前缀匹配的优先级。

总结一下,一共 4 个 location 语法:

location = /aaa 是精确匹配 /aaa 的路由。

location /bbb 是前缀匹配 /bbb 的路由。

location ~ /ccc.*.html 是正则匹配。可以再加个 * 表示不区分大小写 location ~* /ccc.*.html

location ^~ /ddd 是前缀匹配,但是优先级更高。

这 4 种语法的优先级是这样的:

精确匹配(=) > 高优先级前缀匹配(^~) > 正则匹配(~ ~*) > 普通前缀匹配

我们现在是直接用 return 返回的内容,其实应该返回 html 文件。

可以这样改:

location /222 {
    alias /usr/share/nginx/html;
}

location ~ ^/333/bbb.*\.html$ {
    alias /usr/share/nginx/html/bbb.html;
}

然后复制到容器里,并 reload:

docker cp ~/nginx-html/conf.d/default.conf nginx1:/etc/nginx/conf.d/default.conf

都是能正确返回对应的 html 的:

前面用过 root:

root 和 alias 有什么区别呢?

比如这样的两个配置:

location /222 {
    alias /dddd;
}

location /222 {
    root /dddd;
}

同样是 /222/xxx/yyy.html,如果是用 root 的配置,会把整个 uri 作为路径拼接在后面。

也就是会查找 /dddd/222/xxx/yyy.html 文件。

如果是 alias 配置,它会把去掉 /222 之后的部分路径拼接在后面。

也就是会查找 /dddd/xxx/yyy.html 文件。

也就是 我们 root 和 alias 的区别就是拼接路径时是否包含匹配条件的路径。

这就是 nginx 的第一个功能:静态文件托管。

主配置文件在 /etc/nginx/nginx.conf,而子配置文件在 /etc/nginx/conf.d 目录下。

默认的 html 路径是 /usr/share/nginx/html。

然后来看下 nginx 的第二大功能:动态资源的反向代理。

什么是正向、什么是反向呢?

从用户的角度看,方向一致的就是正向,反过来就是反向。

比如这样两个代理:

第一个是正向代理,第二个是反向代理。

第一个代理是代理的用户请求,和用户请求方向一致,叫做正向代理。

第二个代理是代理服务器处理用户请求,和用户请求方向相反,叫做反向代理。

测试 nginx 做反向代理服务器之前,我们先创建个 nest 服务。

npx nest new nest-app -p npm

把服务跑起来:

npm run start:dev

浏览器就访问 http://localhost:3000 看到 hello world 就代表 nest 服务跑成功了:

添加一个全局的前缀 /api

改下 nginx 配置,添加个路由:

location ^~ /api {
    proxy_pass http://192.168.1.6:3000;
}

这个路由是根据前缀匹配 /api 开头的 url, ^~ 是提高优先级用的。

然后复制到容器里,并 reload:

docker cp ~/nginx-html/conf.d/default.conf nginx1:/etc/nginx/conf.d/default.conf

然后你访问 http://localhost:81/api 就可以看到 nest 服务返回的响应了:

也就是这样的:

为什么要多 nginx 这一层代理呢?

自然是可以在这一层做很多事情的。

比如修改 header:

然后复制到容器里,并 reload:

docker cp ~/nginx-html/conf.d/default.conf nginx1:/etc/nginx/conf.d/default.conf

在 nest 服务的 handler 里注入 headers,打印一下:

然后浏览器访问下。

直接访问 nest 服务的话,是没有这个 header 的:

访问 nginx 的反向代理服务器,做一次中转:

这就是反向代理服务器的作用,可以透明的修改请求、响应。

而且,还可以用它实现负载均衡。

在 controlller 里打印下访问日志:

把 nest 服务停掉,然后重新 npm run start

3001 和 3002 端口各跑一个:

浏览器访问下,都是正常的:

控制台也打印了访问日志:

问题来了,现在有一个 nginx 服务器,两个 nest 服务器了,nginx 该如何应对呢?

nginx 的解决方式就是负载均衡,把请求按照一定的规则分到不同的服务器。

改下 nginx 配置文件:

在 upstream 里配置它代理的目标服务器的所有实例。

下面 proxy_pass 通过 upstream 的名字来指定。

然后复制到容器里,并 reload:

docker cp ~/nginx-html/conf.d/default.conf nginx1:/etc/nginx/conf.d/default.conf

这时候我访问 http://localhost:81/api 刷新 5 次页面:

可以看到两个 nest 服务,一个 3 次,一个 2 次。

因为默认是轮询的方式。

一共有 4 种负载均衡策略:

  • 轮询:默认方式。
  • weight:在轮询基础上增加权重,也就是轮询到的几率不同。
  • ip_hash:按照 ip 的 hash 分配,保证每个访客的请求固定访问一个服务器,解决 session 问题。
  • fair:按照响应时间来分配,这个需要安装 nginx-upstream-fair 插件。

我们测试下 weight 和 ip_hash 的方式。

添加一个 weight=2,默认是 1,这样两个服务器轮询到的几率是 2 比 1。

然后复制到容器里,并 reload:

docker cp ~/nginx-html/conf.d/default.conf nginx1:/etc/nginx/conf.d/default.conf

按 command + k,把 nest 服务的控制台日志清空下:

然后我访问了 8 次 http://localhost:81/api

看打印的日志来看,差不多就是 2:1 的轮询几率。

这就是带权重的轮询。

我们再试下 ip_hash 的方式;

然后复制到容器里,并 reload:

docker cp ~/nginx-html/conf.d/default.conf nginx1:/etc/nginx/conf.d/default.conf

按 command + k,把 nest 服务的控制台日志清空下:

再次访问了 http://localhost:81/api

可以看到一直请求到了一台服务器:

这就是 Nginx 的负载均衡的策略。

总结

我们通过 docker 跑了 nginx 服务器,并使用了它的静态资源托管功能,还有动态资源的反向代理功能。

nginx 的配置文件在 /etc/nginx/nginx.conf 里,它默认还引入了 /etc/nginx/conf.d 下的子配置文件。

默认 html 都放在 /usr/share/nginx/html 下。

我们可以通过 docker cp 来把容器内文件复制到宿主机来修改。

修改 nginx 配置,在 server 里配置路由,根据不同的 url 返回不同的静态文件。

有 4 种 location 语法:

  • location /aaa 根据前缀匹配
  • location ^~ /aaa 根据前缀匹配,优先级更高
  • location = /aaa 精准匹配
  • location ~ /aaa/.*html 正则匹配
  • location ~* /aaa/.*html 正则匹配,而且不区分大小写

优先级是 精确匹配(=) > 高优先级前缀匹配(^~) > 正则匹配(~ ~*) > 普通前缀匹配

除了静态资源托管外,nginx 还可以对动态资源做反向代理。

也就是请求发给 nginx,由它转发给应用服务器,这一层也可以叫做网关。

nginx 反向代理可以修改请求、响应信息,比如设置 header。

当有多台应用服务器的时候,可以通过 upstream 配置负载均衡,有 4 种策略:轮询、带权重的轮询、ip_hash、fair。

掌握了静态资源托管、动态资源的反向代理+负载均衡,就算是掌握了 Nginx 的核心用法了。

上次更新: 6/21/25, 9:42 AM
贡献者: YNight
Prev
78.Docker 支持重启策略,是否还需要 PM2
Next
80.基于 Nginx 实现灰度系统