网关与网格选型

• Ingress Controller 的职责
• API 网关的职责
• Service Mesh 的职责与边界

三者的职责边界按"入口治理 vs 服务间治理"以及"协议与策略深度"划分：Ingress Controller 负责 K8s 集群的南北向入口流量，把外部请求按 Ingress 规则转发到集群内 Service，主要提供 L4/L7 基本转发、TLS 终止与简单路由，是 K8s 原生入口。API 网关（Kong/APISIX/Envoy Gateway）在入口之上提供更丰富的 API 管理能力，包括限流、鉴权、Key 管理、API 聚合、灰度发布、WAF 等，面向"面向外部客户/合作伙伴的 API 出入口"。Service Mesh 负责集群内部服务间（东西向）的流量治理，提供服务级路由、mTLS、熔断、重试、可观测性等，治理对象是微服务之间的调用。边界概括：Ingress/API 网关管"入口"，Service Mesh 管"服务间"。实践中 API 网关可作为网格入口（ingress gateway）接入网格，而网格内服务间调用由 sidecar 治理。

三者是"纵深分层"的治理：Ingress 是基础入口转发，API 网关是面向外部的 API 策略层，Service Mesh 是服务间的东西向治理。划分依据是流量方向（南北/东西）与治理深度（转发/API 策略/服务治理）。理解边界才能避免重叠——入口级策略交给网关，服务间策略交给网格。

• 南北向与东西向流量的区别
• 网关与网格的治理分工
• 必须走网关的流量类型

南北向流量指外部（客户端）进入集群的入站流量，由网关（Kong/APISIX/Envoy Gateway）承担入口治理，包括域名/路由、TLS 终止、鉴权、限流、WAF 等面向外部访问的策略；东西向流量指集群内部服务之间的调用，由网格（Istio）承担服务级治理，包括 mTLS、路由、熔断、可观测性。必须走网关的流量：来自集群外部（公网/跨网络）的流量必须先经过网关，因为网关注册了对外暴露的域名与端口、承载 TLS 证书与外部访问策略，是外部访问的唯一入口；未经网关的流量无法被外部访问。内部服务间调用则走网格（sidecar），无需经过网关。边界在于：外部流量 → 网关 →（接入网格）→ 服务间 → sidecar 治理。

边界是"流量方向决定治理归属"：外部入口必走网关（安全与对外策略），内部服务间走网格（东西向治理）。当网关作为网格入口（ingress gateway）接入时，两者联成一体：网关负责入口策略，网格负责服务间策略。明确"什么流量必须走网关"是安全与架构设计的起点。

• 三者插件机制差异
• 性能特征
• 生态与选型矩阵

三者差异：Kong 基于 OpenResty/Nginx，插件用 Lua 开发，生态成熟、插件数量多、文档丰富，支持企业版与多数据库（Postgres）；APISIX 基于 OpenResty + Nginx 与 etcd 存储，插件 Lua 开发、热加载、性能高、云原生友好（与 K8s 集成好），是国产开源代表；Envoy Gateway 基于 Envoy 数据面，用 Go 实现控制面，xDS 下发配置，插件用 wasm/扩展，性能好、与网格技术栈统一，但插件生态相对较新。性能上三者都基于高性能代理，大致接近，但 Envoy Gateway 在"与网格统一数据面"上有优势。选型矩阵：按"插件生态"（Kong/APISIX 丰富）、"云原生/Script 集成"（APISIX）、"与网格统一数据面"（Envoy Gateway）、"企业支持/团队熟悉度"等维度加权。结合性能基准、团队技能、运维复杂度与生态成熟度综合打分。

三者的本质差异是"技术栈与生态侧重"：Kong 成熟稳定、APISIX 云原生高性能、Envoy Gateway 与网格统一。选型矩阵应把"插件需求、性能、云原生集成、团队能力、生态成熟度"作为维度，按场景加权，而非唯性能论。

• Ingress 的局限
• Gateway API 的分层模型
• 相比 Ingress 的优势

