大家好，我是IT孟德，You can call me Aman(阿瞒，阿弥陀佛的ē，Not阿门的ā)，一个喜欢所有对象（热爱技术）的男人。我正在创作架构专栏，秉承ITer开源精神分享给志同道合（爱江山爱技术更爱美人）的朋友。专栏更新不求速度但求质量（曹大诗人传世作品必属精品，请脑补一下《短歌行》：对酒当歌，红颜几何？譬如媳妇，吾不嫌多...青青罗裙，一见动心，但为佳人，挂念至今...），用朴实无华、通俗易懂的图文将十六载开发和架构实战经验娓娓道来，让读者茅塞顿开、相见恨晚...如有吹牛，不吝赐教。关注wx公众号：IT孟德，一起修炼吧！
专栏文章推荐：
职场江湖：在错综复杂的人际关系中寻觅信任
离开互联网职场，我将何去何从？
告别16年IT生涯：一场关于内耗、健康和出路的反思
软件界牛马：Nginx核心原理与性能优化全攻略
架构实战：2万字真实案例全方位解析高并发系统性能优化之道
架构师指南：像呵护感情一样构建无懈可击的系统稳定性防线
系统性能评估：如何定义并发数、响应时间和吞吐量
实战：混合云架构Nginx+Lua实现流量跨机房分发
架构图的魅力：如何用UML提升架构设计的质量
为什么要做架构设计？架构设计包含哪些内容？
架构师的职责是什么？程序员如何转型为架构师？
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
流量总入口：将来自公网的用户请求通过负载均衡分发至机房内的多台Web服务器，同时通过健康检查剔除故障节点，确保服务不宕机
云服务负载均衡：公有云（如阿里云、腾讯云）中的流量网关（如 SLB、CLB）将用户请求分发至云服务器 ECS、容器实例，支持跨可用区负载均衡（如将流量分散到上海、北京两个可用区的服务器），实现服务容灾
安全网关
提供边界安全防护，包括防火墙、入侵检测/防御（IDS/IPS）、病毒过滤、VPN 加密、恶意流量拦截，保障内部网络的安全
网络层：处理IP地址和路由，执行基础防火墙策略（如IP黑白名单）
传输层：控制TCP/UDP端口访问，防止端口扫描攻击
应用层：深度解析HTTP、FTP等协议内容，防御SQL注入、跨站脚本（XSS）等应用层攻击
硬件：华为USG系列、Palo Alto PA系列、深信服NGAF系列
云服务：阿里云WAF/DDos防护产品、腾讯云WAF/DDos防护产品
金融系统：对API请求进行实时威胁检测，阻断SQL注入攻击。
远程办公：通过VPN网关加密内网访问通道
NAT网关
实现私有IP与公网IP的双向转换，解决IPv4地址资源不足问题，同时隔离内外网结构，增强网络安全性
网络层：IP地址转换
传输层：端口多路复用（PAT）涉及端口号转换
硬件：Juniper SRX 系列、Cisco ASA防火墙（支持NAT/PAT）
云服务：阿里云NAT网关、腾讯云NAT网关
本地数据中心与阿里云VPC通过双向NAT实现资源互访
家庭或办公环境私有网络（如192.168.0.0/16）中的多个设备通过一个或少量公网IP访问互联网
微服务网关
微服务架构下的通信入口，负责服务路由、负载均衡、服务发现、熔断降级，处理跨服务认证
应用层
Spring Cloud Gateway、Netflix Zuul、Kong
将用户请求路由至订单、支付、库存等微服务，并聚合结果返回客户端，服务故障时的熔断（如电商系统支付服务过载时自动降级）
API网关
管理API全生命周期、提供通用横切功能（认证、授权、限流、日志、监控）、协议转换、API版本管理与文档维护
应用层
Kong、Apisix、ShenYu
为Web、移动端、IoT设备提供统一API，将外部HTTP请求转换为内部gRPC调用
根据用户标签或版本号路由流量至新服务版本，支持金丝雀发布和AB测试
云原生网关
在传统网关（负载均衡、服务治理等）基础上，强化了对云原生场景的适配，支持K8s Ingress标准、服务网格集成、可观测性等
应用层：处理HTTP/HTTPS、gRPC、WebSocket等应用层协议
传输层：部分产品（如Envoy、APISIX）可代理TCP/UDP流量
开源：Apisix、Higress、Envoy、Istio Gateway
云服务：阿里云MSE网关、腾讯云API网关
容器化应用：作为K8s入口网关，自动发现Pod IP并实现金丝雀发布
多集群 / 多云流量调度：打通 Kubernetes 集群间或公有云 / 私有云的流量，实现跨环境服务访问
AI网关
专为AI应用设计的流量治理组件，统一代理大模型API和MCP Server，包括模型路由、请求缓存、数据防护、审计追踪、Token限流等，简化AI集成流程
应用层：适配AI特有协议，如OpenAI API
Higress（AI插件集）、Azure AI Gateway
多模型动态调度：企业同时调用多个AI服务（如客服场景需文本模型，设计场景需图像模型），网关按业务需求自动分配最优模型
成本优化：高频重复请求（如客服问候语）通过语义缓存直接返回结果，避免重复调用大模型
边缘网关
整合本地数据处理、设备接入、协议转换、边缘计算等能力，实现边缘侧与云端数据同步，降低带宽消耗，并提升本地实时响应能力
物理层与数据链路层：通过以太网、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（支持边缘节点部署与云端协同）
智能家居：整合ZigBee灯具、BLE门锁，通过MQTT协议上传至云平台。
智慧交通：路口边缘网关接入摄像头、雷达，本地运行 AI 算法识别闯红灯、拥堵等事件，即时控制信号灯，同时将统计数据同步至城市交通指挥平台
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住网关的复杂度，与其追求功能全面，不如确保关键需求不打折，非关键需求不冗余。
专栏文章推荐：
职场江湖：在错综复杂的人际关系中寻觅信任
离开互联网职场，我将何去何从？
告别16年IT生涯：一场关于内耗、健康和出路的反思
软件界牛马：Nginx核心原理与性能优化全攻略
架构实战：2万字真实案例全方位解析高并发系统性能优化之道
架构师指南：像呵护感情一样构建无懈可击的系统稳定性防线
系统性能评估：如何定义并发数、响应时间和吞吐量
实战：混合云架构Nginx+Lua实现流量跨机房分发
架构图的魅力：如何用UML提升架构设计的质量
为什么要做架构设计？架构设计包含哪些内容？
架构师的职责是什么？程序员如何转型为架构师？