我对技术探索与实践的看法
早上8点，杭州的天空刚刚泛白，我泡好一杯速溶咖啡（别笑，大厂打工人哪有时间手冲），打开IDEA，准备处理昨天晚上线上告警留下的烂摊子。这已经是本周第三次因为缓存穿透导致订单服务响应变慢了——而今天还是周四，离双11大促只剩不到一个月。
我是美团外卖的一名Java后端开发，入行四年，经历过三次618、两次双11，也熬过无数个被产品经理凌晨三点Call醒改需求的夜晚。最近在刷LeetCode的同时，还在啃《深度学习入门》，不是因为我突然想转AI工程师，而是发现隔壁组用LLM做智能调度的效果实在太香了。顺便提一句，坐标杭州，阿里网易扎堆的地方，跳槽机会多，但简历投出去石沉大海的也不少。
写这篇文章，其实源于上周五的一次“社死”经历。
那天下午，团队来了个新实习生，刚从某985毕业，简历上写着“熟悉高并发架构”、“精通Redis与Kafka”，还参与过“千万级用户系统设计”。我心想：哟，后浪来了。结果下午Code Review时，他写的缓存逻辑居然是get -> if null -> load from DB -> put，连最基本的布隆过滤器或互斥锁都没加。我问他：“你简历里写的高并发经验，是压测过多少QPS？”他支支吾吾说：“课程设计……模拟了100并发。”
那一刻，我突然意识到：技术探索和简历包装，完全是两码事。
很多人（包括曾经的我）以为，只要在简历上堆满“分布式”“高可用”“微服务”这些 buzzword，就能拿下大厂offer。但真实世界里，技术的价值不在于你怎么写，而在于你怎么用、怎么解决问题、怎么扛住线上流量洪峰。
问题从来不会等你“准备好”
去年双11前夕，我们订单服务突然在晚高峰出现大量超时。监控显示DB CPU飙升到95%，日志里全是SELECT * FROM order WHERE user_id = ? AND status IN (1,2,3) 这种语句。查了半天，发现是前端为了“优化体验”，把原本分页的接口改成了一次拉全部订单——用户量一上来，直接把MySQL干趴了。
当时真的想砸电脑。
但骂完产品（友军伤害，勿喷），我们得干活。第一反应是加缓存。但缓存策略怎么定？全量缓存？内存撑不住。按用户ID分片？热点用户怎么办？最后我们搞了个二级缓存 + 滑动窗口限流 + 异步预热的组合拳：
// 伪代码示意
public List<Order> getUserOrders(Long userId) {
// L1: 本地Caffeine缓存（防突发热点）
List<Order> localCache = localCache.getIfPresent(userId);
if (localCache != null) return localCache;
// L2: Redis缓存（带空值防穿透）
String redisKey = "order:user:" + userId;
String json = redis.get(redisKey);
if (json != null) {
if ("NULL".equals(json)) return Collections.emptyList();
List<Order> orders = JSON.parse(json);
localCache.put(userId, orders); // 回填L1
return orders;
}
// DB查询 + 布隆过滤器兜底（这里省略BloomFilter检查逻辑）
List<Order> fromDB = orderMapper.selectByUserId(userId);
// 异步预热：提前加载下一页数据（基于用户行为预测）
asyncPreloadNextPage(userId);
// 写缓存，空值也写（防穿透）
String cacheValue = fromDB.isEmpty() ? "NULL" : JSON.toJSONString(fromDB);
redis.setex(redisKey, 300, cacheValue);
localCache.put(userId, fromDB);
return fromDB;
}
上线后，DB负载降了70%，P99延迟从1.2s降到180ms。虽然过程很痛苦，但这次事故让我明白：真正的技术能力，是在压力下快速定位问题、权衡方案、落地执行的能力。而不是在简历上写“使用Redis提升性能”。
技术探索：别为了学而学
最近我在学AI，不是跟风，而是业务真有需求。比如骑手路径规划，传统算法在高峰期经常给出“绕地球一圈”的路线。我们尝试引入轻量级图神经网络（GNN），用历史轨迹数据训练一个路径预测模型。虽然最终没上生产（模型推理延迟太高），但过程中我学会了用PyTorch写数据管道、用ONNX做模型转换，甚至还给团队写了份《AI工程化落地 checklist》。
技术探索的关键，是带着问题去学。
- 如果你是为了跳槽，那重点应该是：目标公司用什么技术栈？JD里反复提的关键词是什么？
- 如果你是为了提升业务效果，那就盯着指标：能不能降本？能不能增效？能不能提升用户体验？
我见过太多人盲目学K8s、Service Mesh、Flink，结果面试被问“你们为什么选Kafka而不是RocketMQ”时答不上来。技术选型从来不是“哪个更牛”，而是“哪个更适合当前场景”。
举个例子，我们订单状态机以前用数据库事务+状态字段硬编码，后来想上事件驱动。选型时对比了三种方案：
| 方案 | 优点 | 缺点 | 适用阶段 |
|---|---|---|---|
| 数据库事务 + 状态机表 | 简单、强一致 | 扩展性差、耦合高 | 初创期 |
| RabbitMQ + 本地事务表 | 解耦、异步化 | 消息可能重复、需幂等 | 快速增长期 |
| Kafka + Event Sourcing | 可追溯、支持重放 | 架构复杂、运维成本高 | 成熟稳定期 |
我们最终选了第二种——不是因为它最先进，而是团队能hold住，且满足未来一年业务规模。
简历怎么写？说人话！
说到简历，我真的想吐槽：为什么那么多简历写成“技术名词大杂烩”？
“使用Spring Cloud Alibaba构建微服务架构，集成Nacos、Sentinel、Seata，实现服务注册发现、熔断降级、分布式事务。”
听起来很厉害，但面试官只想问一句：你遇到过什么问题？怎么解决的？结果如何？
我的建议是：用STAR-L法则写简历（Situation, Task, Action, Result + Learning）。
比如这样写：
订单服务性能优化（2023.09 - 2023.11）
- 背景：双11预演期间，订单查询接口P99延迟达1.5s，DB CPU持续>90%
- 行动：设计二级缓存架构（Caffeine + Redis），引入布隆过滤器防穿透，配合滑动窗口限流；推动前端分页改造
- 结果：DB负载下降70%，P99降至180ms，支撑日均2亿订单查询
- 复盘：缓存一致性需加强，后续引入Canal监听binlog做失效补偿
这样的简历，面试官一眼就知道你干了啥、能力在哪、有没有复盘意识。
顺便说一句，我在帮朋友改简历时，发现一个普遍问题：过度包装，缺乏细节。写“主导高并发系统设计”，结果连QPS都说不出具体数字；写“优化JVM性能”，却说不清用了什么GC参数、调优前后对比数据。技术人的 credibility，就藏在这些细节里。
实践出真知：别怕“脏活累活”
很多人觉得，只有做“新项目”“新技术”才叫成长。但我想说：修Bug、看日志、对监控，这些“脏活”才是技术深度的试金石。
上周三凌晨2点，线上支付回调接口突然失败率飙升。排查发现是第三方支付平台返回了非法JSON（多了个逗号），而我们的解析逻辑没做容错。当时第一反应是骂第三方，但冷静下来后，我们做了三件事：
- 紧急兜底：加try-catch，异常回调走人工审核队列
- 防御加固：所有外部JSON解析统一用
ObjectMapper.configure(DeserializationFeature.FAIL_ON_TRAILING_COMMA, false) - 建立契约：推动和第三方签订SLA，要求返回格式严格符合RFC
这件事没写进OKR，也没法吹“技术突破”，但它让我深刻理解了鲁棒性（Robustness）比优雅更重要。
最后一点真心话
技术这条路，没有捷径。
你可以背八股文过面试，但线上故障不会陪你演戏；
你可以简历写“精通分布式”，但CAP理论在真实系统里永远是个trade-off。
我现在的习惯是：每解决一个问题，就写一篇内部wiki；每学一个新技术，就尝试在测试环境跑个demo；每次面试别人，也会反思“如果是我，能不能答得更好”。
最近在刷AI，不是为了转行，而是想看看能不能用LLM自动分析线上日志、预测故障。虽然可能失败，但探索本身就有价值。
如果你也在杭州，也在卷技术，欢迎交流。简历可以发我看看（免费，但别发“精通高并发”那种 😅）。毕竟，在这个充满不确定性的时代，唯一确定的，是我们解决问题的能力。
共勉。
评论 0