共计 1441 个字符，预计需要花费 4 分钟才能阅读完成。
为什么需要分布式系统？
当业务发展到一定规模时，单体架构（Monolithic Architecture）会面临三大困境：
- 开发效率低下 ：所有功能耦合在同一个代码库，团队协作困难
- 扩展性瓶颈 ：无法针对单个模块独立扩展资源
- 技术栈僵化 ：整个系统必须使用相同的技术栈
架构模式对比
单体架构（Monolithic）
- 适合场景 ：初创项目、低频迭代的内部系统
- 优点 ：
- 开发调试简单
- 事务管理方便
- 缺点 ：
- 单点故障影响全局
- 技术债务积累快
微服务架构（Microservices）
- 适合场景 ：中大型互联网应用
- 优点 ：
- 独立开发部署
- 技术栈异构
- 缺点 ：
- 分布式事务复杂
- 运维成本高
Serverless 架构
- 适合场景 ：事件驱动型短时任务
- 优点 ：
- 无需管理基础设施
- 按用量计费
- 缺点 ：
- 冷启动延迟
- 调试困难
实战：Spring Cloud Alibaba 微服务搭建
1. 服务注册与发现（Nacos）
// 服务提供方配置
@SpringBootApplication
@EnableDiscoveryClient // 启用服务注册
public class UserServiceApplication {public static void main(String[] args) {SpringApplication.run(UserServiceApplication.class, args);
}
}2. 声明式 RPC 调用（Feign）
@FeignClient(name = "order-service")
public interface OrderServiceClient {@GetMapping("/orders/{id}")
Order getOrder(@PathVariable Long id); // 自动转换为 HTTP 请求
}3. 分布式 ID 生成（雪花算法）
public class SnowflakeIdGenerator {// 时间戳 (41bit) + 机器 ID(10bit) + 序列号 (12bit)
public synchronized long nextId() {long timestamp = System.currentTimeMillis();
if (timestamp < lastTimestamp) {throw new RuntimeException("时钟回拨异常");
}
// ... 算法核心逻辑
}
}关键问题解决方案
接口幂等性
- token 机制 ：先获取服务端令牌再提交请求
- 唯一索引 ：利用数据库约束防止重复
- 状态机 ：设计不可逆的状态流转
熔断降级配置建议（Sentinel）
- QPS 阈值设置为平均流量的 1.5 倍
- 慢调用比例阈值建议 30%
- 熔断时长设置为 10-30 秒
生产环境检查清单
分布式事务选型
| 方案 | 适用场景 | 特点 |
|---|---|---|
| Seata | 强一致性要求 | 性能损耗大 |
| Saga | 长事务流程 | 需补偿机制 |
Dockerfile 最佳实践
# 使用多阶段构建减少镜像体积
FROM maven:3.8-jdk-11 AS build
COPY . /app
RUN mvn package -DskipTests
FROM openjdk:11-jre-slim
COPY --from=build /app/target/*.jar /app.jar
# 设置非 root 用户运行
USER 1000
ENTRYPOINT ["java", "-jar", "/app.jar"]思考题
当业务需要跨机房部署时，考虑以下设计要点：
1. 服务发现机制需要支持多区域（如 Nacos 集群跨机房部署）
2. 数据同步采用异步复制还是同步强一致？
3. 流量调度策略（DNS 解析 vs 网关路由）
4. 故障自动切换（Failover）方案设计
正文完