Ingress 的局限：规则单一、无法表达复杂的路由/策略（超时、重试、限流等）、多实现各自扩展字段不统一、南北向与东西向能力分离。Gateway API 的优势：一是分层模型，GatewayClass（定义实现）、Gateway（定义入口资源）、HTTPRoute/TCPRoute 等（定义路由规则），把"基础设施"与"业务规则"分离，便于平台与业务团队协作；二是扩展性，支持路由级策略（超时、重试、限流、金丝雀）与后端扩展，规范统一；三是可移植性，跨实现（Ingress Controller、APISIX、Envoy Gateway、Istio）遵循同一标准，避免厂商锁定；四是统一南北向与东西向流量管理，可覆盖网格场景。Gateway API 是 Ingress 的演进方向，K8s 逐步把它作为更强大、更标准的流量管理 API。

Gateway API 相比 Ingress 的核心优势是"分层、可扩展、标准化"：分层让基础设施与业务解耦，扩展性让策略表达更丰富，标准化带来可移植性。对于需要复杂路由策略与多实现统一的平台，Gateway API 是更优选择。

• 南北向与东西向流量定义
• 入口策略与服务间策略差异
• 划分依据

南北向流量（North-South）是外部客户端与集群之间的流量，治理目标是"对外提供安全、受控、可观测的入口"，包括 TLS 终止、鉴权、限流、WAF、API 密钥、路由与灰度等，通常由网关集中承担。东西向流量（East-West）是集群内部服务之间的调用，治理目标是"服务间安全、可靠、可观测"，包括 mTLS、细粒度路由、熔断、重试、分布式追踪等，通常由服务网格 sidecar 承担。划分依据：一是流量边界——外部流量在集群边界，内部流量在服务间；二是治理粒度——入口面对未知客户端需要更强的安全策略，服务间面对可信内部服务侧重可靠性与细粒度治理；三是性能与运维——入口集中在网关便于统一策略，服务间分散在 sidecar 便于粒度治理。

南北向与东西向治理的本质是"安全边界 vs 服务可靠性"的差异：入口要防外部威胁，服务间要保内部可靠。划分依据是流量边界、治理粒度与运维方式。理解这一差异，才能避免把入口安全策略强加到服务间，或把服务间治理遗漏在入口。

• 网关接入网格的方式
• ingress gateway 的机制
• 联动后的流量路径

网关作为网格入口（ingress gateway）的方式：把 API 网关/Ingress 部署为网格的 ingress gateway，即网关本身也作为网格中的特殊 sidecar（Envoy 代理），加入网格并受控制面管理。联动机制：外部流量先到达 ingress gateway（网关），网关承担入口策略（TLS 终止、鉴权、限流）；随后网关把请求转发到网格内的服务，此时网关侧 sidecar 与目标服务的 sidecar 之间建立 mTLS，并享受网格的路由、重试、可观测性。流量路径：外部 → 网关（入口策略）→ 网格服务间 mTLS 转发 → 目标服务。这样网关与网格共用同一数据面与配置体系，实现"入口策略 + 服务间治理"的统一，且单点集中管控入口、分布式治理服务间。

网关作为网格入口的关键是"让网关成为网格的一部分"，从而把南北向与东西向衔接起来。外部流量经网关处理后进入网格，服务间走 mTLS 与网格治理。联动让入口策略与服务间策略统一管理，是"网关+网格"架构的常见形态。

• 网关安全能力的层次
• WAF 与限流
• mTLS 终止与 OAuth2/JWT

网关层安全能力按"从外到内、从粗到细"分层实现：最外层是防 DDoS 与 WAF，WAF 拦截恶意请求（SQL 注入、XSS、CC 攻击等），提供基础 Web 防护；其次是限流，按 IP/用户/Key 维度限制请求速率，防止过载与刷量；再是认证与授权，mTLS 终止在网关（网关终止客户端 TLS 并校验客户端证书，或网关与后端建立 mTLS），OAuth2/JWT 验证在网关校验访问令牌（JWT 的签名、有效期、claim），把身份信息传给后端；最内层是 mTLS 到后端服务，网关与后端服务之间建立 mTLS 保证链路安全。各层在网关配置中叠加，形成纵深防御。

网关安全是"分层防御"：WAF 防攻击、限流防过载、认证授权防越权、mTLS 保链路。理解各层职责与顺序，才能正确配置——把校验放在正确的层次（如 JWT 在网关、mTLS 到后端），避免安全漏洞或性能浪费。

