一、核心概念

微服务架构是将单体应用拆分成一组小型服务的架构风格，每个服务：

• 独立部署：拥有独立的进程和数据库
• 职责单一：围绕业务能力构建
• 自治性强：可独立开发、测试、部署
• 轻量通信：通常使用 HTTP/REST 或消息队列

考察点：能否基于业务场景合理拆分服务，避免过度拆分和拆分不足。

---

二、微服务划分原则

1. DDD（领域驱动设计）思想

核心思路：按业务领域（Domain）划分，而非技术层次。

• 识别限界上下文（Bounded Context）：每个上下文对应一个微服务
• 聚合根（Aggregate Root）：确定数据一致性边界
• 领域事件：服务间通过事件解耦

2. 服务拆分的三大维度

维度	说明	示例
业务维度	按功能模块拆分	用户服务、订单服务、商品服务
性能维度	高并发模块独立	秒杀服务、搜索服务
团队维度	按组织架构划分	康威定律：架构反映沟通结构

3. 拆分最佳实践

✅ 应该拆分：

• 业务边界清晰（如用户管理、订单管理）
• 变更频率差异大（营销活动频繁变更，可独立为促销服务）
• 性能要求迥异（搜索服务需要高 QPS，可独立优化）

❌ 避免过度拆分：

• 服务间频繁调用（增加网络开销和复杂度）
• 事务边界模糊（分布式事务成本高）
• 团队规模小（管理成本超过收益）

---

三、淘宝系统微服务划分示例

架构分层

┌─────────────────────────────────────────┐
│         接入层（API Gateway）            │
│    (统一鉴权、限流、路由、协议转换)       │
└─────────────────────────────────────────┘
               ↓
┌─────────────────────────────────────────┐
│              业务服务层                  │
├─────────────────────────────────────────┤
│ 用户服务 | 商品服务 | 订单服务 | 支付服务│
│ 营销服务 | 搜索服务 | 物流服务 | 评价服务│
└─────────────────────────────────────────┘
               ↓
┌─────────────────────────────────────────┐
│             中间件/基础设施               │
│  注册中心 | 配置中心 | 服务网格 | 消息队列│
└─────────────────────────────────────────┘

核心服务划分

1. 用户中心（User Service）

• 职责：用户注册、登录、资料管理、权限
• 数据：用户基本信息、认证凭证
• 技术：Redis 缓存热点数据、SSO 单点登录

2. 商品服务（Product Service）

• 职责：SPU/SKU 管理、库存、分类、详情页
• 拆分细化：
  • 商品基础服务（CRUD）
  • 库存服务（高并发扣减，独立优化）
  • 搜索服务（ES 搜索引擎，读写分离）
• 技术：读写分离、缓存多级（本地 + Redis）

3. 订单服务（Order Service）

• 职责：下单、订单状态流转、订单查询
• 关键点：
  • 分库分表（按用户 ID 哈希）
  • 状态机管理（待支付→已支付→已发货→完成）
• 技术：TCC/Saga 分布式事务、消息队列异步解耦

4. 支付服务（Payment Service）

• 职责：对接支付宝/微信、支付回调、账单
• 安全：幂等性设计、异步通知重试

5. 营销服务（Promotion Service）

• 职责：优惠券、满减、秒杀、拼团
• 特点：规则变化快，独立部署降低风险
• 技术：规则引擎（如 Drools）、缓存预热

6. 物流服务（Logistics Service）

• 职责：物流信息推送、轨迹跟踪
• 特点：对接第三方物流 API

7. 消息通知服务（Notification Service）

• 职责：短信、邮件、站内信、Push
• 技术：消息队列削峰填谷

---

四、关键技术考量

1. 服务间通信

方式	适用场景	示例
同步调用	强一致性要求	HTTP/gRPC（订单查库存）
异步消息	最终一致性	Kafka/RabbitMQ（订单→物流）

2. 数据一致性

• 强一致性：分布式事务（TCC、Seata）
• 最终一致性：Saga 模式、本地消息表

3. 服务治理

# 关键组件
注册中心: Nacos / Eureka
配置中心: Apollo / Nacos
负载均衡: Ribbon / LoadBalancer
熔断降级: Sentinel / Hystrix
链路追踪: SkyWalking / Zipkin
API 网关: Spring Cloud Gateway / Kong

---

五、性能与容错优化

1. 缓存策略

// 多级缓存：本地缓存 + Redis
@Cacheable(value = "product", key = "#id")
public Product getProductById(Long id) {
    return productRepository.findById(id);
}

2. 限流降级

// Sentinel 限流配置
@SentinelResource(value = "createOrder", 
    blockHandler = "handleBlock",
    fallback = "handleFallback")
public Order createOrder(OrderDTO dto) {
    // 核心下单逻辑
}

3. 异步解耦

// 订单创建后异步发送消息
@Transactional
public void createOrder(Order order) {
    orderRepository.save(order);
    // 发送消息到 MQ（记录本地消息表保证可靠性）
    messageService.sendOrderCreatedEvent(order);
}

---

六、答题总结

回答框架（2-3分钟）：

1. 定义微服务：独立部署、业务导向、轻量通信
2. 划分原则：DDD 领域驱动、按业务/性能/团队拆分
3. 淘宝案例：列举核心服务（用户、商品、订单、支付）+ 简述职责
4. 技术选型：
   • 通信：同步（gRPC）+ 异步（Kafka）
   • 治理：Nacos、Sentinel、Gateway
   • 数据：分库分表、分布式事务（Seata）
5. 优化点：缓存、限流、异步、监控

核心亮点：

• 强调业务理解（DDD）而非盲目拆分
• 提及真实痛点（分布式事务、服务治理）
• 结合实际技术栈（Spring Cloud Alibaba）

---

延伸问题：

• 如何保证分布式事务一致性？
• 微服务拆分后如何避免循环依赖？
• 服务粒度过细时如何应对？