我的工作经历从业务系统研发、项目管理、架构治理,逐步延伸到基础设施建设、稳定性治理、成本优化、云原生平台和数据/机器学习平台迁移。相比单点技术实践,我更重视问题从发现、定位、验证、修复到机制化沉淀的完整闭环,也更关注技术方案在真实生产环境中的长期可维护性。
KL博客是我长期工程实践的公开记录。这里的文章大多来自真实项目和线上问题,包括架构升级、开源项目、性能优化、故障排查、成本治理、平台迁移和年度复盘。它不只是博客,更像是一份持续更新的工程履历。
专业方向
- 基础设施稳定性:负责或长期维护 xxl-job、Apollo、OpenTelemetry、OSS、SLS、Redis、CDN、Sentry、DolphinScheduler 等关键基础设施,关注高可用、可观测、排障效率和长期治理。
- 复杂线上问题排查:处理过 Redis、ClickHouse、Sentry/Snuba、OpenTelemetry Collector、Kafka、JVM、压缩算法、数据库驱动等生产问题,习惯从指标、日志、调用链、源码和实验中定位根因。
- 成本优化与资源治理:负责 Redis、CDN、OSS、SLS、机器学习训练平台等场景的成本优化,通过迁移、压缩、流量治理、生命周期治理、实例治理和自动化工具降低长期成本。
- 平台工程与云原生迁移:负责自建机器学习训练平台从云厂商体系迁移到 Kubeflow,推动训练 IO、checkpoint、任务迁移、双跑验证、效果对齐和平台可靠性建设。
- 开源建设与技术影响力:长期维护和参与开源项目,既关注代码实现,也关注社区反馈、文档表达、版本迭代和项目可持续发展。
- AI 工程效率:将 AI 纳入个人工程工作流,用于方案推演、代码实现、问题排查、文档沉淀和复杂上下文总结,在不替代工程判断的前提下提升交付效率。
代表性工程实践
基础设施与稳定性治理 2020 至今
在 TapTap 工作期间,我持续负责和维护多类基础设施能力,包括 xxl-job、Apollo、OpenTelemetry、OSS、SLS、Redis、CDN、DolphinScheduler、Sentry 等。相关工作不只是日常运维,而是围绕稳定性、可观测性、成本和研发效率做系统性治理。
- 推动 Java 基础组件、Java 工程规范、应用可观测性、JDK 17 升级、分布式链路追踪、任务调度等基础能力建设。
- 保障 xxl-job、Apollo、Otel 等关键系统稳定运行,支撑业务研发日常使用。
- 推动 DolphinScheduler 从老版本升级到社区稳定版本,并迁移到 K8s 集群,补齐 workflow 调度和可观测能力。
- 负责 Apollo 配置中心内部运维和社区协同,推动集群高可用增强、内存缓存、OpenAPI 管理、系统配置在线管理、历史发布记录清理、非 properties namespace 灰度发布等能力落地。
- 深入研究 Sentry 架构,维护自建 Sentry 集群,处理 ClickHouse、Relay、APM、资源成本和多地域流量入口等问题,并向 Sentry 主仓提交多个修复 PR。
成本优化与资源治理 2022-2024
我长期关注基础设施成本治理,并且更倾向于通过数据、工具和机制解决问题,而不是一次性压缩资源。
- OSS 治理:通过生命周期管理、无效数据清理、公网流量治理等方式,推动 OSS 实例费用月度成本降低约 11 万元。
- SLS 治理:通过存储周期优化、采样上报、业务日志治理、索引治理和存储类型匹配,推动 SLS 月度成本降低约 27 万元。
- Redis 治理:通过低成本实例迁移、流量压缩、无效数据清理、TTL 治理和无用实例下线,结合自研流量复制、流量放大、数据迁移、在线压缩解压、定向清理和 Key 访问分析工具,推动 Redis 月度成本降低约 46 万元。
- redis-tools:Redis 成本优化工程沉淀工具集,目前已开源。
- CDN 治理:提出“按场景计算综合单价”的评估方式,设计“带宽占比分析”模型,用于评估多供应商 CDN 质量和成本,最终推动 CDN 成本降低 10% 以上。
- 机器学习平台存储治理:推动 checkpoint 数据治理,累计清理 6.26PB 数据,将存储规模从峰值 8.97PB 降到 2.71PB,每月优化 OSS 存储成本约 31.4 万元,并通过自动清理程序把治理机制长期化。
机器学习训练平台迁移与重构 2024-2025
2024 到 2025 年,我从算法训练成本优化切入,逐步负责自建机器学习训练平台建设。这件事表面是从云厂商 DLC、XFlow 迁移到 Kubeflow,实际是一次训练体系重构。
- 完成 DLC 183 个任务与 XFlow 279 个任务迁移,将训练体系从云厂商平台切换到自建 Kubeflow 平台。
- 自研
tapioODPS 数据读取框架,基于 pyodps 支持 TensorFlow 和 PyTorch Dataset,替代阿里云闭源 paiio,解耦云厂商能力。 - 在多个模型中获得明显收益:部分模型训练时间降低约 30%、38%、70%,个别模型从 20 分钟降到 3 分钟。
- 通过 WorkQueue 优化多 worker 训练,降低约 80% 内存资源占用,并缓解快慢 worker 导致的退出延迟问题。
- 排查和解决 TensorFlow PS/Worker 配比、评估任务 hang、session close、Kubeflow success policy、训练结果对齐等迁移过程中的关键问题。
- 建立模型效果验证方法,通过 checkpoint 分支实验缩短迁移验证周期,让平台迁移从“任务能跑”推进到“结果可信”。
这段经历对我来说很重要。它证明了工程方法可以跨领域迁移:即使进入陌生领域,只要能拆清楚目标、链路、约束、验证标准和回滚路径,就能在关键节点产生实际推动力。
大数据迁移与自动化工具链 2025 进行中
2025 年,我加入 MC 大数据迁移项目,项目背景是原有大数据平台基于阿里云 MaxCompute + DataWorks 构建,随着业务和数据规模增长,逐步暴露出计算灵活性不足、技术栈深度绑定、技术选型和议价空间受限等问题。迁移目标是建设以 Spark + OSS 为核心的 Lakehouse 架构,把数据平台从云厂商能力绑定中解耦出来,形成更开放、更可控的数据基础设施。
- 提出并推动 V2 迁移方案落地,降低迁移复杂度和实施风险。
- 自研 ODPS SQL 到 Spark SQL 的翻译引擎,在 ADN 业务实现 100% SQL 翻译覆盖,ADN 作业翻译 0 人工介入。
- 自研 DataWorks 任务迁移服务,实现 ADN 全量任务自动化迁移到新的 Lakehouse 空间。
- 支撑 500+ 任务每日稳定双跑。
- 搭建 mc2lake 数据报告中心,持续输出运行报告,为 Spark vs MC 的性能与成本对比提供数据依据。
- 项目直接收益集中在年化运营成本优化上:预期整体成本降低 15%-30%,Lakehouse 架构下计算成本较 MC 降低约 15%-20%,模型训练成本降低约 8%。
- 长期收益包括解除厂商锁定、提升平台灵活性和技术选型自由度,沉淀主流开源大数据技术栈经验,并为混合云/多云战略和系统可控性打基础。
这类项目的难点不是单个工具,而是把迁移链路、数据一致性、运行报告、性能成本对比和后续割接风险控制串成完整体系。
架构升级与中间件建设 2016-2020
早期在凯京期间,我参与并推动过从业务开发到架构治理的转型,经历过系统从单体和外围系统扩展到 SOA、Dubbo、Spring Cloud、Apollo、xxl-job、Spring Boot + Angular 前后端分离等阶段。
- 参与公司系统架构升级:SOA 服务化、Redis 分布式缓存、MQ RPC 到 Dubbo、HTTP Client 到 Feign、Disconf 到 Apollo、单机调度到 xxl-job、老 GWT 项目到 Spring Boot + Angular。
- 主导或参与多个中间件和平台项目:回调中心、反爬防刷、日志组件、统一网关、电子签章、短信平台、集成中心、Spring Boot 脚手架、授权鉴权项目、Klock、Binlog、kkFileView 等。
- 完成授权认证服务无缝迁移,支撑核心权限体系稳定升级。
- 推动自维护 Dubbo 版本升级,并不停服完成注册中心从 Redis 到 Nacos 的平滑迁移。
- 研究并落地数据脱敏、多数据源分布式事务、JDChain 区块链、Quarkus + GraalVM 等技术实践。
这段经历让我形成了一个基本判断:架构能力不是追逐复杂概念,而是在业务增长、系统演进和组织协作中,把不稳定、不清晰、不可复用的部分逐步收敛成平台能力。
开源与技术影响力
开源是我技术成长中非常重要的一部分。我既维护自己的项目,也参与成熟开源项目的社区建设。
- kkFileView:文件在线预览项目,曾获 Gitee GVP,也是 kk 开源社区的核心项目。
- spring-boot-klock-starter:基于 Spring Boot 的分布式锁组件。
- ratelimiter-spring-boot-starter:基于 Redis 的分布式限流 Spring Boot Starter,支持业务侧细粒度限流。
- springboot-mqrpc:基于消息队列的 RPC 实践。
- kkbinlog:Binlog 相关实践项目。
- Quarkus 相关扩展:围绕 Apollo、Dubbo、Nacos 等国内常用中间件做过 Quarkus 集成探索。
- quarkus-dubbo-rpc:Quarkus 集成 Dubbo 框架的扩展。
- quarkus-nacos-config:Nacos 配置中心的 Quarkus 框架扩展。
- quarkus-apollo-config:Apollo 配置中心的 Quarkus 框架扩展。
- quarkus-redis-klock:基于 Redis 的 Quarkus 分布式锁扩展。
- quarkus-logging-aliyun:阿里云日志的 Quarkus 框架扩展。
我长期参与开源社区建设,其中最核心的角色是 Apollo PMC。围绕 Apollo,我参与社区版本发布、需求讨论、开源之夏导师工作,以及公司内部配置中心实践与社区能力之间的反馈闭环。同时,我也曾参与 Soul、SkyWalking、Seata、p6spy、TubeMQ、JDChain、Sentry 等项目贡献,在真实工程场景中持续和开源社区保持连接。
开源社区相关证书与纪念













