- [1. 阶段目标回顾与成果总览](#1-阶段目标回顾与成果总览)
- [1.1 拆分前的系统现状](#11-拆分前的系统现状)
- [1.2 阶段达成的核心目标](#12-阶段达成的核心目标)
- [1.3 最终架构全景图](#13-最终架构全景图)
- [2. 各服务拆分实施总结](#2-各服务拆分实施总结)
- [2.1 用户认证服务](#21-用户认证服务)
- [2.2 模型管理服务](#22-模型管理服务)
- [2.3 推理调度服务](#23-推理调度服务)
- [2.4 模型推理服务](#24-模型推理服务)
- [2.5 知识库服务](#25-知识库服务)
- [2.6 计费与限额服务](#26-计费与限额服务)
- [3. 基础设施与运维总结](#3-基础设施与运维总结)
- [3.1 服务网格流量治理](#31-服务网格流量治理)
- [3.2 可观测性体系](#32-可观测性体系)
- [3.3 数据库拆分策略](#33-数据库拆分策略)
- [3.4 容器化与弹性伸缩](#34-容器化与弹性伸缩)
- [4. 技术决策与经验沉淀](#4-技术决策与经验沉淀)
- [4.1 关键技术选型回顾](#41-关键技术选型回顾)
- [4.2 踩过的坑与解决方案](#42-踩过的坑与解决方案)
- [4.3 性能对比数据](#43-性能对比数据)
- [5. 项目持续演进方向](#5-项目持续演进方向)
- [5.1 多模态推理服务接入](#51-多模态推理服务接入)
- [5.2 模型热更新与A/B测试](#52-模型热更新与ab测试)
- [5.3 多云部署策略](#53-多云部署策略)
- [6. 本章小结](#6-本章小结)
1.1 拆分前的系统现状
在第44阶段开始之前，大模型推理平台采用的是单体微服务架构——一个大型的Spring Boot应用承载了用户认证、模型管理、推理调度、计费统计、知识库管理等功能。尽管在Kubernetes上部署了多个副本，但由于所有功能耦合在同一个代码库和数据模型中，系统面临着一系列问题。
首先是服务耦合的痛点。用户认证功能出现一个小bug需要修改代码，却不得不对整个服务进行重新构建和部署，导致推理功能也受到影响。一次JVM参数调优需要重启整个服务，所有在线推理请求同时中断。团队中不同的子团队开发不同的功能模块，但使用了同一个Git仓库和CI/CD流水线，频繁出现代码合并冲突。
其次是扩容粒度不匹配的问题。推理服务的负载特征是GPU密集型的，需要根据推理请求队列深度进行扩容。而认证服务的负载特征是完全不同的——它在用户登录高峰期CPU利用率升高，但内存占用稳定。在单体架构下，HPA只能基于统一的CPU指标进行扩容，无法针对不同模块的负载特征进行精细化控制。
第三是数据模型的深层耦合。所有功能模块共享同一个MySQL数据库，随着推理记录数据量的暴涨，即使是查询用户列表这样简单的操作也变得越来越慢。数据库表的变更会影响所有模块的查询逻辑，团队对Schema修改变得小心翼翼。
这些问题促使团队下定决心，启动第44阶段的微服务拆分工作。
1.2阶段达成的核心目标
经过本阶段五篇文章的系列实践，团队成功将大模型推理平台从单体架构拆分为六个独立的微服务：
**用户认证服务**：提供用户注册、登录、JWT令牌管理、API Key认证和RBAC权限控制。使用MySQL作为主存储，Redis管理令牌白名单和会话。独立的认证服务可以在不影响推理功能的情况下进行安全策略的调整和升级。
**模型管理服务**：管理模型元信息、版本发布和配置分发。使用MySQL+双层缓存（Caffeine+Redis）。模型配置的平均读取延迟从200ms（数据库查询）降低到5ms（本地缓存命中）。版本发布后通过Kafka通知下游服务刷新缓存。
**推理调度服务**：负责推理请求的路由和负载均衡。根据模型版本、用户等级、GPU负载等多种条件智能选择推理实例。实现了LEAST_REQUEST负载均衡算法和基于优先级的请求队列，P99排队等待时间控制在3秒以内。
**模型推理服务**：核心的GPU推理工作负载。支持多模型版本同时在线服务，使用NVIDIA GPU和vLLM推理引擎。实现了基于请求队列深度的KEDA自动伸缩，模型启动时的预热机制将冷启动时间从5分钟缩短到90秒。
**知识库服务**：提供文档管理和向量检索能力。使用MongoDB存储文档元信息和分块内容，Milvus向量数据库存储文本嵌入。知识库检索延迟控制在50ms以内。
**计费与限额服务**：管理用户账户余额、Token消费计费和API配额。使用MySQL乐观锁保证余额扣减的强一致性，通过定时对账任务保证最终一致性。每日自动出账，支持按用户和模型维度的消费明细查询。
除了服务拆分本身，还完成了配套的基础设施建设：
- 服务网格（Istio）：实现流量治理、mTLS安全通信和灰度发布
- 可观测性体系：Prometheus+Grafana+Jaeger+ELK完整覆盖指标、追踪和日志
- 数据库独立Schema：各服务独立数据库，MySQL+Redis+MongoDB+ES+Milvus多模型存储
- Kubernetes弹性伸缩：HPA+KEDA+Cluster Autoscaler的自动伸缩体系
- CI/CD流水线：ArgoCD实现GitOps，支持滚动更新、蓝绿部署和金丝雀发布
1.3最终架构全景图
第44阶段交付的大模型微服务平台最终架构包含以下层次：
**接入层**：用户通过API Gateway访问平台。Gateway基于Spring Cloud Gateway构建，前端使用HTTPS（经Istio Ingress Gateway终止TLS），后端使用gRPC与服务间通信。
**业务服务层**：由六个微服务组成。服务间通信通过Istio管理的Envoy Sidecar代理，启用了STRICT模式的mTLS。所有HTTP/gRPC请求自动注入OpenTelemetry追踪上下文。服务通过Prometheus暴露指标端点。
**基础设施层**：
- 数据库：MySQL集群（认证、计费、模型管理）、MongoDB（推理记录、知识库元数据）、Redis集群（缓存、会话）、Elasticsearch（搜索）、Milvus（向量检索）
- 消息队列：Kafka（事件驱动、CDC数据变更捕获）
- 对象存储：MinIO/S3（模型文件、文本文档）
**运维层**：
- 可观测性：Prometheus + Grafana + Jaeger + ELK + Kiali
- 服务网格：Istio（Pilot、Citadel、Envoy Sidecar）
- 部署：ArgoCD（GitOps）、KEDA（事件驱动伸缩）、Karpenter（节点自动伸缩）
- 容器运行时：Docker + Kubernetes
2.1 用户认证服务
用户认证服务从单体中拆分的核心挑战在于Session和JWT令牌的管理。原单体架构使用Spring Session将用户登录状态存储在本地内存中，拆分后需要在多个认证服务实例间共享会话状态。
技术方案上，团队采用了JWT无状态认证为主、Redis为辅的混合方案。对于常规的API调用，客户端携带JWT令牌，服务通过公钥验证签名而不需要查询数据库。对于需要主动作废令牌的场景（如修改密码、管理员封禁账号），维护一个Redis中的Token黑名单（Bloom Filter实现，内存占用极小）。
API Key认证是另一个关键设计。对于程序化调用推理API的场景，用户生成API Key替代JWT。API Key的验证通过SHA256哈希比对快速判断，避免频繁的RSA签名验证开销。
权限模型采用RBAC（基于角色的访问控制），定义了USER（普通用户）、PREMIUM（付费用户）、ADMIN（管理员）、SYSTEM（系统服务）四种角色。每个角色关联不同的API访问权限，权限检查通过Spring Security的@PreAuthorize注解实现。
@PreAuthorize("hasRole('PREMIUM') or hasRole('ADMIN')")
@PostMapping("/v1/chat/completions/model/gpt-4o")
public InferenceResponse chatCompletions(@RequestBody ChatRequest request) {
// 仅付费用户和管理员可以使用GPT-4o模型
return inferenceOrchestrator.process(request);
}
认证服务拆分后，安全审计和合规需求也得到了更好的满足。所有认证事件（登录、登出、密码修改、权限变更）写入审计日志，存储到MongoDB的独立集合中，设置了30天的数据保留策略。
2.2模型管理服务
模型管理服务的拆分重点在于模型配置的分发机制。在单体架构中，推理服务直接读取模型管理模块的数据库表来获取模型配置。拆分后推理服务不能直接访问模型管理服务的数据库，需要新的配置分发机制。
团队设计了"变更通知+主动拉取"的双向机制。当模型配置发生变化时，模型管理服务发布Kafka事件。推理服务订阅该事件后，通过模型管理服务的REST API拉取最新的配置并更新本地缓存。
// 模型管理服务：发布配置变更事件
@Service
public class ModelConfigNotifier {
@Autowired
private KafkaTemplate<String, ModelConfigChangedEvent> kafkaTemplate;
@Transactional
public void updateModelConfig(Long modelId, ModelConfig config) {
modelRepository.save(new ModelVersion(modelId, config));
// 发布变更事件
ModelConfigChangedEvent event = ModelConfigChangedEvent.builder()
.modelId(modelId)
.modelCode(config.getModelCode())
.timestamp(Instant.now())
.build();
kafkaTemplate.send("model-config-changed", event);
}
}
// 推理服务：订阅配置变更事件
@Component
public class ModelConfigSubscriber {
@KafkaListener(topics = "model-config-changed")
public void onConfigChanged(ModelConfigChangedEvent event) {
log.info("Model config changed: {}, triggering refresh", event.getModelCode());
modelConfigCache.invalidate(event.getModelCode());
// 通过API拉取最新配置
ModelConfig latest = modelConfigClient.getConfig(event.getModelId());
modelConfigCache.put(event.getModelCode(), latest);
}
}
这种设计的优势在于：模型管理服务保持了对配置的唯一写入权，推理服务通过事件驱动获得近实时的配置更新，且本地缓存保证了推理请求的低延迟访问。
2.3推理调度服务
推理调度服务是新拆分出来的服务，在单体架构中没有独立的对应模块。它的核心职责是接收来自API Gateway的推理请求，根据请求特征选择最合适的推理实例，并将结果返回给Gateway。
调度策略的设计经历了多次迭代。最初的版本使用简单的Round Robin轮询。后来发现不同请求的处理时间差异极大，Round Robin常常将复杂的请求堆积在同一个实例上。团队改为LEAST_REQUEST（最少活跃请求数）算法，新请求总是分配给当前负载最轻的实例。
进一步的优化引入了基于模型版本的调度和优先级队列。用户可以在请求中通过HTTP头部指定模型版本，调度服务根据版本标签将请求路由到对应的实例。VIP用户和高优先级请求进入优先级队列，获得更短的平均等待时间。
@Service
public class InferenceScheduler {
private final Map<String, PriorityBlockingQueue<InferenceTask>> queues =
new ConcurrentHashMap<>();
private final Map<String, List<InferenceInstance>> instancePools =
new ConcurrentHashMap<>();
public InferenceInstance selectInstance(InferenceRequest request) {
String modelVersion = request.getModelVersion();
List<InferenceInstance> candidates = instancePools.get(modelVersion);
if (candidates == null || candidates.isEmpty()) {
throw new NoAvailableInstanceException(modelVersion);
}
// LEAST_REQUEST: 选择活跃请求数最少的实例
return candidates.stream()
.filter(InferenceInstance::isHealthy)
.min(Comparator.comparingInt(InferenceInstance::getActiveRequestCount))
.orElseThrow(() -> new NoAvailableInstanceException(modelVersion));
}
}
调度服务还兼具熔断器的作用。当某个推理实例连续返回错误时，调度服务将其标记为不可用并从实例池中移除，避免将更多请求发送到故障实例。如果某类型的所有实例都不可用，返回503 Service Unavailable。
2.4模型推理服务
模型推理服务是系统中最特殊的服务——它是唯一需要GPU资源的服务，也是延迟最高、资源消耗最大的服务。拆分这个服务的核心目标是实现独立扩容和模型版本隔离。
推理服务基于vLLM（一个高性能的LLM推理引擎）构建。vLLM的PagedAttention机制能够高效管理KV缓存，在高并发场景下吞吐量比标准实现提升2-4倍。服务对外暴露了兼容OpenAI API的接口，使得上层服务可以无缝切换。
模型的加载和预热是推理服务面临的最大挑战。一个GPT-4o级别的模型在A100-80GB GPU上加载到显存需要2-5分钟。为了解决冷启动问题，团队设计了预热机制：在模型服务的启动脚本中，通过发送预热请求来触发模型加载和CUDA kernel编译：
模型服务启动脚本中的预热逻辑
async def warmup():
warmup_prompt = "Hello"
# 发送预热请求，触发模型加载
async with httpx.AsyncClient() as client:
for _ in range(3): # 多次预热确保CUDA kernel完全编译
await client.post(
"http://localhost:8080/v1/chat/completions",
json={
"messages": [{"role": "user", "content": warmup_prompt}],
"max_tokens": 10
},
timeout=120.0
)
logger.info("Model warmup completed")
在Starlette启动事件中执行预热
app.add_event_handler("startup", warmup)
推理服务的健康检查也经过了精心设计。Liveness探针仅检查进程是否存活，避免在模型仍在加载时被误杀。Readiness探针检查模型是否加载完成、GPU是否健康、显存是否充足，只有在所有检查通过后才接收流量。Startup探针给模型足够长的加载时间（最长300秒）。
2.5知识库服务
知识库服务管理文档的上传、解析、嵌入和检索。拆分这个服务的关键在于选择合适的存储引擎。
文档的分块（Chunking）策略采用了递归字符分割算法。对于Markdown文档，分割器会先尝试按标题分割，再按段落分割，最后按句子分割。分块大小设为512个token，重叠100个token，保证相邻分块之间的上下文连续性。
向量嵌入使用text-embedding-3-large模型生成1536维的向量。嵌入生成是批量操作——当文档上传后，将所有分块一起发送给嵌入服务，避免逐个请求的网络开销。
向量检索使用Milvus的IVF_FLAT索引（nlist=1024），在百万级别的向量库中，检索延迟稳定在50ms以内。检索策略是混合搜索：先通过向量相似度检索top-100个候选分块，再通过BM25关键词匹配重新排序，最终返回top-5的相关分块。这种混合策略兼顾了语义相关性和关键词精确匹配。
2.6计费与限额服务
计费服务是金融敏感型服务，对数据一致性要求最高。拆分这个服务的核心挑战是如何在分布式环境中保证余额扣减的强一致性。
扣费流程的设计是：每次推理请求完成后，推理调度服务向计费服务发送扣费请求。计费服务使用MySQL的乐观锁机制保证同一用户余额的并发扣减不会出现超扣：
@Transactional
public DeductionResult deductTokenFee(Long userId,
String traceId,
String modelCode,
int inputTokens,
int outputTokens) {
// 计算费用
BigDecimal cost = pricingService.calculate(modelCode, inputTokens, outputTokens);
// 乐观锁扣费
int updated = userAccountMapper.deductWithLock(userId, cost, currentVersion);
if (updated == 0) {
// 版本冲突，重试（最多3次）
if (retryCount < MAX_RETRY) {
return deductTokenFee(userId, traceId, modelCode,
inputTokens, outputTokens, retryCount + 1);
}
throw new ConcurrentModificationException("余额扣费失败");
}
// 记录消费流水
consumptionRecordMapper.insert(
new ConsumptionRecord(userId, traceId, modelCode,
inputTokens, outputTokens, cost)
);
return new DeductionResult(true, cost, newBalance);
}
除了实时扣费，计费服务还有定时对账机制。每天凌晨2点，定时任务扫描前一天的所有推理记录，与计费流水进行交叉比对。对账发现的差异会自动生成补偿记录，由人工审核后处理。
API配额管理是计费服务的另一个子功能。每个用户按日、按月有API调用次数和Token消耗上限。配额数据存储在Redis中，通过Lua脚本保证原子性操作：
-- Redis Lua脚本：原子性检查并扣减配额
local key = KEYS[1] -- 配额Key
local limit = tonumber(ARGV[1]) -- 配额上限
local amount = tonumber(ARGV[2]) -- 当前消耗
local current = tonumber(redis.call('GET', key) or '0')
if current + amount > limit then
return 0 -- 配额不足
end
redis.call('INCRBY', key, amount)
return 1 -- 扣减成功
3.1服务网格流量治理
通过Istio服务网格，团队实现了透明化的流量治理。所有六个微服务和它们的副本都注入了Envoy Sidecar代理，东西向流量全部通过Sidecar代理处理。
在灰度发布方面，团队建立了标准的流程：新版本服务首先部署1个Pod（占10%流量），观察2小时的错误率和延迟指标。如果指标正常，逐步提升到50%流量，再观察4小时。确认无误后，将灰度权重提升到100%，下线旧版本Pod。
mTLS的启用经历了一个渐进过程：首先在整个命名空间启用PERMISSIVE模式（允许明文和加密混合），运行一周确认没有通信问题后，切换到STRICT模式。所有服务间通信现在都是端到端加密的，结合RBAC的授权策略，实现了零信任安全架构。
Kiali仪表盘成为日常运维的重要工具。通过Kiali的Graph视图，团队可以直观地看到服务间的调用拓扑和流量热图。当某个服务的错误率上升时，红色边会立即暴露问题所在。
3.2可观测性体系
可观测性体系取得了以下实际效果：
Prometheus+Grafana的指标监控覆盖了三种类型的指标：基础设施指标（CPU、内存、网络、磁盘）、应用指标（QPS、错误率、延迟分布、JVM GC）、业务指标（Token消耗、模型热度、用户活跃度）。共定义了15条告警规则，涵盖服务不可用、高错误率、高延迟、GPU异常等场景。
Jaeger的分布式追踪让团队第一次看到了一次推理请求的完整调用链路。在性能优化中，团队通过分析Trace数据发现T0时刻至首Token的时间有35%消耗在认证服务上，于是优化了JWT验证缓存，将认证延迟从45ms降低到15ms。
ELK日志平台日均接收约500万条日志。结构化JSON日志使得在Kibana中按traceId、userId、modelCode等字段进行多维度搜索成为可能。通过日志驱动的告警，团队能够在用户报告问题之前主动发现和修复故障。
3.3数据库拆分策略
数据库拆分采用了"逻辑分离→物理分离→多模型混合"的三步走策略。
第一阶段，所有服务仍然使用同一个MySQL实例，但每个服务使用独立的Database（Schema）。通过数据库用户权限控制，禁止跨Database的直接访问。这个阶段验证了Schema设计的合理性，为后续物理分离打下基础。
第二阶段，推理记录服务率先迁移到MongoDB，解决了日益增长的写入压力。随后知识库服务的向量数据迁移到Milvus，搜索数据迁移到Elasticsearch。最后，用户认证、模型管理和计费服务各自迁移到独立的MySQL实例。
第三阶段，完善了多模型混合架构。各服务根据自己的数据特征选择了最适合的数据库。
在数据迁移过程中，团队严格执行了"双写→批量迁移→切读→停双写→清理"的零停机迁移流程。整个过程对在线用户完全透明，没有出现数据丢失或不一致的情况。
3.4容器化与弹性伸缩
容器化和弹性伸缩方面取得了显著成效。各服务的容器镜像体积通过多阶段构建控制在200MB以内，启动时间在30秒以内（GPU推理服务因模型加载需要除外）。
HPA的基础配置覆盖了所有微服务。API Gateway的HPA基于CPU和请求速率双重指标，在日间高峰时段自动扩容到12个Pod，夜间低谷时缩容到3个Pod。推理调度服务的HPA基于CPU和活跃请求数，自动维持在2-6个Pod之间。
GPU推理服务的伸缩使用KEDA，基于Prometheus采集的推理请求队列深度和GPU利用率两个自定义指标。Karpenter负责GPU节点的自动伸缩，支持Spot实例和On-Demand实例的混合调度，GPU资源成本相比全部使用On-Demand降低了约40%。
ArgoCD的GitOps模式使得部署变更完全可审计、可追溯、可回滚。任何对集群的变更都必须通过Git仓库的Pull Request，经Code Review后才能应用。
4.1关键技术选型回顾
回顾整个阶段的关键技术选型，以下决策对项目的成功最为关键：
**选择Istio而非仅依赖Spring Cloud Gateway**。最初团队考虑过全栈使用Spring Cloud生态，但最终选择了Istio。这个决策的正确性在后续得到验证：Istio的Sidecar模式完美支持了推理服务这样使用Python的多语言异构环境，mTLS的透明启用大幅简化了安全配置，流量治理规则通过CRD声明式管理比代码更加灵活。
**选择MongoDB存储推理记录而非MySQL**。MySQL的分区表可以管理大量数据，但推理请求的JSON结构灵活多变，关系模型处理起来非常繁琐。MongoDB的文档模型天然契合推理记录的数据结构，自动分片能力解决了数据量增长的问题。
**选择KEDA而非仅依赖HPA**。标准HPA的CPU/内存指标无法准确反映GPU推理服务的负载。KEDA的事件驱动伸缩能力，结合Prometheus自定义指标，让推理服务的伸缩更加精准。
**选择ArgoCD实现GitOps而非Jenkins Pipeline部署**。ArgoCD的声明式配置管理和自动同步机制，消除了传统Jenkins Pipeline中复杂的kubectl命令和Shell脚本。git diff就能看到集群配置的完整变更历史。
4.2踩过的坑与解决方案
在项目实践中，团队遇到了不少工程挑战，以下是最有价值的几个问题及其解决方案。
**问题一：HPA频繁扩缩容导致服务不稳定**。最初HPA的缩容稳定窗口设置过短（60秒），导致流量短暂下降后立即缩容，流量回升又立即扩容，形成"抖动"。解决方案是将缩容稳定窗口增加到300秒（5分钟），确保缩容只在持续低负载时才会触发。
**问题二：GPU推理服务的冷启动延迟**。新Pod启动后加载模型到显存需要2-5分钟，在此期间Readiness探针会失败，但Liveness探针可能在模型加载完成前触发杀死Pod。解决方案是引入Startup探针，设置30次检查容错（300秒），在启动阶段覆盖Liveness和Readiness的检测。
**问题三：数据库迁移中的数据类型不匹配**。将MySQL的数据迁移到MongoDB时，发现datetime字段在MongoDB中存储为字符串而非ISODate类型，导致按时间范围的查询无法使用索引。解决方案是在迁移脚本中显式处理日期类型转换。
**问题四：Kafka消费者反序列化失败导致消费阻塞**。当消息体的格式与消费者期望的类不匹配时，默认的错误处理会阻塞整个分区的消费。解决方案是实现Dead Letter Queue机制，将反序列化失败的消息发送到DLQ主题，不影响正常消息的消费。
@Component
public class KafkaConsumerConfig {
@Bean
public DefaultErrorHandler errorHandler() {
//反序列化失败的消息路由到DLQ
DeadLetterPublishingRecoverer recoverer =
new DeadLetterPublishingRecoverer(kafkaTemplate,
(record, exception) -> new TopicPartition(
record.topic() + ".dlq", record.partition()));
DefaultErrorHandler handler = new DefaultErrorHandler(recoverer,
new FixedBackOff(1000L, 3)); // 重试3次，间隔1秒
handler.addNotRetryableExceptions(
DeserializationException.class);
return handler;
}
}
4.3性能对比数据
以下是微服务拆分前后的关键性能指标对比：
指标 | 拆分前（单体） | 拆分后（微服务） | 改善 |
----- | ------------- | --------------- | ------ |
平均推理请求端到端延迟 | 18.5s | 12.3s | -33% |
P99推理延迟 | 45.2s | 22.8s | -50% |
API Gateway QPS上限 | 450 | 1200 | +167% |
推理服务GPU利用率 | 62% | 85% | +37% |
服务启动时间 | 120s | 25s（非GPU）/ 90s（GPU） | -79% |
单次部署影响范围 | 全站中断 | 仅影响单服务 | 零停机 |
生产事故平均修复时间 | 45min | 12min | -73% |
月度GPU成本 | ¥85,000 | ¥52,000 | -39% |
最显著的变化是P99延迟从45.2秒降低到22.8秒。这主要归功于推理调度服务的LEAST_REQUEST负载均衡算法和独立的推理服务实例池。在单体架构下，复杂的推理请求会阻塞简单请求的处理，拆分后每个推理实例都能独立处理请求，互不干扰。
GPU成本降低了39%，主要得益于Spot实例的使用和KEDA的精细化伸缩。在单体架构下，推理服务需要保持足够的副本数应对峰值流量，大部分时间这些副本处于低负载状态。拆分后可以按需启动GPU实例，低谷时缩容到最小副本数。
5.1多模态推理服务接入
当前平台主要服务于文本生成模型。下一步计划接入多模态推理服务，包括图像理解（如GPT-4o的视觉能力）、文生图（DALL-E/Stable Diffusion）、语音识别（Whisper）和语音合成（TTS）。多模态服务的请求特征与纯文本推理有很大不同——图像生成的延迟可能长达数十秒，语音识别需要流式处理。这些差异对调度策略和弹性伸缩提出新的要求。
5.2模型热更新与A/B测试
当前模型版本切换需要部署新的推理服务实例，涉及完整的环境准备和模型加载。未来的目标是实现模型热更新——推理服务在运行中切换模型权重，无需重启Pod。这需要推理引擎层面（vLLM或TGI）的支持，配合Istio的流量切换实现无缝的版本更替。
A/B测试框架也是计划中的功能。模型团队可以在平台上同时部署两个模型变体，随机分配用户流量，通过可观测性体系收集两个版本的推理质量指标（如输出格式合规率、用户满意度评分），用数据驱动模型迭代决策。
5.3多云部署策略
当前所有服务部署在同一个Kubernetes集群中（假设部署在腾讯云TKE）。未来计划扩展到多云部署——核心推理服务部署在多个云提供商的GPU集群上，通过Istio的多集群网格进行统一管理。多云的动机包括GPU资源的可用性保障（避免单一云提供商的GPU短缺影响服务）、成本优化（利用不同云的GPU定价差异）和容灾备份（避免单云单区域故障导致服务中断）。
第44阶段"大模型微服务拆分"是Java程序员进阶到分布式架构领域的关键里程碑。通过五篇文章的系统实践，团队将一个大模型推理平台从单体架构成功拆分为六个独立微服务，并建设了服务网格、可观测性、数据库独立Schema和Kubernetes弹性伸缩四大基础设施。
回顾这一阶段的收获，可以从三个维度总结价值：
**技术维度**：深入掌握了Istio服务网格的流量治理、Prometheus/Grafana/Jaeger/ELK的可观测性体系、独立Schema的数据库拆分策略、HPA+KEDA的弹性伸缩配置。这些技术栈构成了云原生微服务架构的核心能力版图。
**架构维度**：通过实际拆分过程，深刻理解了微服务架构的核心原则——服务自治、独立部署、弹性伸缩、故障隔离。每个服务独立演进的能力使得团队可以采用不同的技术栈和更新节奏，系统的整体演进速度大幅提升。
**工程维度**：积累了零停机迁移、分布式事务补偿、事件驱动数据同步等工程实践经验。这些经验不局限于大模型场景，在更广泛的微服务架构中都适用。
大模型微服务的架构演进是一个持续迭代的过程。第44阶段奠定了坚实的技术基础，为后续的多模态推理、模型热更新、多云部署等方向铺平了道路。最重要的是，团队建立了一套可复用的微服务架构方法论——从服务边界的识别、数据模型的拆分、通信机制的设计到运维体系的建设。这套方法论将成为团队应对未来更大挑战的核心能力。
**第44阶段完结。**
