浅谈技术探索与实践：一个百度搜索算法工程师的“不务正业”之路

大家好，我是老K，坐标北京西二旗，目前在百度干了快三年的搜索算法工程师。主要工作嘛，说白了就是让你们搜“怎么追女生”或者“为什么我写的代码跑不通”时，能更快看到靠谱答案（而不是某些营销号）。团队氛围不错，老板也还算开明，但最近确实有点“倦怠期”——毕竟每天和Query、点击率、CTR模型打交道，再热爱也会审美疲劳。

最近在认真考虑换个工作环境，不是因为钱（虽然也挺重要），更多是想接触些新东西。于是开始“不务正业”地折腾一些跟本职工作关系不大的技术栈，比如云原生、K8s，甚至……区块链。对，你没看错，一个搞搜索的，跑去碰区块链，听起来是不是有点离谱？但今天这篇文，就想聊聊这段“曲线救国”的技术探索经历，以及过程中踩过的坑、用过的工具，和一些意外收获。

---

起因：被“逼”出来的技术好奇心

事情得从去年双11说起。那会儿我们组在搞一个“实时热点聚合”项目，要求在突发新闻（比如某明星塌房）发生后5分钟内，把相关内容聚合到搜索结果页顶部。这听着简单，但实际做起来简直是“地狱模式”——数据源五花八门，微博、抖音、知乎、小红书……每个平台的API限流策略还不一样，稍不留神就被封IP。

更惨的是，当时运维兄弟给我们搭的测试环境还是基于物理机的，扩容全靠手动加机器。有天凌晨两点，线上流量突增，报警响成一片，我和两个同事蹲在工位上疯狂改配置、重启服务，差点当场表演“原地辞职”。

就那一刻，我突然意识到：光会调参、写模型远远不够，系统架构和工程能力才是兜底的关键。而公司内部虽然也有完善的基础设施，但很多细节被封装得太深，像我这种“业务层选手”根本摸不到底层逻辑。

于是，我下定决心：得学点“硬核”的东西。

---

区块链？真不是为了炒币

先别急着笑。我知道一提区块链，很多人第一反应就是比特币、NFT、割韭菜。但抛开金融属性，区块链底层的技术思想其实挺有意思——比如去中心化共识、不可篡改的日志、智能合约的状态机模型。这些概念其实在分布式系统里都能找到影子。

真正让我动手的契机，是我司有个内部创新孵化项目，想做一个“可信内容溯源”系统：用户看到一篇新闻，能知道它最早是从哪个媒体发出的，中间有没有被篡改过。产品经理画了个巨复杂的流程图，还信誓旦旦地说“用区块链就能解决信任问题”。

我当时心里直嘀咕：“这玩意儿性能扛得住吗？咱们日均几十亿的搜索量，你拿个TPS不到1000的链来扛？” 但转念一想，与其嘴上吐槽，不如亲自试试水深。

于是，我花了周末两天时间，用 Hyperledger Fabric 搭了个最小可行链（MVP）。为啥选 Fabric？因为它权限可控、支持私有部署，不像公链那样动不动就要挖矿。而且它的 Chaincode（智能合约）可以用 Go 或 Node.js 写，对我们这些 Web 背景的工程师比较友好。

搭建过程就不细说了，反正被 Docker 网络配置和 TLS 证书折磨得够呛。但搞定之后，还真跑通了一个简单的“内容指纹上链”流程：每篇新闻生成 SHA256 哈希，写入区块，后续任何修改都会导致哈希不匹配。

关键来了：这个实验虽然成功了，但我很快发现——对于搜索场景，区块链可能是个“过度设计”。

维度	传统数据库（如 MySQL + Binlog）	区块链（Fabric）
写入延迟	< 10ms	~500ms - 2s
吞吐量（TPS）	1w+	~500
存储成本	低（可压缩/归档）	高（全节点需存完整账本）
可审计性	需额外日志系统	原生支持
开发调试体验	成熟工具链	调试困难，日志分散

结论很清晰：除非真的需要多方不可信协作（比如跨公司数据共享），否则用区块链解决“单方内部防篡改”问题，纯属杀鸡用牛刀。最后我们还是用了基于 Merkle Tree + 时间戳服务器的传统方案，效果一样好，性能高十倍不止。

但这次折腾并非白费——我深入理解了分布式共识（Raft vs PBFT）、Merkle 树结构、以及如何设计不可抵赖的数据流水线。这些知识反过来帮我优化了搜索索引的增量更新机制，减少了30%的重复计算。

