负载均衡与高可用代理、动态路由与数据中心网络

• Envoy RBAC filter 基于 source/destination 与权限做允许/拒绝
• 语法：principal（主体）+ permissions（权限）
• 结合 header/连接/元数据匹配

Envoy 的 RBAC 过滤器（envoy.filters.http.rbac 或 network.rbac）基于"主体（principal）+ 权限（permissions）"做访问控制。规则定义某主体（如特定 IP、下游连接、header、metadata）是否拥有某权限（如访问特定路径、方法、端口）。匹配条件可基于 source IP、header、path、method、连接元数据。允许矩阵（permissive）或拒绝矩阵（deny）语义。它常用于服务网格：在 sidecar 上给服务配置访问控制（如只允许特定来源访问某 /admin 路径），实现零信任的细粒度授权。配置在 Envoy 的 filter 中声明 rules，与认证（JWT auth）配合。

Envoy RBAC 的核心是"主体+权限"的规则引擎，支持 source/destination/header 匹配。它把访问控制下沉到 L4/L7 代理，实现服务间授权。

• ext_authz 把请求发给外部授权服务（gRPC/HTTP）
• 授权服务返回 allow/deny
• 传递请求元数据、header、body 给授权服务

Envoy 的 ext_authz（外部授权）过滤器把请求转发给外部授权服务（如 OPA、自研鉴权服务），由该服务决定允许或拒绝。授权服务通过 gRPC 或 HTTP 接口接收请求上下文（path、method、header、可选 body），返回 allow/deny 及允许修改的 header。Envoy 根据结果放行或拒绝（403/401）。它支持缓存、超时、失败模式（fail open/closed）。与 RBAC 的差异：RBAC 是 Envoy 内置规则，ext_authz 是外部可编程服务，适合复杂/动态策略。常用于服务网格的集中鉴权、与 OPA 集成。

ext_authz 把"决策"外包给外部服务，Envoy 只做"执行"。它支持 gRPC/HTTP、可编程策略，是集中式鉴权的标准做法。

• roundrobin 轮询，适合同质请求
• leastconn 最少连接，适合长连接/负载不均
• source 按源 IP 哈希，适合会话保持

HAProxy 的负载均衡算法：roundrobin 把请求轮流分给各后端，简单均匀，适合处理时间相近的请求（动态调整权重）。leastconn 分给当前连接最少的后端，适合长连接（如 WebSocket、数据库连接）或请求耗时不均，避免连接堆积。source 按源 IP 哈希，同一源 IP 固定到同一后端，用于会话保持（无 cookie 场景）。uri 按 URI 哈希，同一 URI 固定到同一后端，适合缓存/一致性（如后端缓存）。还有 first、random 等。选型：同质短请求用 roundrobin，长连接用 leastconn，会话保持用 source，缓存一致性用 uri。

算法选择取决于"连接特性与一致性需求"。轮询均匀、leastconn 抗长连接、source/uri 提供一致性哈希。

• L4 基于 IP/端口转发，性能高、功能少
• L7 基于 HTTP 内容路由，功能强、开销大
• 取舍：吞吐 vs 路由/粘性/健康检查

L4 负载均衡（如 LVS、NLB）基于 IP/端口/四元组转发，不解析应用层，性能高（吞吐大、延迟低）、改造成本小，但功能有限（不能按 URL/Host 路由、不能做 HTTP 头处理）。L7 负载均衡（如 Nginx、ALB、Envoy）解析 HTTP/HTTPS，支持按 URL、Host、header 路由、粘性会话、内容缓存、TLS 终止、细粒度健康检查，功能强，但需解析与处理应用层，CPU 开销大、吞吐略低。取舍：高吞吐、纯 L4 场景用 L4；需要应用层路由、高级功能用 L7。实践中常 L4 前置挡流量、L7 做路由。

取舍核心是"功能 vs 性能"。L4 快但粗，L7 细但贵。选型看是否需要应用层路由与高级功能。

• NAT：双向都经过 Director，需改写 IP 与端口
• DR：请求到 Director，响应直接回客户端（回程不经 Director）
• TUN：隧道封装，支持跨网段

