会聚焦 “实际操作、代码/配置落地、工具使用” 设计问题，考察候选人是否真的动手做过七层负载均衡相关研发或运维，避免“纸上谈兵”，核心问题如下：
一、配置与实操落地（考察基础动手能力）
1. 用 Nginx 配置一个七层负载均衡，要求实现“按 URL 路径转发（/api 到服务 A，/web 到服务 B）+ 基于权重的负载均衡算法 + 后端服务的健康检查”，请说出关键配置段（比如 location、upstream 块的核心参数）。
upstream myserver {
192.168.1.1 80;
192.168.1.2 80;
}
location /api {
proxy_pass myserver;
schedule wrr;
}
2. 若用 Envoy 做云原生场景的七层负载均衡，需要让 Envoy 动态发现后端服务（比如从 Kubernetes Service 获取端点），你会怎么配置 Envoy 的 Service Discovery 模块？用到哪些关键资源（如 Cluster、Endpoint Discovery Service 相关配置）？
3. 实际部署七层负载均衡集群时，如何避免“单点故障”？你会用什么工具或方案实现负载均衡节点的高可用（比如 Keepalived、云厂商的 SLB 转发）？请说下具体操作步骤（比如 Keepalived 的 VIP 配置、健康检查脚本）。
二、性能调优与问题定位（考察实操经验）
1. 七层负载均衡（以 Nginx 为例）在高并发下出现“连接超时”，你会用哪些工具排查问题？比如如何通过 netstat/ss 查看连接状态、通过 Nginx 访问日志定位异常请求、通过 perf 分析 CPU 瓶颈？请说下具体操作命令和分析逻辑。
2. 若要优化 Envoy 的七层转发性能（比如降低 HTTP 请求的处理延迟），你会调整哪些关键参数？比如工作线程数（worker_threads）、连接池大小（max_requests_per_connection）、缓冲区大小（buffer_limit），调整时会参考什么指标（如 CPU 使用率、请求响应时间 P99）？
3. 之前用 DPDK 优化七层负载均衡的数据包处理时，具体做了哪些动手操作？比如如何编译 DPDK 环境、如何将负载均衡程序绑定到指定 CPU 核心（避免进程切换）、如何通过 dpdk-devbind.py 绑定网卡到 DPDK 驱动？
三、功能开发与调试（考察研发实操）
1. 若要给 Nginx 开发一个自定义的七层负载均衡算法（比如“基于后端服务的 CPU 使用率动态分配流量”），你会怎么做？请说下开发流程（比如基于 Nginx 模块开发框架、如何获取后端服务的 CPU 指标、如何在模块中实现算法逻辑），以及如何调试这个模块（比如用 nginx -t 检查配置、用日志打印流量分配结果）。
2. 开发七层负载均衡的“请求限流”功能（比如限制单 IP 每秒最大请求数），你会用什么数据结构或工具实现？比如基于 Redis 的计数器、本地内存的滑动窗口？请说下具体实现思路（比如 Redis 的 INCR+EXPIRE 命令组合、滑动窗口的时间片划分逻辑），以及如何测试这个功能（比如用 ab/jmeter 压测验证限流效果）。
3. 调试七层负载均衡的“SSL 握手失败”问题时，你会用哪些工具？比如如何用 openssl s_client 模拟客户端握手、如何查看负载均衡的 SSL 证书链是否完整、如何通过日志定位是证书问题还是协议版本不兼容（比如客户端用 TLS 1.0 而负载均衡只支持 TLS 1.2+）？请说下具体操作和排查步骤。
结合岗位对“研发能力、线上经验、技术视野”的要求，我会从技术原理、实践落地、问题解决、规划能力四个维度提问，以下是核心问题：
一、基础原理与技术理解（考察核心知识储备）
1. 相比四层负载均衡，七层负载均衡能实现哪些独特功能？这些功能在技术实现上依赖哪些网络协议细节（比如HTTP头部、SSL握手流程）？
2. 你在使用Nginx/Envoy/DPVS做七层负载均衡时，分别遇到过哪些协议层面的坑（比如HTTP/2的队头阻塞、SSL证书协商效率问题）？是怎么解决的？
3. 七层负载均衡的“会话保持”有哪些实现方式？不同方式在分布式场景（多负载均衡节点）下会面临什么问题，如何规避？
二、研发与性能优化（考察岗位核心能力）
1. 你之前用DPDK做高性能网络架构时，有没有针对七层负载均衡场景做过优化？比如如何通过DPDK降低HTTP请求的数据包处理延迟，具体优化了哪些链路（如内核态/用户态切换、内存拷贝）？
2. 如果要设计一个支持百万级QPS的云原生七层负载均衡产品，你会从哪些维度做架构设计（比如集群部署、资源调度、缓存策略）？如何验证架构的性能上限？
3. 七层负载均衡的“健康检查”模块，你会设计哪些检查维度（比如TCP连接、HTTP返回码、业务自定义指标）？如何避免健康检查本身对后端服务造成额外负载？
三、线上问题与重保支持（考察落地经验）
1. 之前遇到过七层负载均衡的线上故障吗？比如“部分用户请求4xx/5xx报错”“高并发下负载均衡节点CPU飙升”，当时是怎么定位根因、快速恢复的？
2. 若在业务重保期间（比如双11、大促），七层负载均衡突然出现请求转发延迟暴涨，你会优先排查哪些环节（负载均衡节点、后端服务、网络链路）？有什么应急预案？
3. 如何判断七层负载均衡的“性能瓶颈”是在自身（比如协议处理效率）还是后端服务（比如服务响应慢）？会用哪些工具或指标来佐证？
四、技术规划与产业视野（考察高阶能力）
1. 目前云网络七层负载均衡的技术趋势（比如结合Service Mesh、边缘计算、AI流量调度），你最关注哪一个？如果要把这个趋势落地到产品中，需要突破哪些技术难点？
2. 你之前做产品技术规划时，是如何平衡“新功能研发”和“现有系统稳定性”的？比如要给现有七层负载均衡加“智能流量调度”功能，会怎么做技术选型和灰度方案？
3. 对比公有云和私有云的七层负载均衡场景，用户需求有哪些核心差异？这些差异会如何影响产品的架构设计（比如资源弹性、定制化能力）？