• 选型评估维度
• 性能基准测试
• 维度加权

选型评估框架应涵盖多个维度：性能基准（QPS、P99 延迟、并发连接、资源占用），用压测对比候选方案；功能覆盖（路由、限流、鉴权、灰度、可观测性等是否满足需求）；团队维护能力（团队是否熟悉该技术栈、能否长期维护与排障）；生态成熟度（社区活跃度、插件/文档、版本稳定性、厂商支持）；总成本（TCO，含许可证、资源、运维人力、升级成本）；云原生集成（与 K8s/CI/CD/Istio 的集成）。加权方式：按业务优先级给各维度设权重（如核心功能权重高、性能对延迟敏感场景权重高），用评分矩阵量化打分，综合对比得出最优解。不同场景权重不同——对延迟敏感选性能权重高，对维护能力弱选生态成熟度权重高。

选型评估的核心是"多维度加权 + 量化对比"，避免单一指标（如只看性能）或直觉决策。性能、功能、维护、生态、成本、云原生集成构成完整框架，按业务优先级加权。选型不是"哪个最好"，而是"哪个最匹配团队与业务"。

• 网关+网格叠加的代价
• 运维复杂度来源
• 合并统一数据面的时机

网关与网格叠加的开销：网关与网格各有代理（网关 sidecar + 服务 sidecar），请求可能经过多层代理，增加延迟与资源开销（每跳 1-5ms）；两套配置体系（网关配置 + 网格配置）带来运维复杂度，需分别管理、监控与升级，且两者策略可能重叠或冲突。何时合并为统一数据面：当网关与网格都基于 Envoy 时，可合并为统一数据面（如 Envoy Gateway 作为网格入口，或 Istio ingress gateway），共享同一套配置下发与监控体系，减少代理层数与运维负担；当网关功能（如 API 管理、插件）与网格能力完全由统一数据面覆盖，且团队维护成本过高时，适合合并。反之，若网关需要独立 API 管理能力（如 Kong/APISIX 的丰富插件）与网格解耦，则保持叠加。

网关+网格叠加是"功能分层 vs 运维成本"的权衡。叠加带来多层代理与两套配置的复杂度，当两者都基于 Envoy 且功能可由统一数据面覆盖时，合并能降低开销与运维成本。合并时机取决于功能覆盖与团队维护能力，而非一味追求统一。

• ingress gateway 集成模式
• 独立部署模式
• 两种模式的权衡

网关接入网格（ingress gateway）：网关作为网格的一部分（如 Istio ingress gateway），与网格共享控制面、配置与监控，外部流量经网关后进入网格服务间治理，实现统一管理；优点是统一数据面、一致性、运维简单，缺点是网关能力受网格限制（如插件少）。独立部署：网关（如 Kong/APISIX）独立于网格运行，拥有独立的 API 管理与插件生态，团队可独立选型与升级；优点是功能丰富、独立可控、可独立扩展，缺点是两套配置与监控、无法与网格无缝衔接。权衡：需要与网格深度集成、统一治理选 ingress gateway；需要丰富 API 管理能力、独立运维选独立部署。也可混合（网关独立、其作为网格入口接入）。

两种模式的本质是"统一治理 vs 功能独立"的权衡。ingress gateway 换统一管理牺牲部分网关功能，独立部署保功能丰富但增加运维复杂度。选型取决于对 API 管理能力的需求与运维偏好，而非绝对的优劣。

• WAF 规则配置
• 限流配置
• 防 DDoS 层次化

网关安全按层次化配置：最外层防 DDoS，通过边缘防护（如 CDN/云 WAF）或网关的请求速率/连接数限制，抵御流量攻击（SYN 洪泛、CC 攻击），保护网关本体；第二层 WAF，通过 WAF 规则库拦截应用层攻击（SQL 注入、XSS、路径穿越、命令注入等），对请求内容做检测与拦截；第三层限流，按 IP/用户/Key/接口维度设置限流阈值，防止单一来源打爆或业务刷量；最后一层是业务鉴权与授权。层次化思路：先挡流量放大攻击（DDoS）、再拦截应用攻击（WAF）、再做速率控制（限流）、最后做业务级访问控制。各层配置叠加形成纵深防御。

