亿级分布式系统架构演进实战（十二）- 单元化架构（单元划分与架构设计）
亿级分布式系统架构演进实战（一）- 总体概要
亿级分布式系统架构演进实战（二）- 横向扩展（服务无状态化）
亿级分布式系统架构演进实战（三）- 横向扩展（数据库读写分离）
亿级分布式系统架构演进实战（四）- 横向扩展（负载均衡与弹性伸缩）
亿级分布式系统架构演进实战（五）- 横向扩展（缓存策略设计）
亿级分布式系统架构演进实战（六）- 横向扩展（监控与日志体系）
亿级分布式系统架构演进实战（七）- 横向扩展（安全防护设计）
亿级分布式系统架构演进实战（八）- 垂直拆分（领域划分及垂直分库设计）
亿级分布式系统架构演进实战（九）- 垂直拆分（服务间通信设计）
亿级分布式系统架构演进实战（十）- 垂直拆分（分布式事务管理设计）
亿级分布式系统架构演进实战（十一）- 垂直拆分（服务治理体系、安全架构升级）
一、逻辑单元（Cell）设计
目标：构建可独立运行的自治单元，单元内闭环处理所有业务，避免跨单元强依赖
1.1 分片规则与单元定义
| 分片维度 | 规则与实现 | 适用场景 |
|---|---|---|
| 用户ID哈希 | cell_id = hash(user_id) % 16（16单元） |
用户中心型业务（社交、电商） |
| 地理位置 | 根据用户IP解析城市编码（如北京=1，上海=2），映射到对应单元 | 本地服务、低延迟业务（物流、游戏） |
| 业务分片 | 按业务线独立分片（如订单单元、支付单元） | 复杂系统解耦（金融、ERP） |
单元粒度：
• 中型单元（百万级用户）：部署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动态推送）
核心能力：
- 配置集中管理：统一维护风控规则、黑白名单、灰度策略等全局配置。
- 动态生效：配置变更秒级推送至所有单元，无需重启服务。
实现方案：
• 配置发布：
# 全局风控规则（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模式增强）
核心挑战：跨单元数据操作的原子性与一致性
技术方案：
- 全局事务ID（XID）：由GZone生成并透传至所有参与单元。
- 全局锁管理：通过Redis分布式锁替代数据库行锁，提升并发性能。
- 事务恢复机制：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 跨单元数据同步仲裁
核心问题：单元间数据同步冲突（如用户同时修改手机号）
冲突解决策略：
| 冲突类型 | 自动解决策略 | 人工干预场景 |
|---|---|---|
| 时间戳冲突 | 最后写入优先（Last Write Win） | 无 |
| 业务规则冲突 | 以核心单元为准（如支付单元状态优先） | 转账金额不一致 |
| 版本号冲突 | 基于Vector Clock合并版本 | 分布式购物车商品更新 |
自动修复流程：
- 差异检测：定时任务扫描单元间数据差异（如订单状态不一致）。
- 规则匹配：根据预定义规则自动修复（如以支付单元状态为准）。
- 人工队列：无法自动修复时，记录到人工处理队列（通过管理台处理）。
三、接入层设计
目标：智能路由流量，支持单元级容灾与灰度发布
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
灰度发布：
- 新版本服务部署至20%实例，标记为
Gray。 - 灰度流量通过Header
X-Gray=1导流。 - 监控灰度服务成功率，全量发布或回滚。
3.2 容灾与熔断（Sentinel增强）
熔断规则：
# 北京单元熔断规则（异常比例>60%触发）
sentinel:
degrade:
rules:
- resource: bj-cell-service
grade: EXCEPTION_RATIO
count: 0.6
timeWindow: 30
minRequestAmount: 20
容灾切换流程：
- 健康检测：Prometheus监控单元HTTP成功率与延迟。
- 自动熔断：连续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 跨单元数据同步（最终一致性）
技术实现：
- Canal监听Binlog：实时捕获数据变更事件。
- Kafka消息广播：将变更事件发布至全局Topic。
- 单元消费同步：各单元消费消息并写入本地库。
冲突解决：
• 自动合并：基于时间戳与版本号自动解决大部分冲突。
• 人工干预：剩余冲突记录至管理台，由运维处理。