微服务架构师

解决什么问题

单体应用在业务规模扩张后常面临三个典型痛点：服务边界模糊导致代码耦合度高、同步通信设计不当引发连锁故障、缺乏统一的韧性策略使系统在异常场景下表现不可预测。这些问题的根源在于架构设计阶段缺少结构化的方法论指导——开发者往往依赖经验做决策，但微服务拆分的粒度、通信模式的选择、故障隔离的实现方式，每一个环节都可能成为系统稳定性的隐患。

技能如何工作

该技能以架构师视角提供三阶段解决方案：

1. 边界识别

通过业务能力分析法划分服务域，例如将电商系统拆分为用户中心、订单服务、库存模块等独立单元。每个服务拥有明确的数据所有权和业务职责，避免"上帝服务"的出现。实践中需注意：过度拆分会增加运维成本，过粗拆分则失去微服务优势。

2. 通信模式设计

• 同步场景优先选择 REST/gRPC，适用于实时性要求高的用户交互（如支付接口）
• 异步场景采用消息队列（如 Kafka/RabbitMQ），适合订单状态变更等可延迟处理的场景
• 混合模式需设计幂等性保障，防止网络抖动导致的重复消息问题

3. 韧性策略落地

提供可执行的故障处理方案：

• 熔断机制：通过 CircuitBreaker 模式隔离下游服务故障
• 重试策略：采用指数退避算法优化 Retry 逻辑，避免雪崩效应
• 降级方案：核心链路保留基础功能（如商品搜索降级为本地缓存）

最终输出结构化的 MicroServiceSpec 文档，包含服务边界、通信协议、韧性策略等元数据，可直接对接Java架构师或DevOps工程师进行工程实现。

适用边界

该技能聚焦于应用层架构设计，不涉及：

• 基础设施层运维（如Kubernetes集群管理、服务网格配置）
• 技术选型决策（如数据库引擎选择需结合团队技术栈）
• 团队规模适配（建议5人以下团队优先采用单体+模块化设计）

实际使用时需结合业务阶段判断：初创期项目建议优先验证核心流程，微服务化改造应延迟至日活用户突破10万阈值；成熟系统则可通过该技能优化现有架构，降低跨服务调用延迟。