AI系统微服务化：从单体架构到服务拆分的实战指南

1. 单体架构在处理AI负载时的真实瓶颈：不只是“性能不够”

很多团队在讨论“从单体到微服务”的时候，第一个跳出来的理由都是“性能不够”。但我在实际参与大规模AI系统部署之后，感受最深的一点是：单体架构对AI负载的制约，远不只是慢，而是从资源效率、发布节奏到故障爆炸半径，全链路都在拖后腿。如果不把这几层问题看清楚，就算勉强拆成微服务，也只是把单体的问题复制成多份。

1.1 模型推理与业务逻辑耦合的连锁反应

先看一个最常见的单体AI系统长什么样。一个服务进程里，既有用户请求的解析、鉴权、业务参数校验，又有特征拼接、模型推理、结果后处理，可能还顺带做了结果落库和通知回调。这种架构在流量小、模型少的时候没什么问题，但它把两类生命周期完全不同的代码绑死在了一起。

业务逻辑的特点是变化频繁。产品经理今天要加一个拦截规则，明天要改一个排序策略，每周都有两三次上线。模型推理的特点是重、慢、对资源敏感，而且模型本身迭代周期长，训练一次要好几天，几周才更新一个版本。当这两类代码在同一个进程里时，模型推理时的内存峰值、GPU算力竞争，都会直接影响业务接口的响应时间；反过来，业务侧一次不谨慎的改动，也可能把整个推理服务拖崩。

我见过一个很典型的案例：某内容推荐系统的单体服务里，业务团队为了修复一个用户维度的bug，在请求中间加了一段全量用户画像的查询逻辑，结果这段逻辑把分配给推理线程的CPU时间片抢走了大半，线上推荐接口的P99时延从200毫秒涨到了1.2秒，连带排队请求把内存也打满了，最后整个服务OOM重启。排查的时候，算法团队和业务团队互相都觉得是对方的锅，因为日志都在同一个进程里，实在很难快速界定责任边界。

1.2 资源利用率的浪费：GPU吃不满，CPU在空转

单体的另一个痛点是资源调度颗粒度太粗。一个进程包含了所有功能模块，扩容时只能整体扩容。但在一个AI系统里，不同模块对资源的需求是完全错配的：

• 模型推理模块需要GPU，而且对显存和算力要求极高；
• 特征计算模块是CPU密集型的，主要消耗CPU时间和内存带宽；
• 接口网关和业务校验模块是IO密集型的，大部分时间在等数据库、等Redis、等下游接口返回。

把这些模块塞在同一个进程里，意味着扩容一台机器，就得同时配齐这台机器的CPU、内存、GPU。结果往往是：为了满足推理模块的GPU需求，多买了很多CPU和内存；为了满足业务模块的扩容需求，多买了很多GPU。你问运维同事GPU利用率怎么样，他查完监控说“平均不到30%”，但你问CPU是不是够用，他又说“经常告警”。钱花了，资源还是不够，这就是单体架构的尴尬。

拆成微服务之后，每个服务可以按自己的瓶颈维度独立扩缩容。推理服务卡GPU就加GPU节点，特征服务CPU告警就加CPU节点，网关连接数打满就加普通ECS。同样一批业务量，硬件总成本往往能降30%以上，这是我在多个项目里实测下来的结论。

1.3 发布与扩容的最小单位太大

单体架构还有一个容易被低估的问题：发布影响面。一个服务承载了十多个功能模块，任何一个模块的变更，都要重新构建整个服务镜像，然后滚动发布全部副本。一次发布，参与验证的不只是这个模块的用例，而是整个系统的回归用例。

我在一次大版本升级时就踩过这种坑。当时为了升级一个TensorFlow的运行时版本，原本以为只是推理模块的事，结果因为业务代码里有一段旧API被废弃了，导致整个服务在启动阶段就初始化失败。那次事故的恢复用了将近40分钟，因为回滚也不是简单的一条命令，而是要把整个镜像切回旧版本，再等全部实例拉取镜像、重新加载模型，期间用户请求全部失败。

在大规模AI系统里，这种发布粒度粗的问题会被进一步放大。模型文件动辄几个GB，实例启动时要加载模型、预热显存，一个副本从拉镜像到Ready可能就要5到10分钟。如果你还需要同时发布业务代码，等于把模型加载的时间成倍叠加到了每次发布里。拆成微服务之后，模型推理服务可以单独发布、单独回滚，业务服务发得再频繁也不会影响到模型加载流程，这才是两者分家的核心价值。

