如果你也带过一套跑了好几年、动不动就全局宕机的老系统应该能理解我第一次看到这套“智能客户关系AI系统”时的复杂心情。三年前它还只是跑在十几台虚拟机上的Java单体应用十几个业务模块挤在一个进程里客户资料、订单、工单、营销活动、消息通知再加上一个人称“评分引擎”的AI模块一个关系型主库扛着所有读写所谓的“智能”就是每天凌晨定时任务把全量客户数据灌进去跑完客户分群和线索评分两个模型第二天早上业务才能看到结果。这篇复盘是我亲历的三年演进记录从单体一路走到云原生核心围绕“智能”能力的交付速度、系统的稳定性以及架构演进过程中那些文档里从不写的真实坑展开适合正在纠结要不要拆单体、什么时候上容器和编排平台、怎么把AI能力从批处理改造成实时服务的团队参考。1. 拆掉“能跑就行”的单体系统当时到底痛在哪里1.1 三年前那套系统的真实模样我刚接手的时候这套系统跑在15台虚拟机上核心是一个Java单体应用。客户资料管理、订单记录、客服工单、营销活动配置、消息通知这些业务模块全部在一个进程里连前端模板都打包在同一个发布包里。AI模块听起来高端实际实现很朴素每天凌晨两点定时任务启动把前一天全量客户行为数据灌进库跑完客户分群和线索评分两个流程结果写进中间表第二天早上业务团队打开报表才能看。这套架构在系统刚上线那两年是够用的。客户量级在百万左右日活不高模型也只有两三个经典模型。可随着业务增长问题开始密集暴露。首先是数据库所有模块共享同一个MySQL主库客户行为表已经积累了几亿行某条查询没走到索引就能把主库连接池打满。其次AI模块和业务模块在同一个进程里评分任务一跑CPU和内存被吃光在线接口跟着抖动。最难受的是发布十几个模块捆在一个包里任何地方改一行代码整包都要重新测试和发布测试环境部署一次要50分钟生产发布只能挑凌晨一个发布窗口只敢放一个版本。当时的开发节奏是“两周一个小版本、一个月一个大版本”听起来不算慢但真正交付到业务手里的有效功能很少。大部分时间都花在了回归测试、排查“到底是谁改了哪里导致挂掉”这类内耗上。团队里有个同事开玩笑说我们不是在发布就是在准备发布的路上。这句话现在回想起来其实就是架构进入瓶颈期的预兆。1.2 三次事故和一个黄掉的需求让我意识到不能再拖真正让我下定决心的是接二连三的线上事故。第一次是营销活动大促。运营搞了一场全场性的客户回馈活动流量比平时涨了七八倍。单体应用扛不住数据库连接数瞬间打满整个系统对外服务全部不可用持续了40多分钟。更尴尬的是事故期间用户下的单丢了事后对账才发现少了一批数据。第二次是AI批作业和在线业务“打架”。凌晨跑评分任务大批量扫描客户行为表把数据库读写吞吐全部耗尽导致白天高峰时段的客户列表查询、工单流转全部变慢客服体验一落千丈。业务方上午十点冲过来问你们这个智能系统到底什么时候能跑完第三次是报表慢查询把主库打崩。运营想看一份客户分群统计手写SQL全表扫描直接拖死主库。那次之后我彻底明白不是某一个模块有问题而是整个架构的耦合程度已经到了物理极限。任何一个模块抖动都会传导到所有功能上。如果说事故是“存量压力”那更致命的是“增量需求”。业务方对新AI能力的诉求越来越多实时线索评分客户留资后几秒钟就要给出评分和建议动作会话质检分析客服聊天记录的情绪和意图还有个性化推荐排序。这些需求放在老架构里没有任何一个能在两周内交付因为数据和功能都被锁死在那张行为大表和那个单体进程里。最让我触动的是一个黄掉的需求产品经理提出做一个“实时客户意图识别”我粗略估算按老架构的节奏最少要两个月他等不及需求就黄了。那一刻我很清醒——不是团队不给力是架构不给力。1.3 动手前先对齐的三件事拆单体这种动作从来不是纯技术问题。很多团队死在没对齐就动手上。我做的第一件事不是画架构图而是拉着业务方、产品、团队把三件事讲清楚。第一转型不是因为“微服务时髦”而是因为业务侧的变更频率和AI功能交付速度已经远超单体架构的承受范围。这个理由必须让业务听得懂否则一旦进入转型阵痛期业务方就会质疑投入。第二目标是“降低变更风险和恢复成本”不是“追求技术名词”。云原生、容器化、编排平台都是手段我们定的验收口径很朴素发布从凌晨窗口变成随时可发单个服务故障不拖垮全局AI评分时效从T1变成分钟级甚至秒级。第三这是一场持续三年的工程能力建设不是三个月能出结果的短期项目。组织、考核、责权都要跟着调整。如果这三件事没有对齐半途而废的概率极高。这三句话对齐之后我才开始排技术路线。后来的实践证明这个“先对齐再动手”的顺序极大地减少了转型过程中的内部阻力。2. 三年路线图怎么定先救火再拆墙最后谈原生2.1 三阶段路线止血、拆墙、上云三年规划我分了三个阶段每个阶段目标完全不一样。这个顺序后来我在其他项目里也复用基本逻辑是先让系统别天天出事再把耦合拆开最后才谈得上云原生的弹性和平台化。第一阶段叫止血0到6个月。目标只有一个线上别再生大事故。做法不炫技就是补齐监控、打通告警、做一轮容量评估、把最容易出问题的大表和慢查询优化掉发布流程从晚上手工操作改成双人复核加上基本的自动化检查。第二阶段叫拆墙6到18个月。目标是把业务能力和AI能力从单体里按业务域拆出来每个服务独立部署、独立数据库。这一阶段最累但也是后面容器化能顺利推进的前提。第三阶段叫上云18到36个月。容器化、上Kubernetes、可观测性体系、灰度发布、弹性伸缩都在这一阶段落地。到这一步系统才真正接近云原生形态。三个阶段的硬性指标我贴在办公室墙上故障恢复时间从小时级降到分钟级需求交付周期从三周压到一周以内AI评分时效从T1变成分钟级单次发布失败率低于1%。指标不多但每一个都能被度量。阶段时间范围核心目标关键交付止血0-6个月线上稳定不再全局宕机监控告警、容量治理、发布流程规范化拆墙6-18个月按业务域拆出独立服务、拆分数据库15个左右微服务、事件驱动链路、AI服务化上云18-36个月容器化、K8s编排、可观测性、灰度弹性扩缩容、平台化交付、分钟级发布2.2 为什么我们没选择推倒重来很多人问我三年都够重构两次了为什么不直接重写一套我有两个判断。第一业务不停。老系统里跑着全量客户资料和订单数据每天都有真实用户依赖它。重写意味着要么长时间双系统并行要么找一个窗口做切换这两个动作的善后成本远超我最乐观的估计。我更倾向于用绞杀者模式一点一点替换。第二团队节奏。当时团队不到二十人既有Java后端、又有算法工程师、前端和测试。如果直接推倒重来大家要同时学习微服务、容器、编排、数据迁移学习和交付的负荷叠在一起大概率两头都完蛋。先把老系统稳住用绞杀者方式慢慢拆团队可以在每个阶段只学一个新东西心理压力小踩坑空间也小。绞杀者模式的执行原则很简单新功能不走老系统直接在目标架构里实现老功能按优先级一个一个被新服务替代每个被替代的功能做双跑验证确认没问题再切换流量。这样系统是渐进式地“死掉”的业务方几乎无感知。我们在第二年做的线索评分服务迁移就是这个模式最典型的一次落地。2.3 技术选型里的几次反向决策技术选型这件事最常见的错误不是选错而是追新。我在这三年里做了几个和同行“常规操作”不太一样的决定事后看价值很大。第一没有一开始就上Kubernetes。很多人一听云原生就直奔K8s但我们把容器化放到了第18个月之后。原因很简单当时服务还没拆出来代码里到处都是本地状态和单例依赖直接容器化会遇到一堆和调度无关的破事。先把服务拆干净把状态外置容器化难度会指数级下降。第二没有全面铺服务网格。服务网格的优点是把基础设施和业务解耦代价是引入一整套新的运维复杂度。我们的服务规模一度维持在二三十个用成熟的注册中心加客户端负载均衡已经足够顺滑没必要为了“架构先进”去背服务网格的成本。第三在消息中间件上选成熟方案而不是最热议的方案。我们希望消息通道能承载全量客户行为事件需要高吞吐、能回溯、生态成熟选型时没有纠结直接锁定Kafka这类久经考验的消息中间件。事后证明在处理几亿条行为事件时它的稳定性和数据保留能力帮了大忙。第四开发框架保留Java技术栈。团队主力就是Java工程师为了微服务去引入一套全新语言栈短期内得不偿失。云原生并不要求你必须换掉开发语言Java在云生态下的支持同样成熟。我们要做的只是把框架用得更克制把服务边界理得更清楚。3. 从单体里往外拆那些被低估的脏活累活3.1 拆服务先拆哪一类最划算拆服务的顺序如果搞错后面全是坑。我们定的优先级有三个判断标准变更频率、依赖复杂度、故障影响面。变更越频繁、故障影响面越大的模块理论上越该优先拆但依赖太深、离核心数据太近的模块拆起来代价太大反而应该放后。按这个标准第一批拆出来的是短信通知服务、资质校验服务、操作日志服务。这些模块和外部系统有交互和核心业务耦合相对浅拆出来后能立刻解决“改个短信渠道要重新发整包”这种低级痛点还能让团队在几个真实的发布周期里跑通“独立部署、独立运维”的流程。第二批才是客户资料服务、订单记录服务这类核心域。这些模块离那张大表太近必须先动数据库才能动服务所以我们把数据库拆分和这一批服务绑定在一起做每拆一个服务就同时把对应数据迁走。这个顺序凡是经历过的人都懂服务拆分真正难的不是代码是数据。第三批是AI能力。把“评分引擎”从批处理模块里彻底解耦做成独立的推理服务是第三年才完成的。先拆外围、再拆核心、最后动AI整个过程像一场手术切一刀、观察一下、再切下一刀。3.2 数据库拆分先逻辑隔离再物理隔离双写校验一步不能少数据库拆分是整个转型里最疼、返工成本最高的一步。我们没敢一上来就直接物理拆库而是走了三步。第一步是逻辑隔离。数据库不拆但按业务域建不同schema表归属清晰应用层通过不同账号和连接池访问。这一步成本较低但让团队养成“域边界”意识也为后面物理拆库铺路。第二步是物理隔离加双写。每个服务有了自己的独立数据库后应用层开始双写新库和旧库同时写读仍然走旧库等数据稳定后再切换读流量。双写的实现方式一开始写在了业务代码里维护成本高后来发现不如直接订阅旧库的变更日志在新存储里重放更省心。这个方案既能保证新库实时拿到数据又不需要改老系统那套复杂的事务逻辑。第三步是数据校验和补偿。双写期间每天凌晨跑一次对账任务比较新旧两库关键表的行数和哈希值对不上就报警。我们经历过的最常见情况是异步写丢消息或者历史数据本身就不干净这时候以业务原始数据为准做补偿回写。数据库拆分这件事我想强调一个原则永远不要在一天之内完成切换。每个表的迁移都要经历“双写、对比、切读、删旧”四个步骤每一步留出至少几天观察期。业务侧不需要知道底层发生了什么他们要的只是别出新数据错误。3.3 AI能力改造从24小时一次批处理到分钟级实时评分这个项目叫“智能客户关系AI系统”AI能力的改造是主线也是最有意思的部分。老架构里客户分群、线索评分都是从一张行为大表全量扫描开始的每天一次T1给结果。在业务眼里这个“智能”实在有点迟钝客户昨天在网站上看完产品没下单今天早上销售打电话过去系统给的评分还停留在三天前。我们用了两个台阶来解决。第一个台阶是把批处理改成事件驱动。客户的行为浏览、点击、收藏、加购通过埋点源源不断产生过去是攒一天再算现在行为事件实时进消息队列评分服务订阅事件流增量完成特征更新和评分重算。这个改动不需要特别复杂的算法却把评分新鲜度从24小时直接压到分钟级。业务侧感知最强烈销售再也不用等凌晨批处理跑完客户刚有动作评分很快就变。第二个台阶是让推理从离线走到在线。我们把特征工程收拢到一个统一的特征服务里线上接口要算分时直接调特征服务拿数据再喂给推理服务。模型管理也从“一个模型文件放服务器上”变成带版本、带灰度策略的模型仓库。新模型上线先跑影子流量和旧模型打分做对比一致率超过阈值才灰度放量。设计这三个台阶时我反复强调一个理念架构要支持的不仅是模型精度更是模型的迭代速度。算法工程师的价值不应该消耗在“怎么把模型装到线上”上而应该消耗在“怎么把模型效果做得更好”上。特征服务、模型版本管理、灰度评估这套底座就是帮他们省掉前者的时间。3.4 一次典型拆分实操记录线索评分服务讲一个具体的拆分过程方便大家对照。我们第二年上半年拆了线索评分服务这是AI模块里最核心的一块。整个流程分六步。第一步梳理接口清单。把单体里和线索评分相关的入参、出参、依赖表全部列出来画清调用关系。这一步看着简单实际最花时间因为老代码里很多调用是隐式的比如某个工具类里直接查了别的模块的表。第二步抽代码。把评分逻辑连同它依赖的特征计算全部搬到一个新工程里依赖用接口隔离不再直接查别的模块的表。第三步独立数据库。评分结果表单独建库应用通过新的连接池访问。第四步双跑对比。新旧两套评分逻辑同时跑每天对比输出结果一致率必须超过预设阈值我们的线是99.5%。低于这个数就查原因这一阶段我们发现过几个偏差老代码里有一个浮点运算精度问题还有一个时区处理不一致双跑把这些潜在bug全暴露出来了。第五步切流量。把线上调用逐步从老接口切到新服务先切1%确认稳了再10%、50%、100%。第六步删旧代码。整个切完后老代码连同它依赖的中间表才被清理。这六步里最容易被低估的是第四步双跑对比。它能帮你发现大量隐藏在旧代码里的“潜规则”这些规则文档里根本没有全靠对跑结果逼出来。团队每次都说“再也不想做双跑了”但每次做完都承认没有双跑就贸然切流量线上迟早要出事。4. 云原生基础设施落地容器化、编排平台与可观测性4.1 容器化改造的三个坑每一个都踩得实实在在到第18个月服务和数据都拆得差不多了我们才敢动容器化。这一阶段我印象最深的是三个坑。第一个坑是本地状态。单体时代大量状态藏在进程里用户登录session放在本地内存临时文件写在服务器本地磁盘定时任务依赖节点本地的cron配置。容器化要求所有实例随时可以被销毁、重建这些“本地状态”全部成了定时炸弹。我们花了大量时间把session外置成无态令牌把临时文件改成对象存储把定时任务收敛到统一的调度平台。这一步清理很枯燥但不做的话容器一重建就丢状态线上必然出事。第二个坑是JVM和容器资源限制打架。Java应用在容器里跑如果不告诉JVM容器给了多少内存JVM会按宿主机内存来初始化堆大小很容易被CGroup限制直接OOM Kill。我们踩过很多次“进程没了但监控显示内存没用满”的诡异现象后来统一在镜像里显式配置JVM内存参数问题立刻消失。第三个坑是镜像构建和启动速度。刚开始一个镜像构建要十几分钟发布一次等半天团队怨声载道。我们做了三件事基础镜像瘦身只保留运行时依赖层缓存代码变更不重新下载依赖启动脚本里加健康检查和预热确保流量进来之前服务已经真正就绪。启动时间从三分钟压到几十秒发布体验完全不一样。4.2 为什么我们到第18个月才上Kubernetes这个问题被同行问过很多次。答案不是“我们落后”而是“顺序比速度重要”。Kubernetes能力再强它解决的是部署和调度问题而当时我们最大的问题根本不在部署而在耦合。服务没拆干净、数据库没分好直接上K8s等于给一辆还没修好底盘的赛车换高级发动机。团队在止血和拆墙阶段积累的配置管理、日志处理、发布流程经验到了容器编排阶段全都能用上。上K8s的时候我们做了比较充分的前期准备。Namespace按环境和服务域划分资源和配额提前规划存储这边先接好共享存储网络方面把集群方案和生产环境拓扑想清楚再动手。基础设施团队先把一套测试集群跑了三个月把扩容、缩容、驱逐、故障恢复这些场景全演练过才把生产业务一个个搬进去。上了K8s之后收益立竿见影的是弹性。之前大促要提前一个月申请资源、手动扩容虚拟机现在评分服务、消息消费者这类对流量敏感的工作负载直接通过资源指标配置自动伸缩流量一涨副本自动加流量回落自动减。有一年大促评分服务的副本数从20个自动涨到120个再回落到正常值全程没有人值班干预这在老架构里是不可想象的。4.3 可观测性日志、指标、链路追踪一个都不能少老架构时期排查问题基本靠“去服务器上翻日志”grep一串关键字找半天。服务拆成几十个之后这种土办法彻底失效——一个请求往往要经过四五个服务出了问题你都不知道去哪台机器找日志。所以我们建设了完整的三件套。日志统一收集、集中检索指标采集方面把关键服务的延迟、流量、错误率、饱和度按黄金四指标监测链路追踪贯穿所有服务每个请求生成全局TraceId一次调用从头到尾的完整路径都能串起来。建设过程中最真实的教训是成本和效率的平衡。日志全量收集很爽但存储账单会很吓人链路全量采样开销又大。我们最终做了分级核心交易链路全量采样其他链路按比例采样日志按重要级别区分保存周期。这套策略让可观测性既没掏空预算又保住了关键链路上的排查能力。4.4 发布风控从凌晨发版到随时灰度单体时代发布是“仪式”凌晨两点、双人复核、全量切换一次失败就要回滚很久。云原生之后发布变成了日常操作。这个转变背后是三个能力的组合。特性开关。新功能默认关闭在线上验证通过后再对部分用户放量。开关配置中心化不需要改代码、重新发版。团队可以在新功能出问题时一键关掉而不是紧急回滚。金丝雀发布。新版本先部署一组实例导入少量流量观察错误率和延迟稳定了再逐步放量。我们把自动化的健康检查和指标卡点内置到发布流水线某个指标超阈值就自动暂停发布把风险隔离在最早阶段。快速回滚。K8s的滚动发布天然支持版本回退一个命令就能回到上一个稳定版本。我们不止一次在大促前的发布里用到了回滚因为“宁可没发上去也不可有问题留到线上”。# 查看滚动发布状态 kubectl rollout status deployment/scoring-service -n prod # 异常时回滚到上一个版本 kubectl rollout undo deployment/scoring-service -n prod发布从“凌晨的仪式”变成“白天的日常”靠的就是这三个能力叠加出的可控性。业务方后来最常说的一句话是你们怎么白天也敢发版了这句话背后的变化比任何架构指标都更有说服力。5. 三年踩坑实录从分布式事务到团队协作5.1 分布式事务别硬做学会计账服务拆开之后第一个技术债就是分布式事务。比如创建客户资料的同时要初始化评分档案老代码里一个本地事务就能搞定拆成两个服务后怎么办很多团队第一反应是上强一致分布式事务方案。我们评估后放弃了这个念头原因很简单跨服务、跨数据库的强一致方案性能和复杂度代价极高而且我们绝大多数场景根本不需要实时一致。最终用的是本地消息表也就是常说的Outbox模式。核心逻辑是A服务在自己的数据库里完成业务操作的同时写一条“待发布事件”到本地表两个动作在同一个本地事务里完成然后由一个小程序把待发布事件读出来投递到消息队列B服务订阅并处理。这样既保证“业务状态和事件不会丢”又避开了跨库强一致这个无底洞。这个模式第一次听会觉得绕但它用最终一致性换来了极强的可落地性。客户资料、评分档案、营销活动这几类场景我们全用这套。真正需要实时一致的场景反而越想越少——绝大多数业务接受几秒钟的延迟完全没问题。5.2 双写一致性校验的真相拆库期间双写是常态但双写的核心难题不是“能不能写对”而是“怎么证明写对了”。我们每天跑对账任务对比新旧库。一开始只对行数和主键后来发现不够因为内容可能不同但行数一样。于是升级成对关键字段的哈希和值。再后来发现光对比还不够还要能定位到具体哪条记录不对于是对账任务输出差异清单触发补偿流程。真实世界里对账系统比想象中更容易碰到脏数据。比如历史数据里有些客户的手机号本来就是空的有些记录的创建时间戳格式不统一这些脏数据在双写对比时会产生大量噪音。处理噪音需要专门的清洗规则否则对账任务每天报警慢慢就没人看了。我的经验是对账任务必须支持“已知噪音白名单”让报警回归到有价值的信息上。5.3 团队协作模式的转变比技术更难三年转型里最难的其实不是技术而是团队的协作习惯。单体时代团队按功能分后端、前端、算法、测试各管一摊。拆成微服务后必须按领域分客户域团队、订单域团队、AI平台团队。每个领域团队对自己的服务全权负责从设计、开发、测试到上线、运维、值班一条龙。这一步初期非常痛苦工程师过去只写代码现在要学着看监控、盯告警、处理线上问题。但坚持下来后大家的责任感和能力都上来了。同时我们配了平台小组专门维护基础设施、流水线、K8s集群。为什么必须有个平台小组因为让每个业务团队自己搭一套云原生基础设施既不现实也容易乱。业务团队和平台团队的分工像城市里的住户和物业住户在自己家里怎么装修都行但公共水电网络必须有人统一维护。还有一个容易被误判的点拆了微服务不等于团队就能并行独立交付。如果领域边界不清楚接口改了没人通知一样互相踩脚。所以接口契约管理、变更通知机制、兼容性检查这些是团队习惯问题不是纯工具问题。我们后来强制要求所有对外接口变更必须发变更通知并在一周内保持向后兼容这个规矩让并行开发的摩擦小了很多。5.4 三年踩坑高频问题速查表做这种长周期转型很多问题其实是共性的。我把被问最多、也最值得写下来的问题整理成一张表希望能帮后来的人少走几步弯路。症状常见原因排查思路与解法测试环境经常被“污染”一跑就挂多团队共用一套环境配置和数据互相覆盖按团队拆分隔离环境不稳定服务用容器按需拉起某个服务突然OOM被杀JVM堆配置和容器Limit不一致显式设置JVM内存参数Heap不超过容器Limit的70%双写后数据对不上异步消息丢失或历史脏数据对账任务加差异清单、补偿流程、噪音白名单切流量后偶发接口报错新服务缺少旧代码里的隐式逻辑拉长双跑对比周期把一致性阈值调高再切发布速度变慢镜像太大、依赖重复下载基础镜像瘦身、依赖层缓存、健康检查前置微服务太多排障困难缺少链路追踪全局TraceId串联调用链核心链路全量采样不知道哪个团队改了我依赖的接口接口契约没管理接口变更走评审结果发到统一契约平台并通知订阅方6. 一些回头看的心得三年下来最大的体会是架构演进不是为了在技术简历上多几个名词而是为了让系统在业务增长面前不从内部崩溃。单体和微服务、虚拟机和容器、批处理和实时这些二元对立在具体业务里从来没有标准答案只有“当下合不合适”。我们三年里很多决策在外部看起来是激进的但执行上每一步都尽量保守该双跑的绝不切流量该验证的绝不靠直觉。如果让我对正在犹豫要不要转型的团队说三句话我会说第一先把监控和发布流程做好再谈架构升级止血永远在拆墙之前。第二拆服务最大的成本在数据和团队协作不在代码别用写代码的思维规划整个项目。第三AI是这轮架构升级最好的应用场景也是最需要架构支撑的场景——没有特征服务、模型版本管理和灰度评估这些底座算法研究得再深也落不了地。最后分享一个小技巧在每个阶段结束时一定要留出一周做“架构复盘”把当时为什么这么拆、哪些判断错了、下个阶段怎么调整写成一页纸。这一页纸的价值在第三年会超出你的想象——当团队新成员问你“为什么我们的服务边界长这样”的时候你不需要从头讲一遍三年只需要让他看那几页纸就够了。
