大家好，我是IT孟德，You can call me Aman(阿瞒，阿弥陀佛的ē，Not阿门的ā)，一个喜欢所有对象（热爱技术）的男人。我正在创作架构专栏，秉承ITer开源精神分享给志同道合（爱江山爱技术更爱美人）的朋友。专栏更新不求速度但求质量（曹大诗人传世作品必属精品，请脑补一下《短歌行》：对酒当歌，红颜几何？譬如媳妇，吾不嫌多...青青罗裙，一见动心，但为佳人，挂念至今...），用朴实无华、通俗易懂的图文将十六载开发和架构实战经验娓娓道来，让读者茅塞顿开、相见恨晚...如有吹牛，不吝赐教。关注wx公众号：IT孟德，一起修炼吧！
专栏文章推荐：
1、前言
2024年，上海浦东国际机场客流量以7678万+人次位居全国第一，其中出入境客流3180万+人次，接近北京首都机场、广州白云机场和深圳宝安机场三场之和。另外货邮吞吐量377.8万吨，在全球范围内仅次于香港国际机场。
| 排名 | 机场名称 | 旅客吞吐量（单位：万人次） | 出入境客流（单位：万人次） | 货邮吞吐量（单位：万吨） |
| 1 | 上海浦东国际机场 | 7678.70 | 3180.59 | 377.83 |
| 2 | 广州白云国际机场 | 7636.48 | 1462.49 | 238.19 |
| 3 | 北京首都国际机场 | 6736.74 | 1485.62 | 144.33 |
| 4 | 深圳宝安国际机场 | 6147.73 | 518.10 | 188.15 |
| 5 | 成都天府国际机场 | 5490.58 | 562.11 | 38.49 |
| 6 | 北京大兴国际机场 | 4944.10 | 459.80 | 32.62 |
| 7 | 重庆江北国际机场 | 4867.70 | 190.00 | 46.95 |
| 8 | 杭州萧山国际机场 | 4805.39 | 470.00 | 73.49 |
| 9 | 上海虹桥国际机场 | 4794.41 | 321.06 | 42.77 |
| 10 | 昆明长水国际机场 | 4717.83 | 297.00 | 38.56 |
浦东机场作为一座国际大都市的旅客集散地，连接着城市之间乃至全球交通网络（异构网络）。出港旅客在多语种播报和标识牌的指引下，无缝换乘地铁、公交、出租车、网约车等疏散至城市各个角落。机场，宛如现实世界接入全球经济与社会活动网络的重要网关，穿梭其间，每一位旅客都如同一个经过层层校验、被打包路由至目的地的数据。
-
数据转发： 如同网关负责根据目标地址选择路径并转发数据，飞机降落带来了世界各地的旅客和货物，然后被高效地分流转送至四面八方。机场通过空管塔台进行航班流量整形与优先级控制（QoS），通过语音播报、标识牌等分流（路由）国内与国际旅客进出港。它承载着流量的聚合与分发，其吞吐能力直接影响着城市的运转效率和活力。
-
协议转换： 网关处理不同网络协议之间的转换，机场则在不同交通方式之间实现了物理协议的转换。旅客通过陆路交通工具（汽车、火车、地铁）抵达机场，遵循航站楼内部的值机、安检、登机流程，最终被“封装”进飞机的“数据帧”，经由特定的“物理链路”（航线）传输出去。到达目的地机场后，反向进行“解包”和“协议转换”，接入当地交通系统。货物运输也是如此，包装标准、货运单据的处理类似于协议适配。
-
安全控制： 网关是网络安全的第一道防线，机场同样承担着安全屏障的重要功能。旅客需要携带身份证、护照、签证、登机牌通过值机和安检，过滤各类风险，确保运输安全。边防和海关对入境人员进行资格审查和物品查验，确保符合国家安全的访问策略，保障社会秩序。
-
插件机制：网关作为流量入口，为应对不同业务场景的差异化需求，支持更加灵活的插件机制。机场提供了休闲娱乐、商业零售、餐饮服务、通信服务、交通接驳等大量配套和增值服务，从单纯的交通连接器升级为适配多样场景的综合服务入口，从而更好满足乘客的需求和提升运转效率。如机场通过新增免税店、充电站、共享办公区等，适配跨境出行和商务旅客等新兴场景。
在我们生活的城市中，不光是机场，火车站、汽车站、边防站、物流中心、生鲜批发市场都类似于大大小小的网关，承担着数据转发、协议转换和安全控制等功能。
2、网关的作用是什么？
网关（Gateway）是一种实现异构网络（不同通信协议、数据格式或网络架构）数据转换与传输的硬件设备或软件服务。其核心价值在于打破网络异构性，通过流量调度、协议转换及安全控制，实现高效安全互联。作为系统的统一入口，将共性、非业务、跨服务功能从业务服务中剥离，交由网关集中处理，这是分布式系统应对复杂度治理的必然选择。这种分工让业务服务专注核心逻辑，提升开发与迭代效率；网关则聚焦共性治理，实现全局标准统一、系统简化与安全增强。简言之，网关以 “统一入口” 简化交互，屏蔽后端服务细节；以 “集中治理” 提升效率，实现共性功能全局管控；以 “隔离保护” 保障系统安全，在外部请求与内部服务间建立屏障。
早期网关功能相对单一，主要承担协议转换、简单路由等基础核心任务。随着微服务架构的普及、云原生技术的成熟以及物联网应用的爆发，网关的形态正发生深刻变化。如今网关的分类也愈发多元，聚焦微服务间通信与治理的微服务网关、兼顾API全生命周期管理的API网关、适配物联网场景的边缘网关、侧重安全防护的还有安全网关......尽管称谓五花八门,但功能边界已逐渐模糊。比如云原生网关整合了流量调度、服务治理、安全防护等能力，适配K8s和降低资源开销与运维复杂度；边缘网关则融合协议转换、边缘计算、本地缓存能力，平衡物联网连接规模、处理效率和安全。以下是常见的网关类型：
| 网关类型 | 主要作用 | OSI工作层级 | 代表产品 | 应用场景示例 |
| 流量网关 | 负责流量调度与负载均衡、基础安全防护、流量监控与日志记录、协议转换与路由管理等，降低网络与服务的耦合度 | 传输层：基于 TCP/UDP 端口的流量调度（如将 80 端口 HTTP流量分发至Web 服务器，3306 端口MySQL流量分发至数据库集群）、TCP 连接复用 应用层：基于域名、URL路径的高级路由 | 硬件：F5 BIG-IP 软件：Nginx、HAproxy、LVS、Apisix 云服务：阿里云SLB、华为云ELB、腾讯云CLB |
|
| 安全网关 | 提供边界安全防护，包括防火墙、入侵检测/防御（IDS/IPS）、病毒过滤、VPN 加密、恶意流量拦截，保障内部网络的安全 | 网络层：处理IP地址和路由，执行基础防火墙策略（如IP黑白名单） 传输层：控制TCP/UDP端口访问，防止端口扫描攻击 应用层：深度解析HTTP、FTP等协议内容，防御SQL注入、跨站脚本（XSS）等应用层攻击 | 硬件：华为USG系列、Palo Alto PA系列、深信服NGAF系列 云服务：阿里云WAF/DDos防护产品、腾讯云WAF/DDos防护产品 |
|
| NAT网关 | 实现私有IP与公网IP的双向转换，解决IPv4地址资源不足问题，同时隔离内外网结构，增强网络安全性 | 网络层：IP地址转换 传输层：端口多路复用（PAT）涉及端口号转换 | 硬件：Juniper SRX 系列、Cisco ASA防火墙（支持NAT/PAT） 云服务：阿里云NAT网关、腾讯云NAT网关 |
|
| 微服务网关 | 微服务架构下的通信入口，负责服务路由、负载均衡、服务发现、熔断降级，处理跨服务认证 | 应用层 | Spring Cloud Gateway、Netflix Zuul、Kong |
|
| API网关 | 管理API全生命周期、提供通用横切功能（认证、授权、限流、日志、监控）、协议转换、API版本管理与文档维护 | 应用层 | Kong、Apisix、ShenYu |
|
| 云原生网关 | 在传统网关（负载均衡、服务治理等）基础上，强化了对云原生场景的适配，支持K8s Ingress标准、服务网格集成、可观测性等 | 应用层：处理HTTP/HTTPS、gRPC、WebSocket等应用层协议 传输层：部分产品（如Envoy、APISIX）可代理TCP/UDP流量 | 开源：Apisix、Higress、Envoy、Istio Gateway 云服务：阿里云MSE网关、腾讯云API网关 |
|
| AI网关 | 专为AI应用设计的流量治理组件，统一代理大模型API和MCP Server，包括模型路由、请求缓存、数据防护、审计追踪、Token限流等，简化AI集成流程 | 应用层：适配AI特有协议，如OpenAI API | Higress（AI插件集）、Azure AI Gateway |
|
| 边缘网关 | 整合本地数据处理、设备接入、协议转换、边缘计算等能力，实现边缘侧与云端数据同步，降低带宽消耗，并提升本地实时响应能力 | 物理层与数据链路层：通过以太网、Wi-Fi、4G/5G 等接口连接本地设备，处理硬件通信 网络层：负责IP路由、子网划分，实现本地设备与上层网络的地址映射和数据转发 传输层：基于TCP/UDP协议保障数据传输的可靠性或实时性 应用层：核心功能层，处理协议转换（如MQTT与HTTP的适配）、数据格式解析（如JSON/XML 转换）等应用层逻辑 | 工业网关：西门子 SIMATIC IoT Gateway、罗克韦尔 Allen-Bradley Edge Gateway 通用网关：思科 IR829（支持 4G/5G，适用于户外边缘场景）、华为 OceanConnect Edge Gateway（侧重物联网协议转换） 云厂商方案：微软 Azure IoT Edge、AWS IoT Greengrass、阿里云 Link IoT Edge（支持边缘节点部署与云端协同） |
|
3、如何选择网关？
除针对特定场景设计的网关（如NAT网关、边缘网关、安全网关、AI网关）外，其他通用型网关的功能，尤其是在应用层，往往存在显著的交叉与重叠。因此，在架构选型决策过程中，核心并不在于网关的分类或功能，而在于精准锚定自身场景的核心需求。即不必纠结 “哪种网关功能更强大、技术更先进”，而要聚焦 “当前架构最需要解决什么问题、未来1~3年最可能遇到什么问题”。
以云原生架构下的流量网关选型为例，究竟是选择传统的Nginx，主流开源方案如APISIX或Higress，还是直接采用Envoy + Istio服务网格方案？
第一步：明确刚需，排除明显不匹配的方案
-
若核心诉求是 “简单稳定 + 低学习成本”：比如中小团队迁移云原生初期，仅需基础的反向代理、静态资源缓存、简单路由（路径/域名匹配），且团队运维以Nginx为主力 -- 直接选Nginx。Nginx 的优势在于极致性能与稳定性，单实例每秒可处理数万级请求，在静态资源转发、简单反向代理场景中仍不可替代。但需接受其动态配置依赖reload（可能有毫秒级抖动）、原生不支持K8s Service动态发现的短板。
-
若核心诉求是 “动态配置 + 微服务适配”：比如微服务架构下，服务频繁发布、需要动态更新路由规则（无需重启），且依赖K8s原生Service发现（自动感知Pod上下线）-- 排除 Nginx（动态性弱），优先考虑Apisix或Higress。Apisix与Higress这类云原生网关则针对性解决了动态性问题，它们基于etcd 实现配置热更新，配置变更从提交到生效可控制在毫秒级，能实时感知K8s Service的端点变化，简化K8s集群内微服务发现并实现了api全生命周期管理。
-
若核心诉求是 “全栈流量治理”：比如企业需要统一流量治理，Envoy + Istio可提供全栈解决方案。Envoy作为数据平面，不仅处理南北向流量（网关），还能管理服务间的东西向流量（Mesh），实现统一控制，避免网关与服务网格规则割裂（比如网关配置了限流，Sidecar却未同步导致失效）。但这种能力是是以架构复杂度为代价的，且Sidecar模式会引入额外延迟，适合对治理能力要求高于极致性能的场景。
第二步：用重要但非必须的诉求缩小范围，平衡功能与成本
-
若需 “强扩展性 + 轻量插件”：比如业务有定制化需求（如特殊鉴权逻辑），且希望插件开发门槛低-- Apisix 更合适。它的插件机制轻量，支持热插拔，社区提供大量现成插件（如OpenTelemetry 链路追踪、Dubbo协议转换），且定制插件可通过简单API注册。
-
若需 “K8s生态深度贴合”：比如团队重度依赖K8s原生能力（如CRD、Gateway API 标准），且需要与云厂商服务（如阿里云MSE）无缝对接--Higress 更优。它基于Envoy内核，但在 K8s 适配层做了深度优化（比如直接解析 K8s Service 的标签路由），且兼容 Gateway API 规范（未来云原生网关的标准接口），避免被特定Ingress规则绑定。
-
若需 “极致性能 + 协议兼容”：比如高并发场景（每秒数十万请求），且涉及多协议转换（HTTP转 gRPC/Dubbo，甚至 WebSocket 长连接）— Apisix和Envoy更占优。两者均基于异步非阻塞架构（Apisix用OpenResty，Envoy用 C++），性能接近原生Nginx；而 Nginx如需支持gRPC等协议需额外编译模块，灵活性较差。
第三步：评估隐性成本，避免选时容易用时难
-
运维团队的技术栈匹配度：比如团队熟悉Lua/OpenResty，Apisix的二次开发和问题排查会更顺畅；若团队擅长Go语言，Higress（Go编写）或 Envoy（可通过WebAssembly 用Go写插件）的上手成本更低；而 Istio+Envoy 的运维复杂度高（需理解 Pilot、Mixer 等组件），适合有专职服务网格运维团队的中大型企业。
-
未来架构演进的兼容性：比如计划从独立微服务升级到服务网格，可优先选Higress（兼容Gateway API，未来能平滑接入Istio）；若明确长期维持轻量微服务，无需服务网格的复杂治理，Apisix的轻量特性会更省心。
-
社区与生态支持：开源方案的生命力依赖社区--Apisix、Higress和Istio社区活跃（issue响应快，新版本迭代快），Nginx虽稳定但云原生特性更新慢（如对Gateway API 的支持滞后），小团队尽量避开社区冷清的小众方案。
| 对比维度 | Nginx | Apisix | Higress | Envoy | SLB/ELB/CLB |
| 定位 | Web服务器/反向代理 | 云原生API网关（流量+微服务） | 云原生API网关（深度集成云生态） | 服务网格SideCar代理 | 公有云流量分发服务，支持四层、七层负载均衡 |
| 技术基础 | 多进程单线程模型（C语言） | 基于OpenResty（Nginx + LuaJIT） | 基于Go语言，基于Envoy数据面 | 单进程多线程模型（C++） | / |
| 支持协议 | HTTP、HTTPS、WebSocket、WSS、gRPC | HTTP、HTTPS、HTTP 3.0、WebSocket、WSS、gRPC、MQTT、 Dubbo | HTTP、HTTPS、HTTP 3.0、gRPC、Dubbo等 | HTTP、HTTPS、HTTP 3.0、gRPC、Redis、MySQL | HTTP、HTTPS、gRPC |
| 配置管理 | 静态配置，配置变更、Lua插件变更需要Reload进程 | 基于etcd的声明式API + Dashboard动态配置，支持配置、证书、插件热更新 | 基于K8s CRD + 控制台，支持热更新，集成云配置中心（如ACM） | 基于 xDS API 动态配置 | 资源变更后由云服务之间的OpenAPI能力动态加载配置 |
| 性能 | 基于多进程 + 单线程事件驱动模型（Epoll），无锁设计减少上下文切换，适合高并发短连接，优化后Http QPS 10万+，延迟1~5ms | 复用Nginx内核，通过LuaJIT插件扩展，平衡性能与灵活性，Http1.1请求QPS接近Nginx（约90%性能） | 接近Nginx性能，Http QPS约为Nginx的85%左右 | 多线程优化，Http1.1请求QPS约Nginx 70%性能 | 单个ELB实例最大支持100万QPS、千万级并发连接 |
| 服务发现 | 服务发现支持K8s | 服务发现支持K8s、Nacos、ZooKeeper、Eureka、consul、DNS、固定IP | 支持K8s、Nacos、Eureka，深度适配阿里云服务发现 | K8s、Consul、Eureka、Nacos | 服务发现支持K8s |
| 扩展性 | 依赖Lua模块或第三方模块，扩展需修改配置并reload，灵活性有限；社区模块成熟但更新慢 | 插件热插拔机制，社区提供300+现成插件，支持Lua、go、java等自定义插件（Lua插件性能最佳，其他语言有rpc开销） | 集成阿里云生态服务（如ARMS、WAF）；支持WASM插件（跨语言，须符合Proxy-Wasm规范） | 基于Filter机制扩展，支持自定义Filter；通过xDS协议对接控制面，适合深度定制化流量逻辑；支持C++（原生，需重新编译）和WASM插件 | 依赖云厂商提供的扩展能力，支持通过API对接云服务（如WAF、CDN） |
| 可观测性 | 需通过第三方工具（如Prometheus + Grafana）采集指标，需配置日志模块输出日志；分布式追踪需额外集成（如SkyWalking） | 内置监控指标（QPS、延迟、错误率），支持对接Prometheus、Grafana；集成SkyWalking、Jaeger等追踪工具；日志可自定义输出格式 | 内置监控指标，支持Prometheus、Grafana；集成阿里云ARMS监控，可自动生成监控看板；支持分布式追踪（对接SkyWalking、Jaeger）；日志集成阿里云SLS，支持实时分析 | 原生支持Metrics（内置Prometheus指标）、Tracing（对接Jaeger、Zipkin）；与Istio集成后可生成服务拓扑、遥测数据聚合；支持访问日志自定义 | 云厂商提供内置监控面板（如阿里云CLB监控），支持Metrics、日志自动采集；对接云厂商可观测平台（如ARMS、CloudWatch） |
| 社区活跃度 | 成熟，开源版更新较慢 | Apache项目，快速迭代 | 阿里开源，社区快速成长，迭代频繁 | CNCF 项目，大厂支持 | 云厂商自行维护 |
| 运维复杂度 | 低，但缺少可视化配置界面 | 中，需维护etcd | 中低，支持可视化控制台；若依赖阿里云生态，运维成本更低（云服务托管部分组件） | 高，依赖控制平面集成 | 低，全托管 |
| 适用场景 | 传统高并发场景、静态资源托管、简单反向代理与负载均衡 | 轻量级、插件化的 API 全生命周期管理、混合云环境下统一流量入口 | 云原生环境下API网关需求、依赖阿里云生态的业务、混合云统一流量治理 | 流量镜像、故障注入、跨云多集群通信等复杂流量治理，深度集成Istio服务网格 | 四层大流量高并发业务场景 |
总而言之，选型不是选最好，而是选最不折腾。核心逻辑是让网关的核心优势覆盖业务核心诉求，同时让团队运维能力能hold住网关的复杂度，与其追求功能全面，不如确保关键需求不打折，非关键需求不冗余。
专栏文章推荐：
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