2. 服务拆分之前先想清楚：AI系统中的微服务边界怎么划

很多团队拆微服务，一上来就按功能模块画了一张大图：用户服务、订单服务、推荐服务、模型服务……看起来井井有条，落地的时候却发现每个服务的调用关系变成了一张蜘蛛网，查一个问题要跨五六个服务翻日志。AI系统的微服务拆分，尤其不能照搬普通业务系统的划分方式，因为AI系统里最重的那个“模型推理”环节，跟传统业务服务的运行模型完全不一样。

2.1 按模型能力拆分：一个模型一个服务，还是共享服务？

先回答一个最常见的问题：一个模型对应一个微服务，还是多个模型共用一个服务？

我的建议是，优先按模型的运行特征和更新频率来分组，而不是机械地“一个模型一个服务”。

有些模型是常驻型的基础模型，比如用户向量化模型、通用文本分类模型，它们平时始终被调用、更新频率低、单次推理时延要求高。这类模型可以合并到一个推理服务里，进程启动时一次性加载全部模型到显存，请求进来时按模型ID分发到对应的推理线程。这样可以最大化显存利用率，避免每个模型一个服务导致显存碎片化。

另一些模型是重型模型，比如百亿参数的大模型、多模态生成模型，这类模型单是加载就要占几十GB显存，推理一次要几百毫秒甚至几秒。这种模型必须独占一个服务，占用的那一批GPU节点也是独占的。如果你把这种重型模型和轻量模型混在一个服务里，轻量请求会被重型推理的任务排队拖到超时，重型模型的显存压力又会频繁触发轻量模型的显存回收，两边都体验不好。

我还建议把模型服务内部再做一个轻量层的“模型网关”，由这个网关统一接收上游请求，再转发到具体的模型实例上执行。网关不需要做复杂的业务逻辑，它只负责三件事：路由（根据模型ID找到有副本的实例池）、限流（保护GPU不被超发请求打爆）、超时控制（每个模型单独配置超时阈值）。这一层看起来多了一次跳转，但它让上层调用方不需要关心模型实例的地址和扩缩容状态，也方便做A/B测试和模型灰度。

2.2 按流量特征拆分：在线推理与离线批处理的隔离

AI系统里有一类很典型的流量冲突：在线推理和离线批处理争抢同一批资源。

在线推理的场景，是用户发起一个请求，需要实时返回结果。这个场景对时延极其敏感，P95超过800毫秒用户就能感知到“卡”。离线批处理的场景，则是每隔一段时间跑一次全量数据计算，比如晚上对一天积累的日志做一次用户画像更新，或者对一批新增内容做批量打标。这类任务对时延几乎无要求，但对吞吐量有要求，恨不得把整张GPU卡的计算能力全占满。

如果这两类流量共用一个服务，最常见的现象是：白天在线流量平稳时，批处理任务在后台跑着，把GPU的算力吃掉了大半，在线推理的响应时间莫名上涨；晚上批处理任务集中高峰期，如果在线流量也有波动，两者就开始互相抢显存。

所以在拆分微服务时，我一定建议把离在线彻底隔离。离线批处理任务单独部署一套服务，甚至可以单独用一批低优先级节点，让它跑在空闲时段或者抢占式实例上。在线推理服务则要保证资源是独占的，不允许后台任务混部。这个原则，跟分布式系统里的“关键路径隔离缓冲”是一个道理。

2.3 按团队职责拆分：算法、平台、应用三层边界

除了按技术特征拆，还要考虑组织架构。如果你的算法团队、平台团队、应用团队是独立运作的，微服务的边界最好也跟团队职责对齐，否则“代码归属权”的问题会在后续协作里反复撕扯。

我常用的拆分维度是三层的：

第一层是应用层。这一层直面产品，负责业务逻辑的编排、用户交互、外部系统对接。它不关心模型内部怎么推理，只关心“调用一个服务能拿到结果”。这一层适合按业务域拆，比如内容服务、用户服务、推荐编排服务等。

