亿级分布式系统架构演进实战（十二）- 单元化架构（单元划分与架构设计）

亿级分布式系统架构演进实战（一）- 总体概要
亿级分布式系统架构演进实战（二）- 横向扩展（服务无状态化）
亿级分布式系统架构演进实战（三）- 横向扩展（数据库读写分离）
亿级分布式系统架构演进实战（四）- 横向扩展（负载均衡与弹性伸缩）
亿级分布式系统架构演进实战（五）- 横向扩展（缓存策略设计）
亿级分布式系统架构演进实战（六）- 横向扩展（监控与日志体系）
亿级分布式系统架构演进实战（七）- 横向扩展（安全防护设计）
亿级分布式系统架构演进实战（八）- 垂直拆分（领域划分及垂直分库设计）
亿级分布式系统架构演进实战（九）- 垂直拆分（服务间通信设计）
亿级分布式系统架构演进实战（十）- 垂直拆分（分布式事务管理设计）
亿级分布式系统架构演进实战（十一）- 垂直拆分（服务治理体系、安全架构升级）

一、逻辑单元（Cell）设计

目标：构建可独立运行的自治单元，单元内闭环处理所有业务，避免跨单元强依赖

1.1 分片规则与单元定义

单元粒度：
• 中型单元（百万级用户）：部署10-15个服务实例（8C16G规格），独立数据库分片（MySQL 8C32G）
• 扩展规则：用户量增长20%时触发自动扩容（K8s HPA + ShardingSphere动态分片）

1.2 单元自治原则

核心要求：
• 服务闭环：单元内微服务自包含，跨单元调用需通过GZone代理（禁止直连）。
• 数据闭环：单元内数据库分片存储，仅通过Canal + Kafka异步同步全局数据。

技术实现：

# 北京单元Nacos配置（服务注册隔离）
spring.cloud.nacos.discovery.namespace=bj-cell
spring.cloud.nacos.discovery.server-addr=bj-nacos:8848

# 数据同步配置（Canal监听北京单元Binlog）
canal.instance.master.address=bj-mysql:3306
canal.mq.topic=cell-sync-topic

二、全局服务层（GZone）设计（核心增强）

目标：统一处理跨单元协同服务，保障全局一致性与高可用

2.1 全局配置管理（Nacos动态推送）

核心能力：

1. 配置集中管理：统一维护风控规则、黑白名单、灰度策略等全局配置。
2. 动态生效：配置变更秒级推送至所有单元，无需重启服务。

实现方案：
• 配置发布：

# 全局风控规则（Nacos配置ID=risk_rules）
risk_rules:
  - pattern: "amount > 10000"
    action: "REVIEW"
  - pattern: "ip in blacklist"
    action: "BLOCK"

• 监听与生效：

@NacosConfigListener(dataId = "risk_rules", group = "GLOBAL_GROUP")
public void onRiskRulesUpdate(String newRules) {
    RiskRuleManager.refreshRules(newRules);  // 动态生效
}

2.2 跨单元事务协调（Seata AT模式增强）

核心挑战：跨单元数据操作的原子性与一致性

技术方案：

1. 全局事务ID（XID）：由GZone生成并透传至所有参与单元。
2. 全局锁管理：通过Redis分布式锁替代数据库行锁，提升并发性能。
3. 事务恢复机制：GZone集群持久化事务日志，宕机后自动恢复。

生产配置：

# Seata Server高可用配置（3节点集群）
seata:
  registry:
    type: nacos
    nacos:
      server-addr: gzone-nacos:8848
  config:
    type: nacos
    nacos:
      server-addr: gzone-nacos:8848
  store:
    mode: db
    db:
      url: jdbc:mysql://gzone-mysql:3306/seata
      user: seata
      password: seata

# Redis分布式锁配置
redis.lock.prefix=seata:lock:
redis.lock.expire=30

事务流程：

2.3 跨单元数据同步仲裁

核心问题：单元间数据同步冲突（如用户同时修改手机号）

冲突解决策略：

自动修复流程：

1. 差异检测：定时任务扫描单元间数据差异（如订单状态不一致）。
2. 规则匹配：根据预定义规则自动修复（如以支付单元状态为准）。
3. 人工队列：无法自动修复时，记录到人工处理队列（通过管理台处理）。

三、接入层设计

目标：智能路由流量，支持单元级容灾与灰度发布

3.1 流量路由策略

• DNS智能解析：根据用户IP解析至最近单元（如华北用户→北京单元）。
• API网关路由：支持Header显式指定单元（X-Cell-ID=1），用于调试与灰度。

# Spring Cloud Gateway配置（北京单元路由）
spring.cloud.gateway.routes:
  - id: bj_cell
    uri: lb://bj-cell-service
    predicates:
      - Header=X-Cell-ID, 1

灰度发布：

1. 新版本服务部署至20%实例，标记为Gray。
2. 灰度流量通过Header X-Gray=1 导流。
3. 监控灰度服务成功率，全量发布或回滚。

3.2 容灾与熔断（Sentinel增强）

熔断规则：

# 北京单元熔断规则（异常比例>60%触发）
sentinel:
  degrade:
    rules:
      - resource: bj-cell-service
        grade: EXCEPTION_RATIO
        count: 0.6
        timeWindow: 30
        minRequestAmount: 20

容灾切换流程：

1. 健康检测：Prometheus监控单元HTTP成功率与延迟。
2. 自动熔断：连续3次失败后，标记单元为不健康。
3. 流量切换：DNS更新解析记录，流量导向备用单元。

四、服务层设计

目标：业务逻辑无状态化，支持快速扩缩容

4.1 无状态化实现

• 会话外部化：Spring Session + Redis存储用户状态。

@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 1800)
public class SessionConfig {
    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory("bj-redis", 6379);
    }
}

• 配置外置：数据库连接、缓存地址从Nacos动态获取。

4.2 服务容错设计

降级策略：

@SentinelResource(
    value = "queryProduct", 
    fallback = "queryProductFallback", 
    blockHandler = "queryProductBlock"
)
public Product queryProduct(String id) {
    // 正常查询逻辑
}
public Product queryProductFallback(String id) {
    return Product.DEFAULT;  // 返回默认商品
}

五、数据层设计

目标：保障数据本地化与最终一致性

5.1 单元内分库分表

ShardingSphere分片规则：

rules:
- !SHARDING
  tables:
    user:
      actualDataNodes: cell_${0..15}.user_${0..3}
      databaseStrategy:
        standard:
          shardingColumn: user_id
          shardingAlgorithmName: hash_mod
  shardingAlgorithms:
    hash_mod:
      type: HASH_MOD
      props:
        sharding-count: 16

5.2 跨单元数据同步（最终一致性）

技术实现：

1. Canal监听Binlog：实时捕获数据变更事件。
2. Kafka消息广播：将变更事件发布至全局Topic。
3. 单元消费同步：各单元消费消息并写入本地库。

冲突解决：
• 自动合并：基于时间戳与版本号自动解决大部分冲突。
• 人工干预：剩余冲突记录至管理台，由运维处理。