1. 项目概述与年度定位1.1 核心需求解析2025年对全知科技来说是一个从“能跑”到“跑得稳”的关键转折点。年初定调的时候我们团队内部吵了好几轮最后达成共识这一年不追求新概念的数量不搞花活核心就干三件事——把现有产品的稳定性做到极致、把核心系统的性能瓶颈彻底打透、把团队的技术纵深拉起来。这个定位来自一个很直接的判断前两年我们铺了不少场景客户侧反馈最多的不是“你缺功能”而是“功能有了但不敢上生产”。稳定性才是拦路虎。所以2025年度总结如果只让我说一句话那就是——我们把过去积累的技术债还掉了一大半并且把一套能持续还债的机制建起来了。这篇总结适合三类人看一是同样在做系统架构升级的技术负责人二是想把团队从“功能驱动”转向“质量驱动”的leader三是正在规划年度技术路线、需要参考真实案例做决策的同学。我不会只报喜不报忧踩过的坑、走弯路的过程、最后怎么拉回来的都会展开讲。1.2 团队规模与协作模式全知科技技术团队目前稳定在45人左右分为四个小组基础架构组8人、数据平台组12人、业务后端组15人、前端与体验组10人。支撑体系上有独立的QA团队5人和SRE团队4人配合。协作模式上2025年我们从“按项目临时拉人”切换成了“按领域长期固定”的纵队结构——每个纵队负责一个完整的业务域从需求、开发、测试到上线运维端到端负责。这个调整在年中一度引发了不少抵触很多工程师觉得“这不是让我既要写代码又要接工单吗”但半年跑下来效果确实出来了。责任边界清晰之后推诿少了大家对系统的敬畏心也明显上来了。2. 技术演进与架构升级2.1 核心系统从单体走向服务化2025年上半年最重要的一件事是把核心业务系统从单体应用拆分为七个领域服务。这个决策不是拍脑袋而是被数据逼出来的年初核心接口的P99延迟已经涨到1.8秒发布一次全量上线需要40分钟测试环境经常因为资源竞争互相干扰。单体架构的优势简单、直接已经彻底被组织扩张和业务复杂度掩盖。拆分过程分了四步走。第一步是梳理领域边界我们花了三周做事件风暴把业务流程中的领域事件全部列出来再根据聚合根划分服务边界。这里有个关键心得不要一开始就纠结技术细节先让业务人员和核心开发一起把语言对齐边界清晰了后面拆起来自然顺。第二步是数据隔离这是最痛苦的一步——七个服务需要七个独立的数据库 schema光迁移历史数据就出了两次线上事故。第三步是接口定义先行我们用 OpenAPI 规范统一了服务间调用契约每个服务提供方必须先行给出接口文档消费方基于 mock 并行开发。第四步是渐进式切流先在灰度环境跑了两周然后按5%、20%、50%、100%的比例逐步放量。整个过程耗时近四个月但好在最终平稳落地。2.2 数据层重构与读写分离落地数据层是2025年度投入最大的单项。原有的单库单表架构在日均亿级请求量面前已经捉襟见肘慢查询频发连接池经常被打满。我们的方案是分三步走读写分离、分库分表、缓存加速。读写分离是最先落地的。线上主库只承担写流量读流量全部切到三个只读副本。这里必须强调一个容易踩的坑只读副本和主库之间的同步延迟。我们的业务中有一个场景用户下单后立刻查询订单详情经常出现“查不到刚下的单”的诡异问题。解决办法是提供了强制走主库的接口标记只对一致性要求极高的少数场景使用其他读多写少的场景都走副本。分库分表我们选用了 sharding 中间件按照用户ID的哈希值分为32个库每个库128张表。容量评估的依据是单表数据量控制在500万行以内单库容量控制在200GB以内。这样即便未来业务翻五倍也不需要再做二次拆分。缓存层选用了 Redis Cluster热数据命中率从年初的87%提升到现在的96.3%缓存穿透问题通过布隆过滤器前置拦截解决。2.3 可观测性体系建设如果问我2025年最值得的投资是什么我的答案不是某个具体的中间件而是可观测性体系。过去排查问题靠“登录服务器翻日志”效率极低。今年我们统一接入了 Metrics、Logging、Tracing 三件套。Metrics 用的是 Prometheus Grafana覆盖了所有服务的 CPU、内存、QPS、P99 延迟、错误率等基础指标配置了分级告警规则。Logging 统一采集到 ELK并且做了结构化改造——所有日志必须包含 traceId、userId、业务类型三个维度这样按图索骥非常快。Tracing 用的是 Jaeger核心链路全部埋点。这套体系的价值在年中一次大故障中体现得淋漓尽致。某天下午核心支付服务出现延迟飙升监控大屏直接定位到是下游积分服务响应变慢沿着 traceId 十秒钟就看到是积分服务连接 Redis 出现了异常。放在过去这种跨服务问题至少需要半小时起步。3. 核心项目实战复盘3.1 性能优化专项P99延迟从1.8s降到320ms性能优化是2025年的硬仗。年初核心链路 P99 延迟1.8秒双十一预案推演时发现扛不住峰值流量项目组立下军令状要把 P99 压到 400ms 以内。最终我们做到了 320ms超出预期。第一刀砍向数据库。通过慢查询日志分析发现50%的延迟集中在 SQL 上。最典型的一个查询是订单列表页关联查询了七个表用 EXPLAIN 一看三个表没走索引其中一个关联字段的类型都不一致varchar 对 bigint导致全表扫描。修复后单查询从200ms 降到5ms。优化完所有慢查询后整体延迟直接下降40%。第二刀是服务间调用优化。我们清理出13个循环调用链最典型的是 A 调 B、B 调 C、C 又调回 A 的死循环。通过引入异步消息中间件把非强一致性的同步调用改为事件驱动最终削掉了约30%的无效同步等待。第三刀是 JVM 和容器参数调优。这个环节收益最小但也不容忽视。我们将服务堆内存调整到与容器限制匹配避免频繁 Full GC通过观察 GC 日志和对象分配情况定位到几个大对象的频繁创建改为对象复用后GC 停顿时间降低了60%。3.2 稳定性建设从99.9%到99.99%稳定性是今年最强调的指标。年初我们的系统可用性是99.9%换算下来一年允许宕机8.76小时目标提到99.99%一年只允许52.6分钟不可用。这个目标逼着我们做了一堆“反人性”的事情。故障演练是其中的核心手段。每个月做一次随机故障注入可能是杀掉一个 Pod可能是让某个服务返回500可能是把数据库连接池调小。第一次演练的时候团队手忙脚乱花了40分钟才恢复。到了年底最后一次演练从发现故障到恢复只用了4分钟。这套机制的收益不是演练本身而是让每个工程师都形成了“故障就在身边”的警觉。容量规划我们也做了重大调整。过去是“预估峰值然后留两倍冗余”今年改成了“基于历史业务曲线 活动日历做精细化容量预测”。每一次大促前SRE 会拉出过去三次同量级活动的峰值数据叠加业务增长率计算出每个服务的需要扩容的副本数。过程中也踩了坑——有一回低估了某个新增功能带来的流量放大效应导致活动期间 P99 飙红这个教训直接推动我们建立了新功能上线前置压测机制。3.3 数据平台与智能化探索数据平台组2025年的重头戏是实时数仓的落地。我们在 Flink 上构建了实时计算链路把核心业务指标从 T1 提升到秒级。这套系统的核心价值是让运营和决策层能实时看到业务状态而不需要等第二天的报表。离线数仓方面我们做了分层重构将数仓划分为 ODS、DWD、DWS、ADS 四层并统一了指标口径。这里有个很接地气的体会数仓建设最大的难题不是技术而是口径对齐。同一个“活跃用户”市场部、运营部、技术部的定义居然都不一样。我们抽调了业务分析师和数仓工程师组成“指标治理小组”花了两个月把200多个核心指标全部定义清楚沉淀成指标字典后续所有报表都基于这个字典出数。智能化方向上AIGC 的应用我们也落地了几个。知识库问答机器人基于内部文档做了 RAG 增强可以回答大部分运维和业务咨询问题让值班同学从重复性答疑里解放出来。代码生成助手基于企业内部代码库做了微调虽然不能直接生成大段业务逻辑但补全模板代码、生成单元测试框架、辅助重构效率提升非常明显。4. 团队管理、流程改进与文化建设4.1 研发流程从瀑布走向双轨迭代2025年以前我们的研发流程是标准的瀑布式产品出完整 PRD、技术出完整方案、研发一次性开发两个月、然后测试一个月。这种模式在业务变化快的环境下非常被动。今年我们切换为“双轨迭代”一条轨道是确定性强的需求按月度版本走另一条轨道是探索性需求按两周一个迭代走。这个模式带来的最大变化是反馈周期大幅缩短。探索性需求可以在两周内看到用户反馈并快速决定是继续投入还是果断放弃。年中有一个后台管理功能首版做完用户评测反馈极差若按照老流程我们会在两个月后才发现方向错了。双轨模式让我们在两周时就察觉问题及时调整了交互方案和第二版的产品定位。配套变革是引入了 CI/CD 流水线。提交代码后自动触发静态检查、单元测试、构建镜像、部署到测试环境所有步骤跑完不到15分钟。发布操作从手动点击按钮改为流水线自动执行配合灰度发布能力让“随时可发布”成为常态。4.2 质量内建与自动化测试体系质量不能只靠测试团队的最后一关这是2025年我们反复强调的理念。按“质量内建”的要求开发自测环节被提到了前所未有的高度。过去单元测试覆盖率是口头说说年底一统计大概只有20%。今年我们硬性规定核心模块覆盖率不低于80%并把覆盖率指标卡在 CI 流水线里——不达标不允许合入主干。一开始开发同学们怨声载道觉得浪费时间。但坚持到半年后大家自己感觉到了好处回归测试时 bug 明显变少加班修问题的时间大幅减少反而省了时间。接口自动化测试用例从年初的300条增长到年底的3200条。UI 自动化我们也引入了一套基于视觉识别的测试框架可以自动比对页面渲染效果虽然不是所有场景都适用但在核心交互链路上确实起到了防护网的作用。4.3 技术分享与工程师文化建设团队成长是 2025 年我比较欣慰的一块。我们建立了每双周一次的技术分享机制内容不限于当前业务也可以是业界前沿、开源项目源码解读、甚至工程效率工具推荐。分享者由组内轮值不给压力但每周必须有人在台上讲。这套机制跑起来之后产生了不少化学反应。有人在分享中提到的方案解决了另一个组困扰很久的问题有初级工程师通过准备分享把一个领域啃透了半年的时间成长速度肉眼可见。年底我们还在内部分享日上做了一个 Demo Showcase让大家把工作之外自己写的小工具、研究的小项目拿出来展示。最有意思的是一个自动生成接口文档的工具就是工程师自己为了解决手动维护文档的痛点在周末写出来的后来我们直接把它产品化了。5. 年度踩坑实录与解决思路5.1 典型故障复盘任何年度总结如果只写成绩不写教训就是耍流氓。今年我们处理了大小几十起故障挑三个有代表性的复盘。第一个是架构拆分期的数据迁移事故。6月中旬在将订单数据从单库迁移到分库分表集群的过程中因为迁移脚本中一个时间范围判断写错导致了大约20万条历史订单的 user_id 被写成了 NULL。发现时已经过去了三天。复盘根因有两个一是迁移脚本评审只关注了逻辑正确性忽略了空值校验二是没有在迁移后做全量数据校验。修复方案是写了一个离线扫描任务从 binlog 中还原并结合线上补偿修复。这个教训直接推动了“双写校验”机制的建立——任何数据迁移必须同时开启影子校验边迁移边比对。第二个是缓存击穿引发的雪崩。8月某天运营上线了一个秒杀活动热点 Key 集中在几个商品上。缓存过期瞬间大量请求直接打到数据库数据库连接池被打满进而引起服务雪崩。我们当时的限流策略只做了基于 QPS 的单个服务限流缺少全局拓扑感知。事后我们增加了热点 Key 永不过期 异步刷新策略同时上线了分布式限流组件按用户维度进行平滑限流。第三个是发版事故。10月底一个后端版本上线引入了错误的环境变量配置导致线上服务全部连接到测试环境的数据库。由于配置中心在发布时没有关联环境校验整个事故持续了15分钟才被发现。这个事故之后我们在配置中心加了环境变更审批流同时要求所有敏感配置项必须带上环境标签发布时自动校验。5.2 问题排查体系化重复的故障不应该发生两次用制度对抗“低水平重复”。年度后半段我们建立了标准化的故障响应流程MTTA/MTTR追踪每起P1/P2事故必须输出详细的事后报告包含时间线、根因、触发条件、修复动作、改进事项五个部分。我还在内部推行了一个“异常周会”每周五下午各纵队的开发代表带上本周遇到的所有诡异问题、未解之谜、潜在隐患一起过一遍。这个会不追责、不分配任务只做信息同步和难点互帮。好几次跨服务、跨领域的隐患都是在这个会上被提前挖出来的。6. 来年展望与个人心得6.1 2026年的三个技术重点对于来年我有三个明确的技术重点。第一把服务化之后的数据一致性方案做得更扎实。拆分之后分布式事务的问题开始暴露目前我们主要靠事务消息加最终一致性方案兜底但部分场景的补偿逻辑还比较脆弱。明年计划引入 Seata 或自研一套轻量级分布式事务框架并且加强测试覆盖。第二持续提升 AI 在研发流程中的渗透率。代码生成助手目前的使用率只有约30%明年目标是通过Fine-tune和 RAG 增强让它更懂我们的业务上下文把使用率拉到70%以上。也会探索 AI 辅助测试用例生成、AI 辅助故障定位等方向。第三推动服务网格和容器化改造。目前服务间的流量管理还靠硬编码负载均衡明年计划全面接入服务网格把流量控制、熔断降级、链路追踪都下沉到基础设施层。6.2 我的几点体会最后聊几句个人感受这一年如果让我提炼三个关键词那就是聚焦、机制、钝感力。聚焦是因为我们确实砍掉了很多“看上去很美”的需求和项目才换来了核心链路的可靠性。机制是因为任何靠自觉、靠英雄主义的质量保障都是不可持续的只有制度建设才能让团队在没有救火的时候也能跑对方向。钝感力则是我自己最大的收获——故障发生时不焦虑、不甩锅先恢复再复盘。这套心态帮助团队在最高压的几个夜晚也保持了冷静和秩序。2025年对全知科技来说没有惊天动地的技术革命但每一步都踩得扎实。从单体到服务化、从分钟级发布到秒级发布、从可用性99.9%到99.99%这些数字的背后是团队扎扎实实的成长。希望这篇总结能对正在规划同样路线的朋友有参考价值也想听听其他团队在稳定性建设和性能优化上的经验欢迎交流讨论。