第二层是模型推理层。这一层归算法平台团队管，负责模型的加载、推理、版本切换、GPU资源调度。这一层向上层暴露的接口是模型服务接口，要定义好输入输出的数据格式、错误码、限流策略。

第三层是底座的公共层。包括特征存储、模型仓库、数据集服务、监控告警和日志系统。这些能力以代码库或内部组件的形式提供给上层调用，一般不直接暴露业务接口。

这种三层拆法想让每个团队都有清晰的“领地边界”，也让每一次跨层调用有明确的契约。比如应用层想调用某个模型，不需要去了解那台GPU机器上环境配好没有，只需要通过模型网关拿到一个标准化的推理结果。模型层想发布新版本，也不需要跟每个业务方对齐接口，只要保证网关契约不变。

2.4 微服务之间的通信与协议选型

拆分之后，服务之间的通信方式也要专门设计。AI系统里的服务间调用，不像纯Web后台那样只是轻量JSON，往往涉及大体积的特征数据、向量数据甚至图像数据。如果在每个调用点都走HTTP+JSON，序列化和网络传输的开销会吃掉大量时延预算。

我个人的实践是分层混用：对外部或应用层，走HTTP/JSON，方便调试和兼容；对内部高频调用，走gRPC+Protocol Buffers，减少序列化开销，支持流式传输；对模型服务这种需要传张量数据的场景，直接用共享内存或者RDMA这类高性能通道，避免底层数据反复拷贝。

通信方式定好之后，还需要统一约定链路透传字段，比如traceId、userId、模型版本号。这些字段要由网关在入口处生成，并在所有服务之间传递。没有这套约定，微服务拆完之后你连一次完整请求都串不起来，排查问题会非常痛苦。

3. 从单体到微服务的演进路线图：先并行，再切换，后拆分

拆分微服务最忌惮的一件事，就是“推倒重来”。抛开那些从0起步的新项目不说，存量单体系统做架构演进，必须采用渐进式的绞杀者模式，让新老系统在相当长一段时间内并行运行，通过流量切换逐步完成迁移。这个过程走得好，风险是可控的；走得太急，很容易在某个晚上把用户请求全部切到新系统，结果新系统的隐藏问题集中爆发，整条业务线陪葬。

3.1 不要一来就重构：先做请求链路梳理

动手拆分之前，我强烈建议先花一两周时间，把单体系统的请求链路完整梳理一遍。梳理的目标不是画一张架构图就完了，而是要回答这几个问题：

• 一条完整请求，从入口到落库，经过了哪些模块？
• 哪些模块是纯计算、无状态的，哪些模块依赖本地文件或内存缓存？
• 哪些模块访问数据库、消息队列、外部服务，访问频率是多少？
• 哪些模块之间存在共享的可变数据，比如共享的内存cache、共享的数据表？

这一步骤怎么看都像是“文档工作”，但它决定了后续拆分的顺序和边界。我曾经在一个项目里跳过这一步，凭直觉先拆了“看着最独立”的短信通知模块，拆完之后才发现这个模块内部直接读了用户表，跟用户服务的耦合远比想象中深，最后不得不返工。

建议输出一张“模块依赖矩阵”，用表格列清楚每个模块被谁调用、调用了谁、共享了什么数据。有了这张表，你就知道哪些模块应该优先拆、哪些模块要等数据解耦之后才能动、哪些模块其实可以在新系统里直接重写而不是迁移。

3.2 第一阶段：模型推理独立成服务

多数AI单体系统里，模型推理模块是最容易也最应该独立出去的。原因有三条：

• 它跟业务逻辑的交互方式相对标准化，无非就是“传进来一批特征，返回一个结果”；
• 它占用的资源类型跟其他模块完全不一样，独立出去之后能立刻看到资源调度的优化空间；
• 它的迭代节奏跟业务逻辑完全不同，独立出去之后两边的上线频率就解耦了。

独立的方式是：在单体系统里挖出一个“推理客户端”，把原来直接调用的推理方法替换成HTTP或gRPC调用新的推理服务。新服务先跟单体系统并行运行，单体里保留旧逻辑作为兜底。刚开始可以只切一小部分流量到新服务，比如先切5%，用监控对比新旧两边的时延和结果一致性，跑几天确认稳定后再逐步放量到100%。

