microservices-architect

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Microservices Architect

Microservices架构师

Purpose

目标

Provides expertise in designing and implementing microservices architectures. Specializes in service decomposition, inter-service communication patterns, service mesh implementation, and solving distributed systems challenges.

提供设计和实现Microservices架构的专业能力，专注于服务拆分、服务间通信模式、Service Mesh实现以及解决分布式系统相关挑战。

When to Use

适用场景

Decomposing monoliths into microservices
Defining service boundaries and APIs
Implementing service mesh (Istio, Linkerd)
Designing API gateway patterns
Handling distributed transactions (Saga pattern)
Implementing event-driven communication
Setting up service discovery and load balancing
Designing for resilience (circuit breakers, retries)

将单体应用拆分为Microservices
定义服务边界与API
实现Service Mesh（Istio、Linkerd）
设计API Gateway模式
处理分布式事务（Saga模式）
实现事件驱动型通信
搭建服务发现与负载均衡
设计弹性架构（断路器、重试机制）

Quick Start

快速入门

Invoke this skill when:

Designing microservices from scratch
Decomposing existing monoliths
Implementing service-to-service communication
Setting up service mesh or API gateway
Solving distributed system challenges

Do NOT invoke when:

Migrating legacy systems incrementally → use
```
/legacy-modernizer
```
Event streaming architecture → use
```
/event-driven-architect
```
Kubernetes operations → use
```
/kubernetes-specialist
```
Single service API design → use
```
/api-designer
```

调用该技能的场景：

从零开始设计Microservices
拆分现有单体应用
实现服务间通信
搭建Service Mesh或API Gateway
解决分布式系统相关挑战

请勿调用的场景：

增量迁移遗留系统 → 使用
```
/legacy-modernizer
```
事件流架构 → 使用
```
/event-driven-architect
```
Kubernetes运维 → 使用
```
/kubernetes-specialist
```
单一服务API设计 → 使用
```
/api-designer
```

Decision Framework

决策框架

Communication Pattern?
├── Synchronous
│   ├── Simple calls → REST/gRPC
│   └── Complex routing → API Gateway
├── Asynchronous
│   ├── Events → Kafka/RabbitMQ
│   └── Commands → Message queues
└── Distributed Transaction
    ├── Strong consistency → Saga (orchestration)
    └── Eventual consistency → Saga (choreography)

Communication Pattern?
├── Synchronous
│   ├── Simple calls → REST/gRPC
│   └── Complex routing → API Gateway
├── Asynchronous
│   ├── Events → Kafka/RabbitMQ
│   └── Commands → Message queues
└── Distributed Transaction
    ├── Strong consistency → Saga (orchestration)
    └── Eventual consistency → Saga (choreography)

Core Workflows

核心工作流程

1. Service Decomposition

1. 服务拆分

Identify bounded contexts from domain model
Define service responsibilities (single purpose)
Design APIs for each service
Determine data ownership per service
Plan inter-service communication
Define deployment strategy

从领域模型中识别限界上下文
定义服务职责（单一目标）
为每个服务设计API
确定每个服务的数据所有权
规划服务间通信
定义部署策略

2. Service Mesh Implementation

2. Service Mesh实现

Select mesh (Istio, Linkerd, Consul)
Deploy sidecar proxies
Configure traffic management
Implement mTLS for security
Set up observability (tracing, metrics)
Define retry and circuit breaker policies

选择网格方案（Istio、Linkerd、Consul）
部署Sidecar代理
配置流量管理
实现mTLS安全机制
搭建可观测性（链路追踪、指标监控）
定义重试与断路器策略

3. Saga Pattern Implementation

3. Saga模式实现

Identify distributed transaction boundaries
Choose orchestration vs choreography
Define compensating transactions
Implement saga coordinator (if orchestrated)
Handle failure scenarios
Add monitoring for saga status

识别分布式事务边界
选择orchestration或choreography模式
定义补偿事务
实现Saga协调器（若采用orchestration模式）
处理故障场景
添加Saga状态监控

Best Practices

最佳实践

Design services around business capabilities, not technical layers
Own your data—each service manages its own database
Use asynchronous communication for loose coupling
Implement circuit breakers for fault tolerance
Design for failure—everything will fail eventually
Use correlation IDs for distributed tracing

围绕业务能力而非技术层设计服务
自主管理数据——每个服务独立管理自身数据库
使用异步通信实现松耦合
实现断路器以提升容错性
面向故障设计——所有组件最终都会出现故障
使用关联ID实现分布式链路追踪

Anti-Patterns

反模式

Anti-Pattern	Problem	Correct Approach
Distributed monolith	Coupled services, worst of both	True bounded contexts
Shared database	Tight coupling	Database per service
Synchronous chains	Cascading failures	Async where possible
No circuit breakers	Cascading failures	Implement Hystrix/Resilience4j
Nano-services	Operational overhead	Right-sized services

反模式	问题	正确方案
分布式单体	服务耦合，兼具两者的缺点	真正的限界上下文
共享数据库	强耦合	每个服务独立数据库
同步调用链	级联故障	尽可能使用异步通信
未实现断路器	级联故障	实现Hystrix/Resilience4j
微服务过细（Nano-services）	运维开销过大	合理大小的服务