LVS 三种模式：① NAT——Director 改写请求的目标 IP/端口为后端，响应也经 Director 改写回源，双向都走 Director，后端只需指向 Director 的网关，改造简单但 Director 是瓶颈；② DR（直接路由）——Director 只改目标 MAC 转发请求，后端直接回包给客户端（回程不经 Director），吞吐高，但后端需把 VIP 绑定到 lo 接口并抑制 ARP，改造要求高；③ TUN——Director 用 IP 隧道封装请求到后端，后端解封后直接回包，支持跨网段/异地，后端需配置隧道接口。回程路径：NAT 必回 Director，DR/TUN 后端直接回客户端。改造要求：NAT 低、DR 需 lo 绑定 VIP + 抑制 ARP、TUN 需隧道接口。

三模式差异集中在"回程是否经 Director"与"后端改造"。NAT 双向经 Director、DR 回程直连、TUN 跨网段，DR 是高性能常用。

• listen 指令加 http2 参数启用 HTTP/2
• 需要 TLS（HTTP/2 主要在 HTTPS）
• ALPN 协商、多路复用、头部压缩

Nginx 启用 HTTP/2 在 listen 指令加 http2 参数：listen 443 ssl http2;。HTTP/2 基于 TLS（通过 ALPN 协商 h2），支持多路复用（单连接多流）、头部压缩（HPACK）、服务端优先级等。Nginx 编译时需含 http_ssl_module 与 http_v2_module。启用后客户端通过 ALPN 协商 h2，失败则回落 http/1.1。Nginx 的 http2 模块在多路复用与头部压缩上做优化，但 Nginx 的多路复用是"单连接串行处理"（非全并发），需注意配置 http2_max_concurrent_streams 等。升级到 HTTP/2 减少连接数，降低握手开销。

Nginx 的 http2 是"listen 加参数 + ALPN 协商"。HTTP/2 主要在 HTTPS 下，多路复用减少连接。注意 Nginx 的 h2 实现是串行处理。

• proxy_connect_timeout 设置与上游建立 TCP 连接的超时
• 默认 60s，影响连接建立阶段
• 与 read/send 超时区分

proxy_connect_timeout 定义 Nginx 与上游服务器建立 TCP 连接的超时时间（默认 60 秒）。它只作用于"建立连接"阶段，若该时间内未完成 TCP 握手则报 504/超时。与 proxy_read_timeout（两次读操作间隔）和 proxy_send_timeout（两次写操作间隔）不同。配置 proxy_connect_timeout 5s; 可缩短连接失败等待。排障：若频繁 connect 超时，检查上游主机是否可达、端口是否监听、防火墙是否拦截、半连接队列是否满。它通常放在 location 或 server 块，作用于所有上游请求。

proxy_connect_timeout 管"建连"阶段，超时报错。它需与 read/send 区分，建连超时多因上游不可达或端口不通。

• proxy_send_timeout 设置向上游发送请求的超时
• 指两次写操作之间的间隔超时
• 排查：上游处理慢、请求体大、背压

proxy_send_timeout 定义 Nginx 向上游发送请求（写）的超时，表示"两次写操作之间的最大间隔"，默认 60s。若上游迟迟不读数据（如慢消费者、背压），Nginx 写超时。配置 proxy_send_timeout 30s;。排查上游写超时：上游应用处理慢、请求体过大、上游 socket 缓冲满（背压）、网络拥塞。它与 proxy_read_timeout（读响应超时）对应，写是"发请求"，读是"收响应"。写超时常见于上传大文件或上游不消费。调大需结合业务，避免掩盖上游问题。

proxy_send_timeout 是"发送请求的间隔超时"，写超时反映上游消费慢或背压。与 read_timeout 成对，是"超时三件套"之一。

• sticky session 把请求固定到同一后端
• cookie 注入（服务端生成 cookie）vs cookie 插入（LB 改写）
• 健康检查/后端排空影响会话

sticky session 让同一用户的请求固定到同一后端，保证会话状态（如登录态）不丢。Nginx 的 sticky 指令（cookie 注入：LB 生成并下发 cookie）、HAProxy 的 cookie 指令（cookie 插入：把后端名写入 cookie）、或 ip_hash。失效导致登录态丢失的排查：① 检查 cookie 是否被注入/插入且正确（Domain/Path 匹配）；② 后端重启/扩容导致会话数据丢失（会话未集中存储）；③ 健康检查/排空导致连接被切到其他后端，会话不共享则丢；④ cookie 被清除或超时。排查应确认会话是否在负载均衡层保持、后端会话是否共享（分布式会话/Redis）、后端排空是否影响。