这个过程最需要关注的是超时配置。原来在单体内部调用推理函数，最坏情况只是线程阻塞；现在变成了网络调用，就要面对连接超时、读超时、服务端排队、网络抖动等一系列新问题。我在第一次迁移时把推理服务网关的超时时间设成了5秒，结果流量高峰时客户端排队严重，大量请求在网关层被积压，最后超过5秒的请求全部被客户端断开，引发了一波雪崩。后来我学到的经验是：网关的超时时间一定要比调用方的超时时间短，给调用方留出错后重试的缓冲。

3.3 第二阶段：业务能力模块化，数据解耦

推理服务独立之后，单体系统剩下的部分也是一个大胖子，接下来要做的是把业务能力模块化。

这一阶段的核心不是“把这部分代码复制到一个新服务里”，而是“把数据边界先划分清楚”。很多团队拆服务时死在数据上：代码拆了两套服务，但两个服务还共用一个数据库表，结果只能在服务里各写一套SQL，遇到表结构变更时两边一起改，改完又发现数据不一致。

正确做法是：在迁移某个业务模块之前，先把它的数据结构从单体数据库里分离出来。分离的方式有两种，一种是新建独立库表，通过数据同步任务把旧数据迁移过来；另一种是维持共享库，但把表的读写权限按服务划分，禁止跨服务直接访问。

我在一个用户画像系统的演进里用了第二种方式。先把用户标签计算的代码独立成标签服务，但标签数据还在原来的库里。标签服务通过消息队列消费用户行为事件，异步更新标签表；业务后台则通过API读取标签，不再直接连库。这样做了两个月，数据链路稳定了，才把标签表物理迁移到标签服务自己的数据库里。整个过程用户无感知，灰度回滚也容易。

3.4 第三阶段：基础设施和流量治理升级

服务拆得多了，原来的部署方式和调用方式也会遇到瓶颈。这个阶段要补齐的是一套微服务的基础设施，包括服务注册发现、负载均衡、配置中心、熔断降级、链路追踪。

很多团队在第二阶段的某个时间点发现：服务多了之后，运维手动维护每个服务的IP列表已经不可行了。这时候就应该引入服务注册中心。我推荐用Kubernetes原生的Service机制，再配合Ingress网关做南北向流量的接入，内部服务间调用则通过Kubernetes DNS做服务发现，配合gRPC自带的负载均衡策略。如果团队暂时没有Kubernetes的条件，用Consul或Nacos这类注册中心也能解决服务发现问题，但后续的弹性伸缩和故障恢复能力会弱不少。

流量治理这一块，重点是把限流、熔断、降级的配置从代码里抽出来，放到配置中心统一管理。AI系统有个特殊点：推理服务的算力是有上限的，而且GPU资源非常贵，不可能像普通无状态服务一样随便扩容。所以推理服务的限流策略要尤其保守，宁可拒绝一部分请求，也不要把全部请求都放进来导致服务整体雪崩。我在推理网关里给每个模型配置了独立的QPS阈值和队列长度，超过阈值的请求直接返回“繁忙”错误码，让上层业务自己做降级或者排队，实测下来整个系统的稳定性提升了不止一个台阶。

3.5 演进中的数据一致性设计

微服务拆完之后，最让人头疼的问题之一就是数据一致性。原来在单体架构里，一个请求的事务可以在同一个数据库连接里提交，要么全成功，要么全回滚；现在跨了服务，就没有这种“本地事务”的保障了。

以推荐系统为例：用户在App里点击了一个内容，这个行为要同时更新用户画像、记录到行为日志、异步触发模型增量更新。在单体时代，这三点可以在一个事务里搞定；拆成微服务之后，行为日志服务负责记录，画像服务负责消费行为并更新标签，模型服务负责重新生成推荐候选集。任何一个环节失败，都可能导致数据对不上。

我在实践中采用的方案是“本地消息表+最终一致性”。行为日志服务在本地数据库里写一条消息记录，同时把这条记录标为“待发送”；然后通过消息队列把事件发给下游服务；下游服务消费成功之后，回调确认，行为日志服务再把消息状态改成“已发送”。如果下游消费失败，消息队列会基于重试机制重新投递，直到成功。整个过程没有强一致性的实时保证，但经过几秒钟到几分钟的收敛，最终数据是一致的。

