当前位置：首页 > news >正文

10. 软件设计架构-经典架构问题

news 来源：原创 2025/9/20 14:09:23

文章目录

前言
一、高并发场景下的系统崩溃
- 1. 问题描述
- 2. 解决方案：
- 3. 案例分析：电商秒杀系统
二、单体架构到微服务的拆分陷阱
- 1. 问题描述
- 2. 解决方案：
- 3. 案例分析：在线教育平台拆分
三、分布式系统中的数据一致性难题
- 1. 问题描述
- 2. 解决方案：
- 3. 案例分析：订单与库存最终一致性
四、缓存穿透、雪崩与击穿
- 1. 问题描述
- 2. 解决方案：
- 3. 案例分析：社交平台热点帖子
五、技术选型的权衡与落地
- 1. 问题描述
- 2. 决策框架：
- 3. 案例分析：日志采集系统选型
六、系统扩展性与弹性设计
- 1. 关键设计模式
- 2. 案例：视频转码服务
七、总结

前言

架构思维‌

从程序员成长为架构师，技术视野需要从局部代码设计扩展到系统级架构设计，以下是转型过程中必然遇到的常见经典架构问题，结合解决方案和案例解析，帮助构建系统性架构思维。

一、高并发场景下的系统崩溃

1. 问题描述

突发流量（如秒杀、抢购）导致服务不可用，数据库崩溃。

2. 解决方案：

1. 流量分层削峰：CDN + 静态资源缓存 → 负载均衡（Nginx） → 服务层限流（令牌桶、漏桶）→ 异步队列（Kafka/RabbitMQ）→ 数据库分库分表。
2. 缓存策略：Redis 集群缓存热点数据，设置本地缓存（Guava Cache）减少穿透。
3. 数据库优化：读写分离、分库分表（ShardingSphere）、连接池优化。

3. 案例分析：电商秒杀系统

用户请求先经过 Nginx 负载均衡到多台 Tomcat 服务器。
网关层使用 Sentinel 实现 QPS 限流，拦截 90% 的无效请求。
库存预扣减通过 Redis 原子操作（DECR）确保一致性，剩余请求进入 Kafka 异步处理订单。
数据库使用分库分表（订单按用户ID哈希），避免单表瓶颈。

二、单体架构到微服务的拆分陷阱

1. 问题描述

单体应用臃肿，团队协作困难，如何合理拆分服务？

2. 解决方案：

1. 领域驱动设计（DDD）：通过限界上下文（Bounded Context）划分服务边界。
2. 拆分策略：横向拆分（按功能模块）或纵向拆分（按业务领域）。
3. 服务治理：服务注册发现（Consul/Nacos）、API 网关（Spring Cloud Gateway）、分布式配置中心。

3. 案例分析：在线教育平台拆分

用户服务：管理注册、登录、权限。
课程服务：课程发布、目录管理。
订单服务：支付、交易流水。
使用 Spring Cloud Alibaba 生态，通过 OpenFeign 实现服务间调用，Seata 处理分布式事务。

三、分布式系统中的数据一致性难题

1. 问题描述

跨服务的数据操作如何保证一致性？如订单支付后库存扣减失败。

2. 解决方案：

1. 强一致性：分布式事务（2PC、3PC），牺牲性能换取一致性。
2. 最终一致性：

本地消息表
业务与消息表同库事务，异步重试。
事务消息
RocketMQ 事务消息确保消息必达。
Saga 模式
通过补偿机制回滚分布式操作。

3. 案例分析：订单与库存最终一致性

订单服务创建订单，写入本地消息表（状态为“待扣减库存”）。
消息队列发送扣减库存事件，库存服务消费成功后确认消息。
若库存不足，触发补偿逻辑：取消订单并通知用户。

四、缓存穿透、雪崩与击穿

1. 问题描述

缓存使用不当导致数据库压力骤增。

2. 解决方案：

穿透
布隆过滤器拦截无效 Key，空值缓存（设置短过期时间）。
雪崩
缓存过期时间随机化，多级缓存（Redis + Caffeine）。
击穿
热点数据永不过期，互斥锁（Redis SETNX）重建缓存。

3. 案例分析：社交平台热点帖子

使用布隆过滤器（Redisson 实现）过滤 80% 的非法帖子ID 查询。
帖子详情缓存设置基础过期时间（30 分钟） + 随机偏移（±5 分钟）。
针对明星热点动态，采用本地缓存 + Redis 双读策略，避免击穿。

五、技术选型的权衡与落地

1. 问题描述

如何选择适合当前业务的技术栈？

2. 决策框架：

1. 业务需求：高并发选 Kafka，复杂业务逻辑选 RabbitMQ。
2. 团队能力：熟悉 Java 则选 Spring Cloud，轻量级可选 Dubbo。
3. 社区生态：优先选择有活跃社区和维护的框架（如 Apache 项目）。

3. 案例分析：日志采集系统选型

需求：每秒百万级日志写入，允许少量丢失。
候选：Elasticsearch（搜索强） vs ClickHouse（分析快）。
决策：选择 ClickHouse + Kafka，利用 ClickHouse 的列式存储高效压缩和分析日志。

六、系统扩展性与弹性设计

1. 关键设计模式

1. 水平扩展：无状态服务设计，通过 Kubernetes 自动扩缩容。
2. 弹性模式：熔断（Hystrix）、降级（返回兜底数据）、限流（RateLimiter）。

2. 案例：视频转码服务

转码任务提交至 Kafka，Worker 集群根据队列长度自动扩容 Pod。
当转码服务超时，触发熔断，降级为返回低清晰度视频。

七、总结

架构设计的核心在于平衡（性能 vs 一致性、复杂度 vs 扩展性）与取舍。

推荐学习路径：

理论：《软件架构设计：大型网站技术架构与业务架构融合之道》
实践：参与开源项目（如 Apache Dubbo、SkyWalking），分析 GitHub 优秀架构案例。
工具：熟练使用架构绘图工具（C4 Model、ArchiMate）表达设计思想。

本文的引用仅限自我学习如有侵权，请联系作者删除。
参考知识
程序员到架构师，定会遇到的经典架构问题！

文章目录

前言

一、高并发场景下的系统崩溃

1. 问题描述

2. 解决方案：

3. 案例分析：电商秒杀系统

二、单体架构到微服务的拆分陷阱

1. 问题描述

2. 解决方案：

3. 案例分析：在线教育平台拆分

三、分布式系统中的数据一致性难题

1. 问题描述

2. 解决方案：

3. 案例分析：订单与库存最终一致性

四、缓存穿透、雪崩与击穿

1. 问题描述

2. 解决方案：

3. 案例分析：社交平台热点帖子

五、技术选型的权衡与落地

1. 问题描述

2. 决策框架：

3. 案例分析：日志采集系统选型

六、系统扩展性与弹性设计

1. 关键设计模式

2. 案例：视频转码服务

七、总结

相关文章：