会话保持失效的核心是"会话是否被固定且有共享存储"。cookie 注入 vs 插入是"LB 生成 vs 改写"，后端排空/健康检查会切走连接。

• BGP 选路顺序：WEIGHT→LOCAL_PREF→AS_PATH→ORIGIN→MED 等
• 各属性控制入站/出站流量
• 出站用 LOCAL_PREF/AS_PATH，入站用 MED/AS-PATH prepend

BGP 选路按属性优先级依次比较：WEIGHT（本地最高，Cisco）→ LOCAL_PREF（出站本地偏好）→ AS_PATH 长度（越短越优）→ ORIGIN（IGP<EGP<INCOMPLETE）→ MED（入站偏好，越小越优）→ eBGP/iBGP、下一跳、路由来源等。流量工程应用：控制出站流量用 LOCAL_PREF（调整首选路径）或 AS_PATH prepend（加长路径让入站流量少走）；控制入站流量用 MED（对等方按 MED 选路）或 AS path prepend（向对端宣告加长路径，使入站流量走其他路径）。inbound 方向（流进本 AS）用 MED/AS-path prepend，outbound 方向（本 AS 流出）用 LOCAL_PREF/本地权重。

选路核心是"出站被本地属性控制，入站被对端看到的属性控制"。LOCAL_PREF 管出站，MED/prepend 管入站，是流量工程的关键。

• eBGP 默认单跳（TTL=1），iBGP 默认多跳
• iBGP 用 loopback 建邻居（稳定）
• eBGP 多跳需显式配置 multihop

eBGP 默认只与直连对端建立邻居（TTL=1），跨多跳需显式配置 ebgp-multihop；iBGP 默认多跳，常用 loopback 地址建立邻居以保证稳定性（loopback 不随物理接口 down 而失效）。iBGP 的 loopback 邻居需配置 update-source 与可达路由。TTL 安全机制：neighbor x ttl-security hops N 限制对端 TTL 不小于期望值，防止远端伪造的 BGP 包（TTL 太小的包被丢弃）。eBGP 单跳天然 TTL=1，iBGP 多跳需 ttl-security 约束。eBGP 与 iBGP 的差异还包括：eBGP 有 AS_PATH 追跳、下一跳处理、iBGP 需全互联或路由反射器。

差异核心是"多跳 vs 单跳"与"邻居建立方式"。iBGP 用 loopback 稳定建邻居，eBGP 多跳需显式 + ttl-security 防伪造。

• iBGP 全互联限制，RR 减少连接数
• RR 层次化部署、单点风险
• 联邦划分 AS 减少连接

iBGP 要求全互联（n 台需 n(n-1)/2 连接），大网络不可行。路由反射器（RR）让指定路由器反射路由给其他 iBGP 对等，减少连接数，但 RR 是单点（RR 故障则反射中断），需层次化部署（多个 RR 互为备份、每个反射器服务一组客户端）。联邦（Confederation）把大 AS 划分为多个子 AS，内部子 AS 间用 iBGP 类连接，子 AS 间用 eBGP 类连接，减少全互联连接数，但配置复杂。取舍：RR 简单、层次化、扩展性好，主流；联邦配置复杂、较少用。大规模 IDC 以 RR 为主，做多级 RR 与冗余，避免单点。

取舍是"RR 简单主流 vs 联邦复杂"。RR 减少连接但有单点风险，需层次化 + 冗余；联邦划分 AS 但配置复杂。

• Cilium 基于 eBPF 的 ingress 控制器
• 用 IngressClass 与 Gateway API
• eBPF 处理 L4/L7 转发，性能高