需要注意的是，这种方案只能用在可以容忍延迟的业务场景。如果某个场景必须强一致，比如支付和账务，那就要考虑分布式事务框架或者Saga模式了，但这在AI系统里其实用得很少，因为AI系统里的数据大多数是特征和标签，天然容忍短时间的延迟。

4. 支撑微服务落地的部署基座与配套改造

微服务架构不只是代码层面的拆分，部署基座跟不上，拆出来的服务反而会变成运维噩梦。这一部分讲的是从单机部署切换到容器化、编排化部署时，AI系统独有的坑与配套方案。

4.1 容器化与镜像管理要点

AI系统容器化，第一个特殊点就是模型文件的存放。我见过两种做法：一种是把模型文件直接打进镜像，好处是版本管理简单、启动时不用联网拉模型，坏处是镜像体积动辄十几GB，构建和分发都很慢；另一种是模型文件存放在独立的模型仓库或对象存储里，容器启动时再下载，好处是镜像体积小，坏处是启动依赖外部存储的可用性。

我个人的建议是分情况处理。如果模型文件小于2GB，比如一些中小规模的深度学习模型，直接打进镜像里，减少运维环节的依赖。如果模型超过5GB，一定要走独立的模型仓库，启动时通过initContainer或sidecar机制先下载模型再拉起推理进程。我之前遇到过把8GB模型打进镜像的场景，每次发布光拉镜像就要等十几分钟，而且好几个Pod同时启动时，镜像仓库的带宽直接被打满，其他服务的拉取也变慢了。后来改成模型仓库方案，镜像缩到几百MB，启动时间从十几分钟降到了3分钟以内。

模型版本管理也要纳入镜像标签体系。建议每次模型发布都生成一个独立的版本号，并允许在配置中心指定当前生效的模型版本。这样要做模型灰度时，只需要调整配置，不用重新构建镜像。

4.2 服务编排与弹性伸缩策略

Kubernetes几乎是微服务部署的事实标准，但AI系统需要特别注意两个问题：GPU调度和自动扩缩容策略。

GPU节点的调度，要明确每个推理服务的显存需求和算力需求。一个推理Pod可以声明需要1块GPU还是2块GPU，Kubernetes的Device Plugin会负责把GPU设备绑定到容器里。这里有一个小坑：GPU节点是昂贵资源，调度器默认的“最少请求优先”策略在GPU密集部署时可能导致显存碎片化。建议开启节点亲和性，让同一个推理服务的副本尽量落在同一批GPU节点上，避免碎片化。

自动扩缩容的逻辑，不能只看CPU使用率。推理服务的瓶颈通常在GPU利用率或者请求队列深度。建议基于自定义指标做扩缩容，比如“等待队列中的请求数”超过阈值就扩容，低于阈值就缩容。而且缩容时要设置Cooldown时间，防止在流量抖动期频繁伸缩。

另外一定要为推理服务配置资源上限。GPU显存超限会导致进程直接崩溃，比CPU超限的问题严重得多。要在Pod的资源声明里同时写上requests和limits，limits的值建议等于显存总量，避免Kubernetes把一个Pod调度到显存不足的节点上。

4.3 配置中心与密钥管理

服务多了之后，配置管理不能再靠“改配置文件+重启服务”的原始方式了。配置中心要解决的三个核心问题是：配置实时生效、配置按环境隔离、配置变更可回滚。

AI系统里，配置中心用得最多的场景就是动态调整模型推理参数，比如推理温度、批处理大小、队列深度。这些参数经常需要根据线上表现做微调，如果每次改参数都触发一次发布，效率太低了。有了配置中心，只需要在控制台改一下参数，服务通过监听机制在秒级内感知变化，不用重启。

密钥管理的安全要求比普通配置更高。数据库密码、对象存储AccessKey、外部服务API Token，这些信息不能明文放进配置中心。建议使用专门的密钥管理服务（比如Vault或云厂商的KMS），服务运行时通过SDK从密钥服务拉取需要的密钥，并且配置自动轮转策略。我见过不少团队把AccessKey直接写死在配置文件里，提交到代码仓库之后被扫描工具扫出来，信息泄露风险非常大，这个习惯一定不能有。

4.4 可观测性：日志、指标、链路追踪三件套

微服务架构有一个“分布式难题”：原本一个函数调用栈就能看到全貌的逻辑，现在分散在多个服务进程中。要在这个环境里高效定位问题，必须把可观测性的三件套建好。