---

工具链：效率提升的“外挂”

如果说技术探索是“打怪”，那趁手的工具就是“装备”。这几年我越来越信奉一句话：程序员的时间很贵，别在重复造轮子上浪费生命。

1. K8s + Helm：告别“运维求爷爷告奶奶”

以前每次要部署新服务，都得找运维填工单、等审批、配网络策略，慢得像蜗牛。自从团队全面上云原生，我直接用 Helm 写了个 Chart 模板：

# values.yaml
replicaCount: 3
image:
  repository: registry.baidu.com/search-indexer
  tag: "v1.2.3"
resources:
  limits:
    cpu: "2"
    memory: "4Gi"

一行 helm install indexer ./chart -f prod.yaml，服务就跑起来了。配合 ArgoCD 做 GitOps，连发布都自动化了。上周五晚上加班改了个紧急 Bug，我本地 build 镜像、推仓库、改 tag，10分钟后线上就生效了——再也不用在群里@运维大哥求他“加个班”。

2. eBPF + BCC：排查性能瓶颈的“透视眼”

有次线上模型推理延迟突然飙升，查了一圈日志、监控都没发现问题。情急之下，我祭出了 eBPF 大法，用 bcc 工具包里的 profile 和 offcputime 直接抓取内核栈：

# 查看哪些函数占用 CPU 最多
sudo /usr/share/bcc/tools/profile -F 997

# 查看进程阻塞在哪些地方
sudo /usr/share/bcc/tools/offcputime -p $(pgrep my_service)

结果发现是某个第三方 Python 库在频繁进行 DNS 查询，而我们的 DNS 服务器响应慢。换成 IP 直连后，P99 延迟从 800ms 降到 120ms。这种“无侵入式诊断”简直爽到飞起，比加无数 log 打印高效多了。

3. Digma：开源的“可观测性增强器”

最近在试用一个叫 Digma 的开源工具（对，我就是喜欢研究 GitHub 上的新玩意儿）。它能在 IDE 里直接显示代码的运行时行为：比如某个函数被调了多少次、平均耗时多少、有没有异常。不用切到 Grafana 或 ELK，开发时就能预判性能问题。

虽然现在功能还不完善，但思路很对——把可观测性左移到开发阶段。我已经把它集成到我们组的 CI 流程里了，PR 提交时自动跑一遍性能基线对比，防止有人偷偷提交 O(n²) 的垃圾代码（别问我是怎么知道的）。

---

心得：技术探索不是“炫技”，而是“解题”

回过头看，不管是折腾区块链，还是深挖 K8s/eBPF，核心目的从来不是“我会这个”，而是 “它能不能帮我更好地解决问题”。

在大厂待久了容易陷入两个误区：

• 过度依赖平台：觉得“反正有中台/基建团队兜底”，丧失了动手能力；
• 技术洁癖：非得用最新最酷的方案，忽略了业务场景的真实约束。

我现在的态度是：以业务问题为锚点，向外辐射学习。比如为了解决部署慢，我去学 K8s；为了排查延迟，我去啃 eBPF；为了评估新技术可行性，我亲手搭原型验证。

顺便吐槽一句：有些产品经理真的以为“上链=高科技”，下次再听到这种话，我打算直接甩出上面那张性能对比表（笑）。

---

结语：保持“不安分”，但别瞎忙

写这篇文章的时候，窗外又开始堵车了——西二旗的晚高峰永远这么准时。我在想，或许每个工程师都会经历这样的阶段：熟悉了当前赛道，但又不甘心只做一颗螺丝钉。

技术探索的意义，不在于你最终是否用上了某个技术，而在于拓宽你的解题工具箱，让你在面对新问题时，能多几个选项。区块链我没用上，但分布式系统的思维帮了大忙；K8s 和 eBPF 看似和算法无关，却让我交付的系统更稳定、更高效。

如果你也在考虑转型或跳槽，我的建议是：别只刷 LeetCode，多动手搭真实系统。面试官问“你做过什么”，远比“你知道什么”更有说服力。

好了，不说了，刚收到消息，明天又有新需求评审——据说要接入元宇宙搜索（？？？）。我先去泡杯咖啡，准备迎接新一轮“技术探索”了。

（完）

P.S. 如果你也在折腾云原生或分布式系统，欢迎交流！GitHub ID: k-search-engineer（不是真名，但项目都是实打实的）。跳槽不跳槽另说，但技术路上，多个朋友多条路嘛～