第48周：项目经历梳理与 STAR 法则

字数统计: 3.2k字   |   阅读时长≈ 12分

第48周：项目经历梳理与 STAR 法则

目标：使用 STAR 法则系统梳理项目经历，准备技术难点阐述，制作面试展示材料。

1. STAR 法则

1.1 STAR 是什么

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
STAR = Situation, Task, Action, Result

S（Situation 情景）：
  - 项目的背景
  - 业务场景
  - 面临的问题

T（Task 任务）：
  - 你的目标
  - 团队的目标
  - 具体的指标

A（Action 行动）：
  - 你做了什么
  - 技术选型
  - 关键决策
  - 难点突破

R（Result 结果）：
  - 量化结果
  - 性能提升
  - 业务收益
  - 团队贡献

1.2 优秀 STAR vs 糟糕 STAR

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
糟糕：
  "我做过一个 LB 项目"
  "性能不错"
  "代码我写的"

优秀：
  "我们团队负责公司 XXX 业务的 L4 负载均衡（背景），
   原 LB 基于 iptables，吞吐仅 1 Mpps，无法支撑业务发展（任务），
   我主导设计并实现了基于 DPDK + XDP 的混合数据面（行动）：
   - XDP fast path 处理 80% 简单流量
   - DPDK slow path 处理 20% 复杂状态流量
   - 用 eBPF maps 共享数据
   - 通过 gRPC 控制面动态下发规则
   结果：吞吐 14 Mpps（提升 14x），P99 延迟 800ns（从 10μs 提升）"

关键：
  1. 数据量化（提升多少倍、节省多少）
  2. 体现你的角色（主导 / 主要贡献 / 参与）
  3. 突出技术深度（具体用到了什么）
  4. 业务影响（带来什么价值）

2. 项目梳理模板

2.1 项目 1：高性能云网关（最有技术含量）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
名称：高性能云网关（Cloud Gateway）

周期：3 个月

角色：主程 / 主要贡献者

STAR 描述：

S（情景）：
  公司 X 业务快速增长，原基于 Linux iptables + LVS 的网关
  无法支撑 10Gbps 流量与千万并发连接，运维成本高。
  团队决定自研下一代云网关。

T（任务）：
  - 目标 1：10Gbps 小包线速转发
  - 目标 2：P99 延迟 < 1μs
  - 目标 3：千万并发连接
  - 目标 4：多租户隔离 + 动态配置

A（行动）：
  1. 架构设计：调研 DPDK / XDP / eBPF / SmartNIC
     - 决定 XDP fast path + DPDK slow path 混合架构
     - 微服务控制面（gRPC）

  2. 关键模块实现：
     - 完整 conntrack 表（双向 5 元组 + TCP 状态机）
       性能优化：Per-CPU 切片、epoch reclamation
     - Full-NAT 转换（SNAT + DNAT）
       用 DPDK rte_hash（无锁）
     - Maglev 一致性哈希 LB
     - 状态防火墙（conntrack 状态机）
     - XDP SYN Cookie（防 SYN flood）

  3. 性能优化：
     - NUMA 亲和（mbuf 池在本地 socket）
     - 缓存行对齐 + 预取
     - SIMD 优化校验和
     - Burst 收发包

  4. 控制面：
     - gRPC + Protocol Buffers
     - 配置版本管理
     - 灰度发布支持

R（结果）：
  1. 吞吐：14 Mpps（线速），相比 iptables 提升 14x
  2. 延迟：P99 < 1μs，相比 iptables 提升 10x
  3. 并发连接：1M+，支持千级租户隔离
  4. 部署：3 个生产集群（云服务、内网、5G UPF）
  5. 开源贡献：给 Cilium 提了 2 个 PR
  6. 团队成长：培养 3 名新成员
  7. 业务影响：节省 30% 硬件成本

2.2 项目 2：分布式追踪系统（如果做过）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
STAR 描述：

S（情景）：
  微服务架构下，问题排查困难：
  - 一次请求经过 10+ 个服务
  - 出错时不知道是哪一步失败
  - 平均排查时间 2 小时

T（任务）：
  设计实现分布式追踪系统，缩短排查时间到 5 分钟。

A（行动）：
  1. 调研 Jaeger / Zipkin / OpenTelemetry
  2. 设计 trace ID 传递方案（HTTP header / gRPC metadata）
  3. 实现 OpenTelemetry SDK
  4. 集成公司内部服务（30+）
  5. 实现采样策略（基于错误率 + 自适应）
  6. 实现查询 UI