在开源项目之外,我长期坚持技术写作。2017 年输出 30+ 篇技术文章,2019 年输出 40+ 篇技术文章,后续也持续把线上问题、源码分析、架构实践、成本优化和平台迁移沉淀到博客中。写作对我来说不是包装,而是复盘和知识外化的一部分。
我对工程工作的理解
我认为优秀的工程工作,不只是把功能写完,也不是单次解决一个问题,而是在复杂系统里持续降低不确定性。
- 目标清晰:先明确问题到底是稳定性、性能、成本、效率,还是可维护性。
- 链路完整:能从用户现象、系统指标、数据链路、源码逻辑和资源成本中还原问题全貌。
- 证据充分:关键结论要有日志、指标、实验、代码或数据支撑。
- 方案可验证:迁移、优化、重构都应该有验证方法,而不是依赖经验判断。
- 机制沉淀:一次问题解决后,最好能沉淀成工具、平台、文档、自动化或流程机制。
- 持续进化:AI 可以放大工程师效率,但关键判断、质量把关和最终责任仍然属于工程师。
这些年,我从业务研发、技术管理、架构中间件,到基础设施、成本治理、机器学习平台、大数据迁移,面对的领域不断变化。但底层方法越来越清晰:定义目标,拆解链路,建立验证,自动化执行,形成长期治理机制。
这也是 KL博客存在的意义。它记录了我在真实工程场景里的思考、实践和复盘,也希望来到这里的读者,能从这些文章里获得一些可参考、可验证、可落地的经验。

评论