Cilium ingress 用 eBPF 实现高性能的 K8s 入口，处理 L4/L7 流量转发。它通过 IngressClass 声明启用 Cilium ingress controller，或用 Gateway API（GatewayClass）配置。Cilium 的 dataplane 用 eBPF 在内核完成转发，相比传统 Nginx 代理 CPU 开销低、吞吐高。它支持 TLS 终止、HTTP 路由、重写、与服务网格（Cilium 的 L7 策略）集成。部署：安装 Cilium 并启用 ingress 特性，创建 IngressClass 指向 cilium，Ingress 资源即被 Cilium 处理。适合需要高性能 eBPF 数据面与精细网络策略的 K8s 集群。

Cilium ingress 的价值是"eBPF 数据面高吞吐 + IngressClass/Gateway API 声明式入口"。它把 LB 与网络策略下沉到内核。

• VXLAN 用 VNI 隔离多租户大二层
• VTEP 负责封装/解封装
• BGP EVPN 控制平面分发 MAC/IP

EVPN/VXLAN 实现大二层与多租户隔离：VXLAN 用 VNI（24 位）标识虚拟网络，不同 VNI 隔离不同租户的大二层。VTEP（VXLAN Tunnel Endpoint）负责把二层帧封装成 UDP 报文发送到对端 VTEP。控制平面用 BGP EVPN 分发 MAC/IP 学习结果，避免传统 flood-and-learn 的洪泛。BGP EVPN 的 Type-2 路由携带 MAC/IP 地址（主机路由），Type-5 路由携带 IP 前缀（网段路由），用于跨网段/互联。VNI 与 VRF 绑定实现多租户隔离，EVPN 提供分布式网关与多租户路由。它让数据中心支持大二层迁移与多租户隔离。

VXLAN 管"数据面封装（VNI 隔离）"，EVPN 管"控制面分发（MAC/IP 学习）"。Type-2/Type-5 分别承载主机与网段路由。

• ring hash 用一致性哈希（一致性环）分配请求
• 基于 hash key（header/cookie/源 IP）哈希
• 最小化节点变化的 rehash

Envoy 的 ring hash 实现一致性哈希负载均衡：把后端节点映射到哈希环（0-2^64 空间），每个请求按 hash key（如 header、cookie、源 IP、URL）计算哈希值，落在环上顺时针找到第一个节点，从而同一 key 固定到同一节点。一致性哈希的优点：节点增删时只影响环上相邻节点，rehash 最小化，适合缓存与需要稳定映射的场景。Envoy 用虚拟节点（vnode，默认 1024）把节点均匀分布到环上，避免哈希倾斜。consistent_hash 配合 hash_policy 指定 hash key（如 header、cookie）。常用于会话保持、缓存亲和。

ring hash 的核心是"一致性环 + 虚拟节点"。节点变化时 rehash 最小，适合缓存与稳定映射。hash_policy 决定 key。

• stick-table 存储每 key 的计数/状态
• 粘性会话：按源 IP 等固定后端
• 限流/防 CC：sticky 计数触发

HAProxy 的 stick-table 是内存键值表，可按 key（源 IP、cookie、header）存储计数与状态。粘性会话：用 stick-table type ip size 1m + stick on src 把同一源 IP 固定到同一后端（无需 cookie）。限流/防 CC：stick-table type ip size 1m store http_req_rate(10s) 按源 IP 统计请求速率，配合 tcp-request connection track-sc0 计数，超限则 sc0-inc-gpc0 标记并拒绝。与后端 cookie 注入取舍：cookie 注入（cookie NAME insert）把会话绑定到后端，适合真实会话保持；stick-table 按源 IP 简单但可能受 NAT 影响、且占用内存。限流/防 CC 是 stick-table 的强项，cookie 注入主要用于会话保持。

stick-table 是"内存计数 + 状态表"，既能做粘性会话也能做限流/防 CC。cookie 注入专注会话保持，stick-table 更通用。

• Kiali 展示服务拓扑、调用关系、健康状态
• 基于 Prometheus 指标与 Istio 遥测
• 展示服务/工作负载/应用的健康与错误率

Kiali 是 Istio 服务网格的可视化控制台，展示服务拓扑图（服务、工作负载、实例之间的调用关系）、健康状况（健康/降级/异常）、错误率、延迟、流量分布。它从 Prometheus 拉取 Istio 遥测指标（p99 延迟、错误率、请求量），从 Kubernetes API 获取服务与工作负载信息，生成图形化拓扑。健康状态基于错误率与可用性判定（如错误率超阈值标红）。Kiali 还支持查看 service graph、应用详情、配置 Istio 路由、追踪（Jaeger）集成。排障时用 Kiali 看调用链、定位故障服务与依赖。

