对外提供服务使用 nginx 还是网关地址

那为什么不担心网关压力过大呢

方案 2 。
nginx 是无状态的，单纯转发请求很高效。即使单台 nginx 扛不住，前面还可以接 keepalived 做横向扩展。

2 的弊端 是 2 个方案都存在的，所以选 2

之前在公司要求: 负载均衡器-> 静态资源 / spring cloud gateway
对应的应该是 nginx->zuul
目前 nginx 还是比各种号称 "超越 nginx"/"堪比 nginx"的, 都要稳一些(爬过坑)

先说说有多少压力

2

估计一下需求，做一下压力测试就好了吧

一般 nginx 不会自己搭，而是买云服务商的负载均衡服务，就算挂了也有人背锅

f5->nginx->backend

cdn web 防火墙 slb nginx bakend
我有个项目是这样的

我司是 ngxin->frontend->spring cloud gateway->backend 。需要对外暴露 API，就是 ngxin 加一个 server，转发到 gateway 的事

@iphoneXr #10 问一下，slb 和 backend 之间的 nginx 是什么作用？

按照经验来说，担心 Nginx 压力过大都是多余，你的 qps 能到 1000 吗？我怀疑可能 100 都没有

选 2，nginx 纯粹做转发，效率和性能 都是杠杠的

1. 单个 Nginx 扛不住，单个 Zuul 一定抗不住。
2. 单个 Zuul 扛不住，可以通过 Nginx 做负载均衡。
3. 单个 Nginx 扛不住，可以在更前面搭建 LVS + Keepalived (LVS 没有流量瓶颈，只做请求转发，Nginx 会有流量瓶颈)，然后 LVS 给 Nginx 做负载均衡，Nginx 再给 Zuul 做负载均衡。
4. 如果单个 LVS 还扛不住，用 DNS 服务给 LVS 做负载，如果这个再扛不住，你们需要更资深的人了。

但是，你们的数据库扛得住吗？

nginx 转到 zuul 或 spring cloud gateway ； 在 zuul 或 gateway 要做鉴权之类的

@des f5 是啥

MVVM 架构的话，前端放到对象存储上，经 cdn 加速。网关用 nginx 或 zuul，然后接到后端。这样做的话前后端使用不同的 dns 地址。

要做成一样的 dnss 地址的话，都经过 nginx，不用 zuul，但是 nginx 前加上 cdn，前端回源请求会减少很多，不必担心前端带来的压力。

@warcraft1236 #19 硬件负载均衡器

@ilaipi slb 做的四层转发，后面接多个 nginx 。 nginx 可以做监控和代理转发，方便。

@iphoneXr 其实 slb 也就可以理解为所谓的 keepalive 这些，slb 跑四层转发，nginx 做 7 层代理转发和前端代码。

方案 2，优点简直一堆。
加一个上面没有提到的，当你要使用 https 的时候，在 nginx 层加就好了。

当然是 2

单个 Nginx 扛不住，单个 Zuul 一定抗不住

@jorneyr 单纯 echo 的话，你这套负载能力，淘宝双 11 秒杀的并发量应该也能搞定

果断 nginx 代理走起

外部统一做 nginx 转发，然后看情况要不要分前后端 Nginx，后端 nginx 打到对应的网关层

Nginx 扛不住，前面加 4 层负载