R（结果）：
  1. 排查时间从 2 小时 → 5 分钟（24x 提升）
  2. 服务覆盖率 90%
  3. 每日处理 1 亿+ span
  4. 推动团队采用 OpenTelemetry 标准

2.3 项目 3：数据库连接池（如果做过）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
STAR 描述：

S（情景）：
  后端服务连接数据库慢，每次查询都新建连接
  QPS 5K，但响应时间 100ms+
  定位是连接建立开销（30ms+）

T（任务）：
  实现高性能连接池，目标 P99 延迟 < 20ms

A（行动）：
  1. 设计连接池（预建 + 懒建结合）
  2. 实现连接健康检查（ping + validation）
  3. 实现智能扩缩容
  4. 实现连接重试 + 错误转移

R（结果）：
  1. P99 延迟从 100ms → 15ms
  2. 数据库连接数下降 60%
  3. 服务 QPS 提升 3x
  4. 0 故障运行 6 个月

3. 简历项目组织

3.1 简历中的项目格式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
项目名称：高性能云网关
时间：2024.06 - 2024.09 (3 个月)
角色：主程
技术栈：DPDK 22.11, XDP/eBPF, Linux Kernel 6.8, C, gRPC, Prometheus

背景：
  原有网关基于 iptables，无法支撑业务增长（1 Mpps → 14 Mpps 需求）

行动：
  - 设计并实现 XDP fast path + DPDK slow path 混合架构
  - 实现 Maglev 一致性哈希、Full-NAT、conntrack 连接跟踪
  - 集成 gRPC 控制面，支持多租户动态配置
  - 优化 NUMA 亲和性、缓存行对齐、SIMD 校验和

结果：
  - 吞吐提升 14x（1 → 14 Mpps）
  - P99 延迟降低 10x（10μs → 1μs）
  - 支持千万并发连接
  - 部署 3 个生产集群
  - 节省 30% 硬件成本
  - 给 Cilium 贡献 2 个 PR

3.2 项目顺序

1
2
3
4
5
6
7
8
9
10
11
简历项目顺序原则：
  1. 最相关（JD 关键词匹配）放第一
  2. 最具技术含量放第一
  3. 最新的放第一
  4. 时间倒序

推荐顺序：
  1. 高性能云网关（DPDK/XDP）— 最有技术含量
  2. 分布式追踪系统 — 全栈能力
  3. 数据库连接池 — 性能优化
  4. 开源贡献 — 工程能力

4. 技术难点阐述准备

4.1 为什么用 DPDK 而不是 XDP？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
问题：为什么选择 XDP + DPDK 混合架构，而不是只用其中一个？

答案框架：

1. 业务需求：
  - 处理 L4 LB + 状态防火墙 + NAT
  - 10Gbps 线速（64B 包）

2. XDP 优势：
  - 驱动级 fast path
  - 14M pps 处理简单流量
  - 无需分配 skb
  - 优势：节能、共享中断

3. XDP 限制：
  - 不能做复杂状态机（无循环）
  - 验证器约束（不能动态分配）
  - conntrack 状态机实现困难

4. DPDK 优势：
  - 用户态完整控制
  - 灵活状态管理
  - conntrack/NAT/LB 都可做

5. DPDK 限制：
  - 需要独占 CPU
  - 不能与内核栈共享
  - 调度复杂

6. 决策：
  - XDP：处理 80% 简单流量（fast path）
  - DPDK：处理 20% 复杂流量（slow path）
  - eBPF maps 共享数据（conntrack 表）
  - 性能：14 Mpps，复杂度可控

7. 验证：
  - 实测 XDP fast path：14 Mpps
  - 实测 DPDK slow path：10 Mpps
  - 整体：12-14 Mpps（混合）

4.2 如何解决锁竞争？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
问题：conntrack 表在多核下锁竞争严重，性能下降。

思路：分层优化

1. 选无锁数据结构
   - DPDK rte_hash：CAS 实现的 hash
   - 性能：单线程 14 Mpps，多线程几乎线性扩展

2. Per-CPU 数据分片
   - 将表按 src_ip hash 分到 8 个 shard
   - 每个 shard 独立无锁
   - 减少冲突 8x

3. 读写分离
   - conntrack lookup 频繁（读多）
   - 使用 RCU：读无锁
   - 写时复制新副本