Kiali 的价值是"把服务网格的调用关系与健康可视化为拓扑图"。数据来自 Prometheus 指标与 K8s，健康基于错误率/可用性。

• Gateway CRD 定义入口监听器（端口/协议/域名）
• 与 VirtualService 绑定路由
• ingressgateway 作为入口代理

Istio 的 Gateway CRD 声明入口监听器：定义端口、协议（HTTP/TCP/TLS）、TLS 配置、与 host 的 selector。它本身只定义"监听"，流量路由由 VirtualService 通过 gateways 字段绑定。实际承载流量的是 ingressgateway 组件（部署的 Envoy 代理，selector 匹配）。例如创建一个监听 80 端口、selector 指向 ingressgateway 的 Gateway，再在 VirtualService 中 gateways: [my-gateway] 定义 host 与路由规则。这样入口流量经 ingressgateway 按 VirtualService 路由到服务。Gateway CRD 是声明式入口配置的基础。

Gateway 定义"监听"，VirtualService 定义"路由"，ingressgateway 是运行载体。二者结合实现声明式入口。

• keepalived 的 LVS 健康检查（HTTP/TCP 探测）
• 故障节点自动剔除、恢复自动加入
• 权重与 real_server 配置

LVS 的 real server 健康检查通常由 keepalived 承担。在 keepalived 的 LVS 配置段，为每个 real_server 定义健康检查（TCP_CHECK、HTTP_GET、MISC_CHECK）：TCP_CHECK 探测端口连通性，HTTP_GET 请求 URL 检查 HTTP 状态码，MISC_CHECK 执行脚本。健康检查失败时 keepalived 把该 real server 从转发池剔除（weight 置 0），恢复后自动加入。配置 weight 控制负载权重，connect_timeout/retry 控制探测。故障节点剔除后 LVS 不再向其转发，实现高可用。

LVS 本身不健康检查，靠 keepalived 的探针（TCP/HTTP/MISC）做检测与剔除。故障剔除、恢复加入实现自动高可用。

• Unit 是通用 Web 应用服务器，支持多语言（PHP/Node/Python/Go）
• 用 JSON 配置应用与路由
• 动态重载、进程管理

NGINX Unit 是轻量级通用应用服务器，支持 PHP、Node.js、Python、Go、Java、Ruby 等语言，用 JSON 配置声明应用与路由。配置：{ "listeners": { "127.0.0.1:8080": { "pass": "applications/php" } }, "applications": { "php": { "type": "php", "root": "/var/www", "processes": 4 } } }。通过 HTTP API 或配置文件动态更新，无需重启。它管理应用进程（进程数、并发），替代语言专用的 Web 服务器（如 php-fpm、uwsgi）。与 Nginx 的差异：Nginx 是静态/反代，Unit 是应用运行时与动态应用服务器。多语言统一用 Unit 部署。

Unit 的核心是"JSON 声明 + 多语言 + 动态重载"。它统一管理各语言应用进程，替代 ad-hoc 的进程管理器。

• auth_basic 开启 Basic 认证，auth_basic_user_file 指定密码文件
• htpasswd 生成密码文件
• 作用范围（location/server）

Nginx 用 auth_basic 与 auth_basic_user_file 配置 HTTP Basic 认证：auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd;。密码文件用 htpasswd -c /etc/nginx/.htpasswd user 生成（含哈希）。浏览器访问时弹凭据框，凭据放 Authorization 头，Nginx 校验。作用范围可放在 server 或 location，实现限定的 Basic 认证。结合 HTTPS 使用（Basic 明文 base64，必须 TLS 加密）。常用于内部管理页面、API 的简单保护。

auth_basic 是 Nginx 内建 Basic 认证，靠 htpasswd 文件存储凭据。因 Basic 明文，必须配 HTTPS。

• Stub 区域禁外部路由，用默认路由
• NSSA 允许外部路由（Type-7）
• Totally Stub 禁外部和区域间路由

