前沿聊天：有没有发现，近几年随着工作的深入，好像除了nginx 最亲切外，什么LVS VIP(跟会员一样) APISIX Kong 还有微服务的GateWay，各种网关层面的名词喋喋不休的出现在你的脑子里。再加上需要增加云服务的鲁棒性，一层套一层，再优化迁移。o(╥﹏╥)o 要老命了，今天就把我知道的一些名词整理一下。
一丶 Nginx、LVS 、Keepalived、VIP
先来三个不常见的
LVS（Linux Virtual Server）：内核级负载均衡器，负责将客户端请求按调度算法（如 RR、WLC 等）转发给后端真实服务器（Real Server）。支持 NAT/DR/TUN 三种模式。
Keepalived ：基于 VRRP 协议的高可用守护进程，主要功能：1. 实现主备 LVS 调度器之间的 VIP 漂移；2. 对 LVS 服务或后端 RS 进行 健康检查；3. 自动维护 ipvsadm 规则（无需手动配置 LVS）。
VIP（Virtual IP）：虚拟 IP 地址，是客户端访问服务的唯一入口。正常情况下由主 LVS 节点持有；主节点故障时，由 Keepalived 将 VIP “漂”到备节点。
LVS 负责负载均衡，Keepalived 负责 LVS 的高可用（通过 VIP 漂移实现），而 VIP 是客户端访问的统一入口。
1.先简单分辨 Nginx 和上面三个的关系
Nginx（读作 engine x）是一款高性能、轻量级的HTTP和反向代理服务器，同时支持IMAP/POP3/SMTP协议。它采用事件驱动的异步非阻塞架构，在高并发场景下能保持低资源消耗和快速响应，单机可支撑5万+并发连接。常被用于静态资源托管、反向代理、负载均衡、动静分离等场景
它们本身没有强制依赖关系，但在实际高可用架构中，经常被组合使用 —— 它们属于不同层级的组件，可以独立工作，也可以协同配合。
✅ 结论：
Nginx 和 LVS 是“干活的”（负载均衡器），一个在 L7（应用层），一个在 L4（传输层）。
Keepalived 是“保活的”（高可用控制器），负责让 VIP 在多个“干活的”节点间漂移。
VIP 是“门牌号”，客户端只认它。
👉 所以：Nginx 和 LVS 是“同类竞争者”（都做负载均衡，但层级不同），而 Keepalived + VIP 是它们的“高可用搭档”。
LVS 是“高速公路入口收费站”，负责快速分流车辆（TCP 连接）；Nginx 是“城市内部导航系统”，负责看懂目的地（HTTP 请求）并精准送达。两者分工协作，各司其职。
所以你的架构图中 既有 LVS 又有 Nginx 是完全合理且常见的 —— LVS 保护的是 Nginx 集群的高可用和高吞吐，而 Nginx 提供的是应用层的智能路由能力。
“LVS + Nginx 两层转发，会不会变慢？”
不会明显变慢，反而在高并发场景下性能更高、更稳定。
什么时候不需要 LVS？
如果你的业务满足以下条件，可以只用 Nginx + Keepalived：
QPS < 1万
并发连接 < 1万
团队运维能力有限，不想维护复杂架构
流量增长缓慢，短期内无需横向扩展
💡 对于 90% 的中小项目，Nginx + Keepalived 足够了，没必要上 LVS。
典型协作场景：
场景 1️⃣：Nginx 高可用架构（最常见）
Client → VIP → Keepalived（主备） → Nginx（反向代理） → 后端服务
作用：防止单点故障。一台 Nginx 挂了，另一台自动接管 VIP。
Keepalived 做什么？
主机持有 VIP
定期检查 Nginx 进程是否存活（通过 vrrp_script）
若 Nginx 崩溃，主动降权，触发 VIP 漂移到备机
场景 2️⃣：LVS 高可用架构
Client → VIP → Keepalived（主备 LVS 调度器） → LVS（DR/NAT） → Real Server（如 Nginx/应用）
Keepalived 做什么？
管理 VIP 漂移
自动加载 ipvsadm 规则（通过 virtual_server 配置）
检查后端 Real Server 健康状态（可选）
场景 3️⃣：LVS + Nginx 混合架构（超大流量）
Client
↓
VIP
↓
Keepalived → LVS（四层分发）
↓
多台 Nginx（七层处理） ← Real Servers in LVS DR mode
↓
后端微服务
+------------------+
| Client |
+--------+---------+
|
访问 VIP（虚拟IP）
↓
+------------------------------+
| Keepalived（VRRP高可用） |
| - 管理 VIP 漂移 |
| - 健康检查 |
+--------------+---------------+
|
自动配置并驱动
↓
+------------------+
| LVS |
| - 负载均衡转发 |
| - NAT/DR/TUN模式 |
+------------------+
↓
+----------------------+
| Real Servers（RS） |
+----------------------+
业务组实际配置：
|
+----------------+-----------------+
| VIP: |
172.25.38.56 |---- 172.25.38.4/172.25.38.8 ----|172.25.38.57
+-------+--------+ +--------+-------+
| DS1 | | DS2 |
| LVS+Keepalived | | LVS+Keepalived |
+-------+--------+ +--------+-------+
| |
+----------------+-----------------+
|
+------------+ | +------------+
| RS1 |172.25.38.52 | 172.25.38.53 | RS2 |
| nginx +--------------+---------------+ nginx |
+------------+ +------------+
| |
+----------------+-----------------+
|
+------------+ | +------------+
| DS1-AI |172.25.244.123|172.25.244.128 | DS2-AI |
| KONG +--------------+---------------+ KONG |
+------------+ +------------+
二丶OpenResty与APISIX、 Kong 、 Janus
🧱 一、核心定义
1. OpenResty
是什么？
一个基于 Nginx + LuaJIT 的高性能 Web 平台，由章亦春（agentzh）主导开发。
作用：
让你用 Lua 脚本直接嵌入 Nginx，实现动态逻辑（如认证、限流、路由改写），无需后端服务介入。
本质：开发框架 / 引擎，不是开箱即用的产品。
✅ 类比：OpenResty = “Nginx 发动机 + Lua 编程接口”
2. APISIX
是什么？
一个云原生、高性能的 API 网关，由 Apache 软件基金会孵化并毕业（顶级项目）。
底层：完全基于 OpenResty 构建。
特点：
配置存储：etcd（支持毫秒级动态更新）
插件热加载（无需 reload）
支持多语言插件（Lua、Go、Java、Wasm）
云原生友好（Kubernetes Ingress Controller）
✅ 类比：APISIX = “基于 OpenResty 引擎打造的智能汽车”
3. Kong
是什么？
一个开源的 API 网关和微服务管理平台，由 Mashape（现 Kong Inc.）开发。
底层：同样基于 OpenResty 构建。
特点：
配置存储：PostgreSQL 或 Cassandra
插件生态极其丰富（100+ 官方/社区插件）
提供企业版（Kong Enterprise）含 GUI、分析、Dev Portal
社区活跃，企业采用广泛
✅ 类比：Kong = “基于 OpenResty 引擎打造的豪华 SUV”
4. Janus
是什么？
一个早期的轻量级 API 网关，用 Go 语言编写。
现状：已停止维护（GitHub 最后更新在 2018 年），不推荐用于生产。
与 OpenResty 关系：无任何关系！它不是基于 OpenResty，而是独立实现。
⚠️ 注意：Janus 是“干扰项”，常被误认为与 OpenResty 有关，实际是 Go 生态产物。
┌──────────────────────┐
│ OpenResty │ ←─ 核心引擎（Nginx + LuaJIT）
└──────────┬───────────┘
│
┌────────────────────────┼────────────────────────┐
│ │ │
┌──────────▼──────────┐ ┌──────────▼──────────┐ ┌──────────▼──────────┐
│ APISIX │ │ Kong │ │ （其他网关） │
│ - Apache 顶级项目 │ │ - 商业公司主导 │ │ 如: Gravitee, Tyk... │
│ - etcd 存储 │ │ - PostgreSQL/Cassandra│ └─────────────────────┘
│ - 毫秒级动态配置 │ │ - 插件生态强大 │
└──────────────────────┘ └──────────────────────┘
│
❌
┌──────────▼──────────┐
│ Janus │ ←─ Go 编写，与 OpenResty 无关
│ - 已停止维护 │
└──────────────────────┘
✅ 补充：为什么都基于 OpenResty？
因为 OpenResty 完美解决了 API 网关的核心需求：
高性能：Nginx 事件驱动模型
可编程：Lua 脚本嵌入，灵活控制请求生命周期
低延迟：LuaJIT JIT 编译，接近 C 性能
成熟稳定：被 Cloudflare、阿里、腾讯等大规模验证
所以 APISIX 和 Kong 都选择站在 OpenResty 的肩膀上，而不是重复造轮子。
┌──────────────────────────────────────┐
│ 客户端访问入口 │
│ (统一接入点) │
└──────────────────┬───────────────────┘
▼
┌───────────────────────────────┐
│ VIP (虚拟IP) │ ←─ 由 Keepalived 管理漂移
└───────────────────────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
│ │ │
┌──────────▼──────────┐ ┌──────────▼──────────┐ ┌───────────▼────────────┐
│ 四层负载均衡层 │ │ 高可用控制层 │ │ 七层网关/代理层 │
│ (L4: TCP/UDP) │ │ (HA & Failover) │ │ (L7: HTTP/gRPC/WebSocket)│
└───────────────────────┘ └───────────────────────┘ └────────────────────────┘
│ │ │
┌──────────▼──────────┐ ┌──────────▼──────────┐ ┌───────────▼────────────┐
│ LVS │ ◄───►│ Keepalived │ │ OpenResty │
│ - 内核级高性能 │ │ - VRRP 协议实现 │ │ - Nginx + LuaJIT │
│ - DR/NAT/TUN 模式 │ │ - VIP 漂移 │ │ - 可编程反向代理 │
│ - 不解析应用层内容 │ │ - 健康检查 │ │ - 动态路由/限流/认证等 │
└───────────────────────┘ └───────────────────────┘ └───────────┬────────────┘
│
┌──────────────────┴──────────────────┐
│ 基于 OpenResty 的 API 网关 │
└──────────────────┬──────────────────┘
│
┌─────────────────────┬─────────────────────┬─────────────────────┐
│ │ │ │
┌─────────▼─────────┐ ┌─────────▼─────────┐ ┌─────────▼─────────┐ ┌─────────▼─────────┐
│ APISIX │ │ Kong │ │ Janus* │ │ 自研网关 (Lua/Go) │
│ - Apache 顶级项目 │ │ - 插件生态丰富 │ │ - 已停止维护 │ │ - 基于 OpenResty 或 │
│ - etcd 存储 │ │ - PostgreSQL/Cassandra│ │ - Go 编写 │ │ 其他框架开发 │
│ - 多语言插件 │ │ - 企业版功能强大 │ │ - 静态配置 │ └─────────────────────┘
│ - 毫秒级动态更新 │ │ - 社区活跃 │ │ │
└───────────────────┘ └───────────────────┘ └───────────────────┘
微服务 GateWay
“微服务 Gateway”（Microservices Gateway），通常简称为 API Gateway，是现代微服务架构中的核心组件之一。它的核心使命是：作为所有客户端访问微服务的统一入口，解耦客户端与后端服务，集中处理横切关注点（cross-cutting concerns）。
三丶Spring Cloud Gateway
Spring Cloud Gateway 是 Spring 官方提供的基于 Spring 5、Spring Boot 2 和 Project Reactor 的 API 网关。它旨在提供一种简单而有效的方式来路由到API，并为它们提供跨域的关切，比如安全性（认证和授权）、监控/指标收集、限流等。
主要特性
基于Java配置的路由定义：可以方便地通过编写代码来定义路由规则。
断言(Predicates)：用于匹配HTTP请求中的各个部分，如headers、请求参数、路径等。
过滤器(Filters)：允许你在发送下游请求之前或之后修改请求和响应。这些过滤器可以在网关上全局应用，也可以根据特定的路由进行配置。
动态路由：支持从各种来源加载路由定义，如服务发现机制。
易于集成：与Spring生态系统中的其他组件无缝集成，如Spring Cloud Config用于外部化配置管理。
核心概念
Route(路由)：网关的基本构建块。一个路由由ID、目标URI、谓词集合、过滤器集合组成。如果聚合谓词返回true，则匹配该路由。
Predicate(谓词)：指定在路由转发请求之前必须满足的一组条件。多个谓词可以用逻辑运算符组合。
Filter(过滤器)：在请求被发送到下游服务之前或之后对其进行修改。
使用场景
微服务架构中的API网关：作为所有客户端请求的入口点，然后将这些请求路由到后端适当的服务。
统一的安全层：实现身份验证和授权功能，确保只有经过认证的用户才能访问某些资源。
负载均衡：配合服务注册与发现机制，能够实现对下游服务实例的智能路由。
限流和熔断：防止系统过载并提高系统的容错能力。
如何使用
要在项目中使用Spring Cloud Gateway，你需要添加相应的依赖项到你的pom.xml或build.gradle文件中。接着，你可以通过Java配置类或者YAML文件来定义路由规则、谓词和过滤器。
由于Spring Cloud Gateway是基于Netty运行的，并且不支持传统的Servlet容器，所以在创建Spring Boot应用程序时需要注意选择正确的启动器。
┌──────────────┐
│ Client │ ← 浏览器 / App / 外部系统
└──────┬───────┘
│
HTTPS/HTTP 请求 (南北向流量)
▼
┌─────────────────────────────────────┐
│ Spring Cloud Gateway │ ← 统一入口网关
│ (Reactive, Non-blocking, Netty) │
└───────────────────┬─────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ user-service │ │ order-service │ │ payment-service│
│ (注册到 Eureka)│ │ (注册到 Nacos) │ │ (注册到 Consul)│
└────────────────┘ └────────────────┘ └────────────────┘
▲ ▲ ▲
└──────────────────┴──────────────────┘
微服务集群（东西向流量）
[Client]
│
▼
(VIP + Keepalived 或 LVS) ← 四层负载均衡（可选）
│
▼
┌─────────────┐ ┌─────────────┐
│ Gateway-1 │ │ Gateway-2 │ ← 多实例部署
└──────┬──────┘ └──────┬──────┘
└─────────┬────────┘
▼
[Service Registry: Eureka/Nacos]
▼
[user-service, order-service, ...]
四丶额外补充
网关按功能、协议、场景可分为多种类型：
- API Gateway（应用网关）
用途：微服务架构的统一入口
代表：Kong、APISIX、Spring Cloud Gateway、Envoy、Tyk
特点：支持 JWT、OAuth2、限流、插件等 - Ingress Gateway（云原生网关）
用途：Kubernetes 集群外部流量入口
代表：Istio Ingress Gateway（基于 Envoy）、NGINX Ingress Controller、APISIX Ingress
特点：与 Service Mesh 深度集成，支持 mTLS、金丝雀发布 - Service Mesh Gateway（服务网格网关）
用途：Mesh 边界流量控制（东西向 + 南北向）
从外部 → 进入系统：流量从“北”流向“南” → North → South
从系统 → 返回外部：流量从“南”返回“北” → South → North
所以统称为 North-South Traffic（南北向流量）
代表：Istio Gateway、Linkerd Ingress
特点：策略统一管理，与 Sidecar 协同
4. IoT Gateway（物联网网关）
用途：连接边缘设备与云平台
协议：MQTT、CoAP、LoRaWAN → 转 HTTP/WebSocket
代表：EMQX、ThingsBoard Gateway、Azure IoT Edge
5. Database Gateway（数据库网关）
用途：统一数据库访问、SQL 防火墙、读写分离
代表：ShardingSphere-Proxy、MySQL Router、ProxySQL
6. Message Gateway（消息网关）
用途：跨消息中间件协议桥接
示例：RabbitMQ ↔ Kafka、MQTT ↔ AMQP
代表：Apache Camel、EMQX Bridge
7. Email / SMS Gateway（通信网关）
用途：统一发送邮件/短信
代表：企业自建 SMTP 网关、Twilio、阿里云短信网关
8. Legacy System Gateway（遗留系统网关）
用途：将老系统（如 SOAP、CORBA）暴露为 REST API
工具：Apache Camel、MuleSoft、WSO2
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
