Week 3 · Chapter 1 · 微服务架构设计

复习难度：⭐⭐⭐⭐⭐ | 预计时长：6-8小时 | 重点程度：高

1. 服务发现

注册中心原理

服务启动 → 注册自己（IP/Port/健康状态）→ 注册中心存储
消费者启动 → 订阅服务 → 注册中心推送 / 消费者拉取
心跳检测 → 注册中心定期检测 → 超时则剔除

Consul vs Nacos vs Eureka

Consul Nacos Eureka
语言 Go Java Java
一致性 Raft（CP） Raft/Distronic（CP/AP） 最终一致（AP）
健康检查 支持 支持 服务续约
运维复杂度 低（单二进制） 中（需要MySQL） 低
特点 多数据中心 功能最全 AWS Netflix

客户端发现 vs 服务端发现

客户端发现：消费者直接从注册中心获取服务列表，自己负载均衡
  优点：少一跳网络
  缺点：消费者需要集成注册中心SDK

服务端发现：消费者请求 LoadBalancer / Ingress，LB 负责发现
  优点：消费者无感知
  缺点：多一跳

2. 熔断、降级、限流

熔断（Circuit Breaker）

状态机：Closed（正常） → Open（熔断） → HalfOpen（探测）

Closed：所有请求正常通过，失败计数
  → 失败次数 > 阈值 → 跳到 Open

Open：所有请求直接拒绝（快速失败）
  → 等待熔断时间 → 跳到 HalfOpen

HalfOpen：允许一个请求通过
  → 成功 → 回 Closed
  → 失败 → 回 Open

常用实现：Hystrix（已停止维护）/ Sentinel（阿里）/ Resilience4j

降级（Fallback）

// 正常逻辑
func GetProduct(id string) (*Product, error) {
    return productClient.Get(id)
}

// 降级：服务不可用时返回兜底数据
func GetProductWithFallback(id string) (*Product, error) {
    p, err := productClient.Get(id)
    if err != nil {
        // 降级：返回缓存或默认值
        return getProductFromCache(id)
    }
    return p, nil
}

限流

算法 原理 优点 缺点
固定窗口 固定时间窗口内计数 简单 边界两倍突刺
滑动窗口 滚动时间窗口 精确 实现复杂
令牌桶 按速率往桶里放令牌，取令牌处理 可突发 -
漏桶 固定速率消费 平滑 不能突发 
// 令牌桶实现
type TokenBucket struct {
    rate       float64 // 每秒令牌数
    burst      int     // 桶容量
    tokens     float64
    lastUpdate time.Time
    mu         sync.Mutex
}

func (tb *TokenBucket) Allow() bool {
    tb.mu.Lock()
    defer tb.mu.Unlock()
    now := time.Now()
    // 补充令牌
    tb.tokens += now.Sub(tb.lastUpdate).Seconds() * tb.rate
    if tb.tokens > float64(tb.burst) {
        tb.tokens = float64(tb.burst)
    }
    tb.lastUpdate = now
    if tb.tokens >= 1 {
        tb.tokens--
        return true
    }
    return false
}

3. API 网关

网关职责

路由转发 → 协议转换（HTTP → gRPC）
认证鉴权 → JWT / OAuth2 / API Key
限流熔断 → 流量防护
日志监控 → 记录请求日志
灰度发布 → 权重路由

常见网关

网关 特点
Kong Nginx + Lua，插件生态最全
APISIX Apache 顶级项目，Apache APISIX 云原生更强
Spring Cloud Gateway Java，Spring 生态
Envoy Service Mesh 标准，数据面

4. 服务分层架构

经典三层

接入层（Gateway / API）
  ↓
服务层（业务服务，按领域划分）
  ↓
基础层（DB / Cache / MQ / OSS）

你简历里的审批平台如何分层？

接入层：企微消息回调 → 审批网关
服务层：审批核心服务 + 规则引擎 + 消息通知服务
基础层：MySQL（审批单）+ Redis（分布式锁）+ Kafka（回调）+ Consul（服务发现）

高频面试题

Q1：如何保证微服务的高可用？

① 冗余部署（多实例）；② 健康检查 + 自动摘除；③ 限流熔断；④ 异步化（MQ解耦）；⑤ 降级兜底；⑥ 多活容灾（不同机房）

Q2：微服务拆分的原则？

① 领域驱动设计（DDD）；② 单一职责，独立部署；③ 无循环依赖；④ 边界清晰，接口稳定优先于内部实现

Q3：服务间调用超时怎么设置？

① 读接口：超时=TP99+10%；② 写接口：超时=TP99+20%；③ 核心链路：设置 ReadTimeout + WriteTimeout；④ 使用 Context 传递超时