OSPF 区域类型：① Stub 区域——禁外部（AS 外部）路由，只有区域内部 + 默认路由，减少路由表；② NSSA（Not-So-Stubby）——像 Stub 但允许引入外部路由（用 Type-7 LSA 转换），适合区域接外部 AS；③ Totally Stub——禁外部路由且禁区域间路由，只保留区域内 + 默认路由，最精简。骨干区域（Area 0）设计原则：所有非骨干区域必须与 Area 0 相连（或经虚链路），Area 0 承载区域间路由，负责汇聚，需高可用与冗余。区域划分减少路由与 LSA 洪泛，但骨干必须可靠。

区域类型差异在"是否允许外部/区域间路由"。Stub 禁外部，NSSA 允许外部，Totally Stub 全禁。骨干 Area 0 必须连通所有区域。

• MTU 不匹配导致 DBD 交换失败
• Hello/Dead 计时器不一致致邻居闪断
• 区域 ID 错误、认证失败

OSPF 邻居卡在 ExStart/Exchange 状态（DD 报文交换阶段）的常见原因：① MTU 不匹配——双方接口 MTU 不一致，DBD 报文过大被丢弃，邻居无法完成交换；② Hello/Dead 计时器不一致——计时器不同步导致邻居反复建立/断开；③ 区域 ID 错误——邻居属于不同区域，无法建立；④ 认证失败——认证类型/密钥不匹配，hello 被丢弃。排障：show ip ospf neighbor 看状态，show ip ospf interface 看 MTU/计时器/区域，debug ip ospf 看错误。MTU 不匹配是 ExStart/Exchange 卡住的典型原因。

邻居卡在 ExStart/Exchange 重点查 MTU 与 DBD 交换。MTU 不匹配、计时器、区域、认证是四位常见根因。

• Traefik 的 accessLog 配置（文件/字段/格式）
• 日志转发、过滤、脱敏
• 错误日志（log level）

Traefik 的访问日志通过 accessLog 配置：[accessLog] filePath = "/var/log/traefik/access.log"，可指定 fields（request/response 字段）、filters（过滤状态码/复杂度）、format（common/json）。错误日志用 [log] level = "INFO" 控制级别（DEBUG/INFO/WARN/ERROR），filePath 指定文件。在 K8s 中通常用 IngressRoute 注解或静态配置。访问日志可配 buffering 与脱敏（如隐藏 Authorization 头）。日志用于排障访问与错误。

Traefik 日志分"访问日志（accessLog）"与"运行日志（log level）"。accessLog 记录请求，log 记录运行，两者分开配置。

• k8s provider watch K8s 资源（Ingress/IngressRoute）生成路由
• 自动发现 Service 与 Endpoint
• IngressRoute CRD 声明路由

Traefik 的 k8s provider 通过 watch Kubernetes API 的 Ingress、IngressRoute、Service 等资源，自动生成路由配置。它监听 Ingress 或 CRD（IngressRoute）的创建/更新，把 host 与路径映射到 Service 的后端，并跟踪 Endpoint 变化实现动态后端。配置 [providers.kubernetesIngress] 或 [providers.kubernetesCRD] 启用。端点变化时 Traefik 动态更新无需重启。IngressRoute 是 Traefik 的 CRD，支持中间件、TLS、权重等高级路由。健康检查自动剔除故障后端。

k8s provider 是"事件驱动 + 自动路由"。它 watch K8s 资源生成路由，Ingress/IngressRoute 是声明源，Endpoint 变化动态更新。

• flood-and-learn 靠洪泛学习 MAC，简单但扩展差
• EVPN 用 BGP 控制面分发 MAC/IP，可控
• 大规模/多租户/跨站点选 EVPN

VXLAN 的 flood-and-learn 依赖数据面洪泛（BUM 广播）学习 MAC，配置简单、适合小规模，但洪泛消耗带宽、学习慢、扩展性差、多租户隔离弱。BGP EVPN 用控制平面（BGP）分发 MAC/IP 路由，VTEP 通过 EVPN 路由学习对端主机，避免洪泛，支持多租户（VNI+VRF）、分布式网关、快速收敛、跨站点。迁移时机：大规模二层、多租户隔离要求高、跨数据中心/多站点、需要快速收敛与流量优化时，应从 flood-and-learn 迁移到 BGP EVPN。小规模单机房可继续用 flood-and-learn。