日志方面，每个服务必须把日志输出到标准输出，由容器平台统一采集，再写入集中式日志系统（比如Elasticsearch或Loki）。关键是日志格式要结构化，至少包含时间戳、服务名、traceId、日志级别、消息体。没有traceId的日志在微服务环境下几乎等于废纸，因为你根本无法把一次请求的多个片段串起来。

指标方面，要分成两个层次：基础设施层，关注CPU、内存、GPU利用率、网络IO；业务层，关注接口时延、错误率、QPS、推理队列长度、模型推理耗时。这两层指标都要接入统一的监控大盘，并配置告警。告警的阈值不能拍脑袋定，要用一段时间的历史数据做基线测算。我在某个项目里把推理服务的告警阈值设成了“GPU利用率超过80%”，结果由于流量潮汐规律明显，每天傍晚都会误报一次，把值班同事弄得很疲惫。后来改成“GPU利用率超过80%持续10分钟”并区分工作日和周末，误报率才降下来。

链路追踪方面，我自己用下来最顺手的是基于OpenTelemetry的方案，配合Jaeger或Zipkin做可视化。接入之后，可以清晰地看到一次推荐请求在网关、特征服务、推理服务、画像服务之间各花了多少时间。这不仅是定位问题的手段，也是优化系统性能的依据。比如你发现推理服务耗时只有80毫秒，但特征服务花了200毫秒，那性能优化的方向就明确了，不用再去盲目调推理参数。

5. 迁移过程中的典型故障与排查经验

理论说再多，落地时总会遇到各种预料之外的问题。这一节分享几个我在AI系统微服务迁移过程中真实踩过的坑，每个案例都给出完整的问题现象、排查过程和最终解法，希望能帮读者少走一些弯路。

5.1 分布式链路里“偶发超时”的定位过程

现象：迁移后的某个业务接口，监控上看平均时延还不错，但每过一段时间就会出现几个超时告警，重启服务之后又恢复正常，过一两天又出现。

第一次碰到这个问题时，我们的第一反应是“服务负载太高”，于是给Pod扩容了几个副本，但告警并没有消失。后来我们把链路追踪的火焰图拉出来，发现超时请求都卡在了一个服务之间的gRPC调用上，客户端上报的错误是“DeadlineExceeded”。

进一步排查后发现，这个问题出在连接池配置上。gRPC客户端默认使用同一个连接池，当某个请求里有大批量数据的传输，把连接池里的连接全部占满时，新的请求只能排队等待空余连接，队列一长就超时了。而为什么重启服务会“暂时恢复”？因为重启之后连接池被清空，所有连接重新建立，暂时没有积压，可等流量一上来，连接池又被占满。

解决办法有两个：把gRPC客户端连接池的MaxConcurrentStreams调大，同时给流式调用单独建立连接池，避免大流量请求阻塞普通请求。这个问题的本质是微服务化之后，原本在进程内部的函数调用变成了网络调用，连接资源的隔离和超时控制必须跟上。

5.2 模型服务批量推理导致的尾延迟恶化

现象：模型推理服务在压测时P50表现很好，但P99和P999时延特别差，而且流量越高，P99恶化得越明显。

这个问题的根源在于模型推理的批处理机制。为了提高GPU利用率，推理框架通常会把多个请求拼接成一个batch，一起送到GPU计算。batch里的每个样本耗时不同，快慢不一，但整个batch必须等待最慢的那个样本算完才能一起返回。所以一旦出现一个慢样本，整个batch的几十个请求都会被拖累。

解决思路是把大batch拆小，并设置一个“最大batch等待时间”。比如我配置的规则是：每2毫秒收集一批请求，如果batch大小达到64或者等待时间超过2毫秒，立即开始执行推理。这个参数看起来简单，但需要根据实际模型和GPU规模去调。batch设大会提升吞吐但恶化尾延迟，batch设小会降低吞吐但稳定时延。在线的推荐服务对时延敏感，我建议把batch控制在32以下；离线批处理任务则可以开到128以上，反正不追求实时性。

另外一个容易被忽视的点是：模型推理框架在CPU核数不足时，会影响batch的拼接效率。要确认推理服务的CPU limit没有设置得太小，导致进行batch拼接和Java/C++侧调度的时候CPU都不够用。

