Back to Details

microservices

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Microservices

微服务

Microservices architecture structures an application as a collection of loosely coupled, independently deployable services. Ideally, each service corresponds to a Bounded Context (DDD).
微服务架构将应用程序构建为一组松耦合、可独立部署的服务。理想情况下，每个服务对应一个限界上下文（DDD）。

When to Use

适用场景

  • Large teams (50+ devs) where coordination on a monolith slows down deployment.
  • Modules have conflicting resource requirements (e.g., one needs huge RAM, another needs GPU).
  • Need to scale specific parts of the system independently.
  • 2025 Reality check: Don't start with Microservices. Start with a Modular Monolith.
  • 大型团队（50名以上开发者）：单体应用的协作会拖慢部署速度。
  • 模块资源需求冲突：例如某个模块需要大量RAM，另一个需要GPU。
  • 需要独立扩展系统的特定部分。
  • 2025年现状提醒：不要从微服务开始，先从模块化单体应用入手。

Quick Start

快速入门

yaml
undefined
yaml
undefined

docker-compose.yml (Simulated Microservices)

docker-compose.yml (Simulated Microservices)

services: order-service: build: ./services/order ports: ["3001:3000"] environment: - DB_HOST=order-db
inventory-service: build: ./services/inventory ports: ["3002:3000"]
api-gateway: image: nginx ports: ["80:80"] depends_on: - order-service - inventory-service
undefined
services: order-service: build: ./services/order ports: ["3001:3000"] environment: - DB_HOST=order-db
inventory-service: build: ./services/inventory ports: ["3002:3000"]
api-gateway: image: nginx ports: ["80:80"] depends_on: - order-service - inventory-service
undefined

Core Concepts

核心概念

Independence

独立性

Each service owns its own data. Service A cannot query Service B's database directly; it must ask Service B via API.
每个服务拥有自己的数据。服务A不能直接查询服务B的数据库，必须通过API请求服务B获取数据。

Inter-Service Communication

服务间通信

  • Synchronous: HTTP/REST or gRPC (Request/Response). Tightly coupled in time.
  • Asynchronous: Message Queues (RabbitMQ, Kafka, SQS). Decoupled in time.
  • 同步通信：HTTP/REST或gRPC（请求/响应模式），时间上耦合紧密。
  • 异步通信：消息队列（RabbitMQ、Kafka、SQS），时间上解耦。

Database per Service

单服务单数据库

Ensures loose coupling. If a service needs data from another, use data replication (Events) or API composition.
确保松耦合。如果某个服务需要其他服务的数据，可使用数据复制（事件驱动）或API组合的方式。

Common Patterns

常见模式

API Gateway

API网关

A single entry point for all clients. Handles routing, auth, rate limiting, and aggregation.
所有客户端的统一入口点，负责路由、认证、限流和聚合。

Circuit Breaker

断路器模式

Detects failures and prevents the application from trying to perform the action that is doomed to fail (e.g., external service down), protecting the system.
检测故障并阻止应用执行必然失败的操作（比如外部服务宕机），从而保护系统。

Saga Pattern

Saga模式

Managing distributed transactions. Since you can't have ACID across services, use Sagas (sequence of local transactions) with compensating actions for rollbacks.
管理分布式事务。由于无法跨服务实现ACID特性，可使用Sagas（一系列本地事务），并通过补偿操作实现回滚。

Best Practices

最佳实践

Do:
  • Automate CI/CD and Infrastructure as Code (Terraform/K8s). You can't manage 50 services manually.
  • Implement Distributed Tracing (OpenTelemetry) immediately.
  • Define clear Service Boundaries (use DDD).
Don't:
  • Don't share code libraries for domain logic (leads to "Distributed Monolith"). Share utils only.
  • Don't use synchronous calls for everything (cascading failures).
  • Don't underestimate the Operational Complexity (Logging, Monitoring, Auth).
建议：
  • 自动化CI/CD和基础设施即代码（Terraform/K8s）。手动管理50个服务是不现实的。
  • 立即实现分布式追踪（OpenTelemetry）。
  • 定义清晰的服务边界（使用DDD）。
禁忌：
  • 不要共享领域逻辑的代码库（会导致“分布式单体”问题），仅可共享工具类。
  • 不要所有调用都使用同步方式（会引发级联故障）。
  • 不要低估运维复杂度（日志、监控、认证）。

Troubleshooting

故障排查

ErrorCauseSolution
Cascading Failure
One service down takes down others.Use Circuit Breakers and Timeouts.
Data inconsistency
Async updates failed.Implement Sagas and Idempotent consumers.
Latency
Too many hops (service -> service -> service).Use Caching, Aggregation at Gateway, or Event-Driven data replication.
错误类型原因解决方案
级联故障
某个服务宕机导致其他服务也崩溃。使用断路器模式和超时机制。
数据不一致
异步更新失败。实现Saga模式和幂等消费者。
延迟过高
服务调用链过长（服务→服务→服务）。使用缓存、在网关层聚合数据，或采用事件驱动的数据复制方式。

References

参考资料