差异是"数据面洪泛 vs 控制面分发"。洪泛简单但扩展差，EVPN 可控可扩展。规模/多租户/跨站点是迁移触发点。

• anycast 多个节点宣告同一 IP，就近路由
• BGP 宣告策略、健康检查、流量回撤
• 用于 DNS/CDN 就近接入

anycast 让多个节点用 BGP 宣告同一 IP 前缀，路由器按最短路径把流量路由到最近节点，实现就近接入与容灾。落地要点：① 宣告策略——各节点宣告同一前缀，用 AS path prepend/本地优先级控制流量分配；② 健康检查——节点故障时（服务不可用）从 BGP 撤回宣告（withdraw），使流量路由到健康节点；③ 流量回撤——通过撤回宣告或降低优先级，把流量从故障/过载节点切走。用于 DNS anycast（全球多节点解析同一 IP）、CDN 就近接入。注意 anycast 的会话保持（TCP 连接可能跨节点）与 BGP 收敛时间。

anycast 核心是"多节点宣告同一 IP + 就近路由 + 按健康撤回"。宣告策略与控制流量，撤回实现故障切换。

• VRRP 主备通过虚拟 IP 与优先级切换
• 抢占模式（nopreempt）与优先级
• 认证（AH/PASS）防伪造

keepalived 用 VRRP 实现主备切换：多台机器运行 VRRP，优先级高的成为 MASTER 持有虚拟 IP（VIP），故障时 BACKUP 接管。关键配置：priority（优先级，越大越优）、nopreempt（非抢占，避免抖动）、authentication（认证，PASS 明文/AH 加密，防伪造 VRRP 包）、virtual_ipaddress（VIP）。抢占模式：默认抢占，主恢复后收回 VIP；非抢占避免频繁切换。脑裂防护：VRRP 通过心跳（multicast/unicast）检测，若主备选路/心跳异常可能双主（脑裂），需靠冗余链路、合理计时器、外部一致性检查（如脚本检测 VIP 冲突）。排障看 keepalived 日志与 ip addr 验证 VIP 归属。

VRRP 核心是"优先级定主备 + 心跳切换 + 认证防伪造"。抢占 vs 非抢占权衡抖动，脑裂靠冗余与一致性检测防。

• Spine-Leaf 全互联，ECMP 多路径负载均衡
• ECMP 基于哈希把流量分布到多条路径
• LAG 聚合多条链路为一条逻辑链路

Spine-Leaf 架构中每个 Leaf 与所有 Spine 相连，形成多条等价路径，ECMP（Equal-Cost Multi-Path）基于哈希把流量分布到多条路径，实现高带宽与负载均衡与冗余。ECMP 的哈希通常基于五元组（src/dst IP、端口、协议），保证同一流走同一路径。链路聚合（LAG）把多条物理链路捆绑为一条逻辑链路，增加带宽与冗余；MLAG（跨设备链路聚合）让两台设备上的聚合口作为一个逻辑口，实现无环。互补：ECMP 在"路径级"分担（多 Spine 多 Leaf），LAG/MLAG 在"链路级"聚合（Leaf 到 Spine 的多条物理链路），两者结合：同一 Leaf 到 Spine 用 LAG 聚合链路，Leaf 之间用 ECMP 多路径转发。

ECMP 是"路径级负载均衡"，LAG/MLAG 是"链路级聚合"。两者一个管跨路径分担、一个管单链路聚合，互补提升带宽与冗余。

• drain：停止新连接、等待存量连接完成
• 连接排空超时、graceful shutdown
• 健康检查/权重调整配合

后端排空（drain）是在后端下线/发布前，先停止接收新连接，让存量连接处理完（超时内）再断开，避免请求中断。流程：① 把后端从健康检查/转发池摘除（置 weight 0 或标记 drain），不再发新请求；② 等待存量连接在排空窗口内完成（connection draining 超时，如 30-300s）；③ 超时后强断未完成连接。负载均衡（Nginx/HAProxy/AWS ALB）支持 drain 配置：HAProxy 的 option graceful 与 drain 后端状态，AWS ALB 的 ConnectionDraining/deregistration_delay。发布/缩容时先排空再下线，避免切换中断。配合健康检查与优雅停机（应用处理 SIGTERM 完成请求）。