5.3 配置不一致引发的灰度异常

现象：新服务采用灰度发布，只把10%流量切过去，结果用户报障说功能异常。灰度比例这么低，影响范围按理说不大，但业务方还是收到了不少投诉。

排查时发现，问题不在代码逻辑，而在配置中心。新服务的配置中心里，有些配置项还是“默认值”，没有跟着主配置中心同步过来。比如某个外部接口的签名Key，在单体时是写死在系统配置文件里的；拆出新服务时，运维给新服务在配置中心里建了配置，但签名Key复制过来时出了问题，导致一部分请求在访问外部接口时签名校验失败。

这个问题的教训是：新服务上线前，必须对配置中心里的所有配置项做“差异对比”，而且要跟单体时代的实际生效配置做对比，而不是跟模板对比。最好能在测试环境里做一次完整的接口回归，确保所有外部依赖的配置都正确。同时，配置中心要开启变更审计，任何配置修改都要留痕，方便追溯。

5.4 优雅停机与滚动发布冲突的教训

现象：Kubernetes滚动发布推理服务时，虽然配置了新的Pod就绪后再杀掉旧Pod，但发布过程中还是出现了大量请求失败。

深入了解后发现，这是一个非常经典的问题。推理服务启动时，虽然Kubernetes的readinessProbe认为Pod已经就绪，开始把流量打进来，但推理框架内部还在预热，模型并没有完全加载到显存里。此时接收请求，要么直接报错，要么推理质量异常。等到模型真正预热完成，旧Pod已经被杀掉了一部分，丢掉的流量自然就失败了。

解决办法是在推理服务里实现“优雅就绪”机制：Pod启动后，先完成模型加载和显存预热，此时readinessProbe返回“未就绪”，Kubernetes不会把流量打进来；等到内部确认可以正常推理，再把readinessProbe探针切换为“就绪”状态。这样滚动发布时，新Pod完全Ready之后才会开始接流量，旧Pod在预期时间内把排队的请求处理完，然后优雅退出。

我还遇到过另一个类似问题：旧Pod在收到SIGTERM信号后，立即退出了，但此时还有一批正在执行的推理任务没有完成，导致这些请求直接被中断。修复方法是给推理服务增加优雅退出逻辑：收到SIGTERM后，先停止接收新请求，等待当前正在执行的推理任务完成（或者等待一个最大时间阈值），然后才真正退出进程。这个阈值也要调好，设太短了没有效果，设太长了又会拖慢发布速度，建议根据模型推理的最大耗时来定，一般设成最大推理耗时的2倍左右。

写在最后的实战体会

从单体到微服务，对于AI系统来说，不只是一个技术问题，更是一个组织问题和架构治理问题。我在这个演进过程中最深的体会是：不要追求一步到位，也不要迷信“微服务就是万能解药”。

微服务带来了独立部署、按需扩容、故障隔离这些好处，但同时也引入了分布式系统固有的复杂度：网络延迟、数据一致性、链路排查、运维成本。如果你的AI系统还处于早期验证阶段，流量一天也就几万请求，模型就一两个，强行拆微服务只会增加负担。我见过一些团队，明明单体完全能扛住当前流量，偏要为了“技术先进性”拆成二十个服务，结果研发效率直线下降，一个需求要跨四五个服务联调，上线窗口从按天变成了按周。

我的建议是：架构演进一定跟着业务规模和团队规模走。当你想清楚这几个问题的时候，才值得动手：

• 模型发布和业务发布的频率差异是否已经严重影响上线效率？
• 扩容时是否存在明显的资源浪费，GPU和CPU的需求已经彻底错配？
• 单个服务故障是否经常导致整个系统不可用？
• 团队规模是否已经大到让多团队协作单仓库发布变得难以忍受？

如果这些问题的答案都是“是”，那微服务拆分就是值得投入的方向。如果只有一两个答案是“是”，那先做模块化重构和资源隔离，往往性价比更高。

最后分享一个小的操作技巧：无论迁移到哪一步，都要保留“快速回滚”的能力。微服务架构里，每一次发布都应该有对应的回滚预案，配置回滚、镜像回滚、数据回滚三条链路都要提前演练过。毕竟架构演进是一场马拉松，不在某一晚跑完全程，而在每一步都稳稳落地。