网关安全是"从攻击类型到防御层次"的纵深防御：DDoS 防资源耗尽、WAF 防应用漏洞、限流防滥用、鉴权防越权。层次化配置保证每层各司其职，避免单一安全能力不足。配置时按威胁类型与防护目标分层叠加。

• 性能测试指标
• 压测方法
• 资源配比评估

网关性能测试基准方法：一是指标选取，关注 QPS（吞吐）、并发连接数、延迟分布（P50/P95/P99）、错误率与资源占用（CPU/内存）；二是压测方法，用压测工具（wrk、hey、k6、JMeter）模拟真实流量，分梯度（如 100/500/1000/5000 QPS）逐步加压，找到吞吐瓶颈与 P99 拐点；三是场景设计，覆盖纯转发、TLS 终止、限流、鉴权等不同处理路径，评估各功能对性能的影响；四是资源配比，观察在目标 QPS 下 CPU/内存/连接数的使用，确定每实例的资源配比与集群规模，评估水平扩展能力。输出基准报告：各 QPS 下的延迟分布、最大吞吐、资源占用与扩展性，用于容量规划与选型对比。

性能测试的关键是"贴合真实场景 + 关注尾延迟"。用梯度压测找到吞吐与延迟拐点，用 P99 评估真实体验，用资源占用做容量规划。同一网关在不同功能（TLS/限流/鉴权）下性能差异大，需按实际路径测。

• Kong/APISIX 插件体系
• Lua 扩展
• Wasm 扩展

Kong/APISIX 的插件体系：两者都基于 OpenResty/Nginx，插件用 Lua 开发，通过插件机制在请求生命周期各阶段（rewrite、access、header_filter、body_filter、log）注入逻辑，实现限流、鉴权、转换、日志等；插件可热加载、按服务/路由/消费者绑定。Lua 扩展：开发简单、无需编译、执行于 Nginx 进程内，性能较好，适合大部分插件逻辑；但需注意 Lua 代码质量与 Nginx 环境限制。Wasm 扩展：把插件编译为 Wasm 字节码，在沙箱中运行，跨语言、隔离性好、可热更新，但集成与性能开销相对 Lua 大，生态相对新。差异：Lua 开发便捷、生态成熟；Wasm 隔离性好、跨语言，但开发复杂。选型：常规插件用 Lua，需要隔离/跨语言/安全性要求高时用 Wasm。

插件体系是网关可扩展性的核心，Lua 与 Wasm 是两种扩展方式。Lua 是主流（开发快、生态成熟），Wasm 是增强（隔离、跨语言）。理解"请求阶段注入 + Lua/Wasm 扩展"机制，才能按需开发与选择网关插件。

• 配置管理（声明式/版本化）
• 灰度发布
• 监控告警

网关运维标准化：一是配置管理，把网关配置纳入 GitOps/声明式管理（如 Kong 的 declarative config、APISIX 的 etcd、Envoy Gateway 的 K8s CRD），版本化、可审计、可回滚，避免手改导致漂移；二是灰度发布，网关升级采用灰度（先小流量验证再全量），配置变更用金丝雀/AB 验证，配合健康检查与回滚，保证发布安全；三是监控告警，建立网关核心指标（QPS、P99 延迟、错误率、连接数、CPU/内存）的监控与告警，关联已有可观测体系（Prometheus/Grafana），设置合理阈值（如 5xx 比例、P99 超阈值）触发告警，并有对应应急预案。标准化目标是让网关运维可重复、可审计、可回滚。

网关运维标准化是"声明式配置 + 灰度发布 + 监控告警"三位一体。配置版本化保证可审计可回滚，灰度发布保证变更安全，监控告警保证可观测可发现。标准化能降低网关变更风险与人工运维成本。

• 性能维度
• 插件生态
• 配置管理与云原生集成

网关选型关键维度：性能——用压测对比 QPS、P99 延迟与资源占用，选择匹配吞吐与延迟要求的方案；插件生态——评价插件数量、质量、可扩展性（Lua/Wasm），是否满足限流、鉴权、WAF、转换等需求及二次开发能力；配置管理——对比声明式/版本化配置、热更新、审计与回滚能力，是否支持 GitOps/声明式管理；云原生集成——评价与 K8s（Gateway API、CRD）、Service Mesh（能否接入网格）、CI/CD、可观测体系（Prometheus/OTel）的集成程度。对比方法：按业务优先级对性能、插件、配置、云原生集成加权，结合团队熟悉度与生态成熟度做综合评估。不同场景侧重不同——对延迟敏感重性能，对定制需求重插件，对云原生重集成。