4. 减少临界区
   - 计算放到锁外
   - 只对共享数据结构加锁
   - 临界区 < 100ns

5. 性能验证
   - perf lock contention
   - 看到锁占比从 30% → < 5%
   - 性能提升 3-5x

4.3 如何调试一个性能问题？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
问题：用户反馈网关 P99 延迟从 800ns 突增到 10μs，如何定位？

答案框架（系统化调试流程）：

1. 收集信息
   - 什么时候开始？
   - 影响哪些流量？
   - 是否有变更？
   - 当前哪些指标异常？

2. 测量：黄金三问
   - 是 CPU 不足？（perf）
   - 是锁竞争？（perf lock contention）
   - 是缓存 miss？（perf stat -e cache-misses）
   - 是 I/O 阻塞？（iostat / dmesg）

3. 工具链
   - perf：CPU profile
   - bpftrace：动态跟踪
   - ss：socket 信息
   - mpstat：CPU 分布
   - tcpdump：包分析

4. 案例（真实）
   - 一次：发现是 conntrack 表满了
     → sysctl conntrack_max 提高
     → 优化 GC 策略
   - 一次：发现是某个网卡的 RSS 队列绑到 1 个 CPU
     → 重新分配
     → 性能恢复

5. 根因
   - "多核扩展"时忘了 NUMA 亲和
   - 一个 NUMA 节点被打爆

6. 修复 + 验证
   - 修改后回归测试
   - 长期监控

4.4 为什么用 Maglev 而不是一致性哈希？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
问题：为什么选择 Maglev 一致性哈希算法？

1. 一致性哈希问题：
   - 增删节点时，迁移率高（> 30%）
   - 权重分配不均
   - 在小规模后端时分布不均

2. Maglev 优势：
   - 迁移率 < 1/M（M 是表大小）
   - 完美权重支持
   - O(1) lookup
   - Google 部署千万级后端

3. 实现细节：
   - 大表（65537）+ skip 算法
   - 后端数变化只影响少量 entries
   - 加权：按比例分配 entries

4. 验证：
   - 100 后端，加 1 个，迁移率 0.0015%
   - vs 一致性哈希：迁移率 30-50%
   - 在生产中：连接保持率 > 99.99%

5. 局限：
   - 表大小固定（65537）
   - 后端数极多（> 1000）时分布稍差
   - 我们的场景 < 100 后端，很适合

4.5 怎么处理 DDoS 攻击？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
问题：网关遇到 100Gbps SYN flood 攻击，如何防护？

答案：

1. 立即应对
   - 启用 SYN Cookie（已有）
   - 触发 XDP SYN Proxy（已有）
   - 攻击包在内核态处理（XDP），不消耗 conntrack 资源

2. 流量牵引（缓解后端压力）
   - 触发 BGP 牵引规则
   - 攻击流量导向清洗中心
   - 清洗中心识别 + 放行合法流量

3. 清洗中心架构
   - XDP 协议合规验证（拒绝异常 TCP 标志）
   - 黑名单（基于 LRU hash，自动淘汰）
   - 速率限制（令牌桶）
   - 信誉库（多次攻击的 IP 永久封禁）

4. 应急
   - 联系上游 ISP 协助清洗
   - 临时封禁攻击 IP 段
   - 调整 SYN Cookie 阈值

5. 验证
   - 1Gbps 攻击：网关性能下降 < 5%
   - 10Gbps 攻击：仍能服务合法连接
   - 100Gbps 攻击：依赖上游清洗

5. 架构图制作

5.1 PPT 模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Slide 1：封面
  - 项目名称
  - 时间、角色
  - 你的名字

Slide 2：背景
  - 业务问题
  - 当前痛点
  - 目标

Slide 3：架构
  - 整体架构图（数据面 + 控制面）
  - 关键技术选型理由

Slide 4：核心模块
  - 模块 1（如 conntrack）
  - 数据结构 + 关键算法
  - 性能指标

Slide 5：性能优化
  - 优化前后对比
  - 关键技巧
  - 火焰图或性能曲线

Slide 6：结果与影响
  - 业务指标
  - 团队贡献
  - 开源贡献

Slide 7：经验总结
  - 关键决策
  - 学到的教训
  - 后续方向

5.2 画图工具

