微服务治理
微服务架构将单体应用拆分为多个小型服务，每个服务独立开发、部署、扩展。微服务治理是确保微服务架构可运行、可维护、可扩展的一套技术和实践。
微服务架构引入的核心理由是单数据库的 IO 瓶颈和压力，此外，引入微服务还有其他理由，单体应用的问题：代码库庞大、部署困难、技术栈固定、扩展受限、单点故障。
微服务的代价：分布式复杂性（服务间通信、数据一致性）、运维复杂度（大量服务需要管理）、调试困难（调用链路长）。
微服务治理的目标：管理服务数量庞大的系统，保证服务的可用性、性能、一致性。
微服务治理的核心组件
服务注册与发现：服务如何注册自己的地址，客户端如何发现服务地址。
配置中心：如何动态管理配置，所有实例能够及时获取最新配置。
API 网关：统一入口，处理认证、限流、路由、聚合。
负载均衡：如何将请求分发到多个服务实例。
缓存架构：提升系统性能、降低数据库负载。
微服务的健壮性
微服务架构下，服务间的依赖关系复杂，单个服务的故障可能级联扩散，导致整个系统雪崩。健壮性是服务在异常情况下维持核心功能的能力。
熔断降级：服务故障时快速失败，返回默认值，避免雪崩。
限流保护：保护服务不被过载请求打垮，确保服务在容量范围内稳定运行。
舱壁隔离：将资源隔离，避免单个服务的问题影响整个系统。
微服务的可观测性
微服务架构下，服务数量众多、调用链路复杂，问题定位和性能分析变得困难。可观测性是通过系统的外部输出（日志、指标、链路）来理解系统内部状态的能力。
监控告警：收集和展示系统的运行指标，及时发现和处理异常。
链路追踪：记录一个请求经过的所有服务，快速定位故障和性能瓶颈。
微服务拆分原则
按业务能力拆分：订单服务、库存服务、用户服务。每个服务负责一个完整的业务能力。
按数据子域拆分：参考领域驱动设计（DDD），每个服务对应一个限界上下文。
单一职责：每个服务只做一件事，做好一件事。
独立数据存储：每个服务有自己的数据库，避免共享数据库。
无状态服务：服务不保存状态，状态存储在外部（Redis、数据库），便于扩展。
微服务的数据一致性
分布式事务：跨服务的数据一致性难以保证，强一致性方案性能差。
最终一致性：接受短暂不一致，通过补偿机制保证最终一致。
幂等性：同一操作执行多次，结果与执行一次相同。
事件驱动：通过事件总线异步通信，降低服务耦合。
Saga 模式：长事务拆分为多个本地事务，每个事务有补偿。
TCC 模式：Try-Confirm-Cancel 三阶段提交。
微服务的测试与部署
单元测试：测试单个服务的逻辑。
集成测试：测试服务间的交互。
契约测试：测试服务接口的兼容性。
金丝雀发布：先发布到少量实例，验证后全量发布。
蓝绿部署：维护两套环境，切换流量实现零停机部署。
滚动发布：逐个替换实例，保证持续可用。
微服务治理是微服务架构的基石，理解服务治理的组件和模式，有助于设计可维护的微服务系统。
三高指标
在分布式架构（如你正在搭建的 K8s + AI 推理集群）中，“三高”是评价一个系统是否达到“工业级”水准的核心指标。
简单来说，三高指的是：高可用 (High Availability)、高性能 (High Performance)、高并发 (High Concurrency)。
1. 高可用 (High Availability, HA)
探讨核心：系统能不能“不宕机”？
高可用衡量的是系统面对故障时的生存能力。通常用“几个 9”来表示（如 99.99% 意味着一年停机时间不超过 52 分钟）。
- 底层手段：
- 冗余 (Redundancy)：不要单点。MySQL 必须有主从，Operator 必须能自动拉起挂掉的 Pod。
- 故障转移 (Failover)：主节点挂了，从节点秒级接管。
- 数据备份：利用 OSS/S3 定期存快照。
- 你的 AI 场景：如果一个 vLLM 节点显卡掉线了，流量能不能自动切到另一个备用显卡节点？
2. 高性能 (High Performance)
探讨核心：系统跑得能不能“足够快”？
高性能关注的是响应时间 (Latency) 和 吞吐量 (Throughput)。
- 底层手段：
- 缓存：用 Redis 减少数据库 IO。
- 异步：用 RocketMQ 把耗时任务从主流程剥离。
- 硬件加速：对于 C 开发者，你会关注利用 GPUDirect Storage 或 RDMA 网络减少数据拷贝。
- 索引优化：在 ElasticSearch 或 Milvus 中通过精密的索引算法加速搜索。
- 你的 AI 场景：生成一个 Token 需要多少毫秒（TPOT）？首字返回需要多久（TTFT）？
3. 高并发 (High Concurrency)
探讨核心：系统能不能“扛得住多人同时用”？
高并发衡量的是系统在单位时间内处理请求的能力（QPS/TPS）。
- 底层手段：
- 水平扩展 (Scaling)：一台服务器扛不住 1000 人，那就通过 K8s HPA 自动扩容到 10 台。
- 池化技术：连接池（MySQL）、线程池、甚至 GPU 算力池。
- 分库分表：当 MySQL 单表数据过亿影响并发时，进行拆分。
- 你的 AI 场景：当 1000 个用户同时在网页上找你的 Agent 聊天时，系统是依然顺滑，还是直接 OOM 崩溃？
三者的关系：互相牵制，动态平衡
作为架构师，你需要理解这三者往往是冲突的：
- 为了高可用，你需要多副本数据同步，这会增加延迟，降低高性能。
- 为了高并发，你可能需要引入复杂的缓存逻辑，这增加了系统的复杂性，反而可能降低高可用。
| 指标 | 解决的问题 | 核心工具 |
|---|---|---|
| 高可用 | 别挂了。 | Operator, Keepalived, K8s |
| 高性能 | 别慢了。 | Redis, C/C++ 优化, SSD |
| 高并发 | 别挤爆了。 | Nginx, RocketMQ, K8s HPA |
总结建议（结合你的背景）
在你的 Agent 项目 中，目前最难调优的其实是 “高性能”。
- C/Python 混合优化：利用 Python 处理业务逻辑，底层推理交给 C++ 优化的 vLLM。
- 流量调度：使用我们刚才聊过的限流降级，当并发超过“高并发”阈值时，牺牲一部分用户的体验来换取整体的“高可用”。
既然了解了三高的定义，你想看看在 K8s 环境下，如何利用 Prometheus 监控指标来实时定义你系统的“三高”基准线吗？