网关选型是"性能、插件、配置、云原生"多维对比，按业务优先级加权。性能决定能否承载流量，插件决定功能覆盖，配置管理决定运维效率，云原生集成决定生态协同。综合加权才能选出最匹配的方案。

• 多副本部署
• 健康检查
• 连接排空与故障转移

网关高可用：多副本部署——网关多实例部署（K8s 多副本），配合负载均衡器/SLB 分发流量，避免单点；健康检查——网关暴露健康检查端点（如 /healthz、/ready），K8s 的 liveness/readiness 探针或 LB 定时检查，感知实例故障；连接排空——关闭/升级实例时，通过 readiness 降级（从 LB 摘除）与优雅关闭（drain），让在途请求完成后再退出，避免连接被切断；故障转移——某个实例故障时，LB 把流量转移到健康实例，K8s 重建故障 Pod，实现自动恢复。故障转移流程：健康检查发现实例不可用 → 从 LB 摘除 → 流量转移到健康实例 → 重建新实例 → 重新加入。配合 PodDisruptionBudget 保证升级时可用副本数。

网关高可用是"副本冗余 + 健康检查 + 连接排空"的协同：多副本保证冗余，健康检查感知故障，排空保证平滑切换。故障转移流程是"检测→摘除→转移→重建"，配合优雅关闭避免连接中断。这是网关可用的基础保障。

• 三者数据面差异
• 多集群能力
• 生态差异

三者差异：数据面——Istio 用 Envoy 作数据面，功能全面（路由、mTLS、Wasm、丰富策略），但 Sidecar 资源开销大；Linkerd 用自研轻量代理，资源开销小、性能好、部署简单，但功能较 Istio 少（侧重 L7 基础治理）；Consul 用内置 Envoy 数据面（支持无代理模式），与 Consul 的服务发现/注册深度集成，侧重服务发现与配置。多集群——Istio 支持多主/单主/多网络架构，多集群能力最强；Linkerd 支持多集群但功能较简单；Consul 支持多集群与跨数据中心（结合 Consul 本身）。生态——Istio 生态最丰富、与 K8s 深度集成、社区大；Linkerd 轻量、社区活跃、易上手；Consul 生态涵盖注册中心、配置、多数据中心，适合与 Consul 生态结合的企业。选型：功能全面、多集群复杂选 Istio；轻量简单、资源敏感选 Linkerd；与 Consul 注册/配置生态结合选 Consul。

三者是"功能全面度 vs 轻量简单"的谱系：Istio 功能最全但重、Linkerd 轻量但功能少、Consul 侧重服务发现与配置。选型取决于对功能深度、资源开销、多集群复杂性与生态结合的需求。

• 自研网关的优劣
• 开源网关的优劣
• 决策框架

自研网关：可完全定制、满足特定性能/协议/安全需求、无厂商依赖，但需投入大量开发与维护成本，性能与稳定性难达成熟产品，社区生态缺失。开源网关（Kong/APISIX/Envoy Gateway 等）：功能成熟、生态丰富、迭代快、二次开发灵活，但需适应其架构与升级节奏，深度定制受限。决策框架：从性能需求（是否开源方案无法满足的极端性能/协议）、扩展需求（是否开源插件无法覆盖的定制）、团队能力（是否有足够团队维护自研）、生态依赖（是否依赖社区插件与文档）、成本（开发维护 vs 许可证）五维度权衡。原则：除非有独特且开源无法满足的需求（极端性能、特有协议、强安全定制），且团队有能力长期维护，否则优先开源并二次开发。避免重复造轮子。

自研 vs 开源的决策本质是"定制灵活性 vs 成本与生态"的权衡。开源方案通常已满足 90% 需求，自研仅在需求独特且团队有能力维护时合理。决策框架强调"能复用开源就不自研"，把自研资源聚焦在开源无法覆盖的差异化能力上。