排空核心是"先停新、再等旧、超时强断"。它与优雅停机配合，避免发布/缩容时请求中断。

• Lua filter 简单易用但性能与隔离弱
• Wasm（Proxy-Wasm ABI）性能好、隔离强、跨语言
• 取舍：开发成本、性能、隔离、生态

Envoy 的 Lua filter 用 Lua 脚本扩展，开发简单、上手快，但性能一般（Lua 解释执行）、隔离弱（依赖 LuaJIT 与 Envoy 主循环）、无法跨语言共享。Wasm（WebAssembly）通过 Proxy-Wasm ABI 扩展，用 Rust/C++/Go 等编译成 Wasm，性能好、沙箱隔离强、安全、可复用多语言，但开发成本高（需编译、SDK 学习）。取舍：简单场景/快速迭代用 Lua；对性能、安全、多语言复用要求高用 Wasm。Wasm 是 Envoy 的推荐扩展方向，隔离与性能兼顾。

取舍是"Lua 易用但弱 vs Wasm 强但成本高"。Wasm 以 Proxy-Wasm ABI 提供沙箱隔离与跨语言，是更可扩展的路线。

• slow start 让新后端渐进增加流量，避免连接突增
• NGINX slow_start、HAProxy slow-start、AWS ALB 渐进
• 应用场景：缓存预热、连接池建立

slow start 让刚加入/恢复的后端逐步增加流量，而不是瞬间满负载，避免连接突增导致服务过载或缓存/连接池未预热。NGINX 商业版 slow_start=30s 让权重从 0 渐增到设定值；HAProxy 的 slowstart 参数（server s1 10.0.0.1:80 slowstart 30s）在重试后渐进；AWS ALB 的 target group 有 slow_start 设置（默认关闭，可设 30-900s）。应用场景：后端刚启动需预热缓存、数据库连接池、JIT 编译，或健康检查恢复后避免雪崩。权衡：slow start 延长了该后端承接全量流量前的时间，需与业务容量匹配。

slow start 的核心是"渐进放量、预热后端"。它避免连接突增与缓存未预热，需与后端容量匹配设置时长。

• log_format 定义自定义日志格式
• 常用变量：$request_time、$upstream_status、$status
• access_log 引用格式

log_format 定义自定义访问日志格式：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" ...';，然后 access_log /var/log/nginx/access.log main; 引用。常用变量：$request_time（请求耗时）、$upstream_status（上游状态）、$upstream_addr（上游地址）、$status（响应状态）、$request_method、$http_user_agent、$http_x_forwarded_for 等。自定义格式用于排障（记录上游状态/耗时）与统计（缓存命中、地域）。修改后 reload 生效。排障 5xx 常加 $upstream_status 与 $request_time。

log_format 用内置变量拼自定义格式，access_log 引用。排障时加 $upstream_status/$request_time 定位代理与上游。

• ALB 是 L7（HTTP/HTTPS），NLB 是 L4（TCP/UDP），CLB 是传统
• ALB 按 LCU 计费，NLB 按 LCU/吞吐，CLB 按小时
• 跨区负载均衡与粘性会话差异

AWS 负载均衡：ALB（Application）是 L7，支持 HTTP/HTTPS 路由、路径/host 路由、TLS 终止、WAF、粘性会话（cookie）；NLB（Network）是 L4，支持 TCP/UDP 高吞吐、静态 IP、跨区，适合高吞吐/非 HTTP；CLB（Classic）是传统型，兼容 L4/L7 但能力有限，已不推荐。计费：ALB 按 LCU（Load Balancer Capacity Unit，按新建连接/活跃连接/处理字节/规则数折算）计费，NLB 按 LCU 或吞吐，CLB 按小时。跨区负载均衡：ALB/NLB 可跨 AZ 均衡，需启用跨区；粘性会话 ALB 用 cookie，NLB 支持源 IP 或 cookie。选型：HTTP 应用用 ALB，高吞吐/非 HTTP 用 NLB，遗留用 CLB。

选型核心是"L7 用 ALB、L4 用 NLB、遗留 CLB"。计费 LCU 与跨区/粘性会话按类型区分。