1
2
3
4
5
6
7
8
9
10
11
12
13
推荐工具：
  - draw.io（免费、强大）
  - excalidraw（手绘风格）
  - Lucidchart（专业）
  - Whimsical（简洁）
  - Mermaid（代码生成图）
  - PlantUML（UML 图）

图示要素：
  - 简洁清晰
  - 颜色一致
  - 标注关键参数
  - 数据流方向

5.3 架构图示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
整体架构图：

┌─────────────────────────────────────────────────┐
│              高性能云网关                            │
│                                                    │
│   ┌─────────────────────────────────────────┐    │
│   │   XDP Fast Path (eBPF)                    │    │
│   │   - 简单路由 (VIP → 后端)                  │    │
│   │   - 5 元组 hash                            │    │
│   │   - 已知会话直接处理                       │    │
│   └─────────────────┬───────────────────────┘    │
│                     │ 未知流量                        │
│   ┌─────────────────▼───────────────────────┐    │
│   │   DPDK Slow Path (User Space)            │    │
│   │   ┌──────────┐  ┌─────────────┐          │    │
│   │   │ Conntrack│  │ Maglev LB   │          │    │
│   │   └──────────┘  └─────────────┘          │    │
│   │   ┌──────────┐  ┌─────────────┐          │    │
│   │   │ NAT 转换 │  │ 状态防火墙   │          │    │
│   │   └──────────┘  └─────────────┘          │    │
│   └─────────────────┬───────────────────────┘    │
│                     │                               │
│   ┌─────────────────▼───────────────────────┐    │
│   │   Control Plane (gRPC)                     │    │
│   │   - 配置下发                              │    │
│   │   - 监控采集                              │    │
│   └─────────────────────────────────────────┘    │
└─────────────────────────────────────────────────┘

数据流：
  Client → 网卡 → XDP fast → (hit? yes → TX)
                            ↓ no
                          DPDK slow → Conntrack → NAT → LB → TX

5.4 性能曲线示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
性能优化前后：

方案           │  PPS    │ 延迟 P99
─────────────┼────────┼─────────
原 iptables  │  1M     │  10μs
XDP only     │ 14M     │  500ns
XDP+DPDK     │ 14M     │  1μs    ← 我们的方案
DPDK only    │ 14M     │  800ns

优化贡献（按百分比）：
  NUMA 优化:    20% 提升
  缓存对齐:     10%
  Burst 处理:   15%
  SIMD 校验和:  5%
  总提升:       50%+

6. 5 分钟自我介绍

6.1 自我介绍模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
您好，我叫 [姓名]，[N] 年经验，主要方向是高性能网络和系统。

我最近在做的是 [项目名]：
  - 业务场景：XXX
  - 我的角色：XXX
  - 关键技术：DPDK、XDP、eBPF
  - 主要贡献：
    * 设计了 XDP + DPDK 混合架构
    * 实现了 Full-NAT 转换
    * 性能达到 14 Mpps
  - 成果：吞吐提升 14x，延迟降低 10x

之前做过 [项目 2]...

我比较关注 [领域]，未来想深入 [方向]。

以上是我的简单介绍，您可以问我任何感兴趣的问题。

6.2 自我介绍技巧

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
原则：
  1. 简洁：5 分钟内
  2. 重点突出：最相关的项目放第一
  3. 量化：用数据说话
  4. 表达清晰：技术词精准

常见错误：
  - 念简历（面试官已经看过了）
  - 流水账（从毕业讲到现在）
  - 没重点（什么都讲一点）
  - 没数据（"做了优化性能提升"无量化）

应对追问：
  - 每个项目准备 3-5 个深入问题
  - 准备"为什么这么做"的回答
  - 准备"如果重来会怎么做"的反思

7. 准备清单

1
2
3
4
5
6
7
8
9
10
11
12
13
□ 项目 STAR 描述（每个项目一份）
□ 简历中每个项目的量化数据
□ 5 个技术难点的详细阐述
□ 5 分钟自我介绍（熟练背诵）
□ 架构图（3-5 个）
□ 性能曲线（2-3 个）
□ 每个项目的常见追问准备
□ 项目代码（部分可演示）

□ 准备好的问题（给面试官）：
  - 团队目前最关注的技术挑战？
  - 这个岗位的成长路径？
  - 您觉得我的背景还有什么可以加强的？
赏

谢谢你请我吃糖果

支付宝
微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

主要涉及技术：
Java后端开发、Linux开发、
公众号开发、开源爱好者、Linux

联系QQ:562054870