Microservices Architect 是一个面向分布式系统与微服务架构的专家技能，用于在设计与实现微服务架构时提供专业支持，其专长包括服务拆分、服务间通信模式、服务网格实现，以及分布式系统难题的解决。
用途与适用时机 该技能可在以下场景调用：从零开始设计微服务、拆分现有单体应用、实现服务间通信、搭建服务网格或 API 网关、解决分布式系统挑战。资料同时给出了不宜调用的边界：以增量方式迁移遗留系统应使用 /legacy-modernizer；事件流架构应使用 /event-driven-architect；Kubernetes 运维应使用 /kubernetes-specialist；单个服务的 API 设计应使用 /api-designer。
决策框架 在选择通信模式时，资料提供如下判断路径：同步场景下，简单调用可采用 REST/gRPC，复杂路由可采用 API 网关；异步场景下，事件可采用 Kafka/RabbitMQ，命令可采用消息队列；涉及分布式事务时，强一致性采用 Saga（编排式），最终一致性采用 Saga（协同式）。
核心工作流 一是服务拆分：从领域模型中识别限界上下文，定义服务职责（单一目的），为每个服务设计 API，确定各服务的数据归属，规划服务间通信，定义部署策略。二是服务网格实现：选择网格（Istio、Linkerd、Consul），部署边车代理，配置流量管理，通过 mTLS 实现安全，搭建可观测性（追踪、指标），定义重试与熔断策略。三是 Saga 模式实现：识别分布式事务边界，在编排与协同之间选择，定义补偿事务，实现 Saga 协调器（若采用编排式），处理失败场景，为 Saga 状态添加监控。
最佳实践与反模式 最佳实践包括：围绕业务能力而非技术分层设计服务；数据自持，每个服务管理自己的数据库；使用异步通信实现松耦合；实现熔断器以获得容错能力；为失败而设计，一切最终都会失败；使用关联 ID 进行分布式追踪。资料列出的反模式及纠正方式为：分布式单体——服务耦合、兼具两者之弊，应采用真正的限界上下文；共享数据库——紧耦合，应每个服务独立数据库；同步调用链——级联失败，应尽可能异步；无熔断器——级联失败，应实现 Hystrix/Resilience4j；纳米服务——运维负担重，应采用规模合适的服务。
使用方式 资料以技能调用形式给出，属于在相关设计或实现任务中引用该技能来获得架构建议，具体的安装命令、运行环境与集成方式，资料暂未提供。