📌 第一章：架构优化
核心目标：提升系统 高并发 & 高可用能力，优化架构，提高吞吐量。
1.1 微服务高可用优化
解决问题：微服务可能存在 单点故障、扩展性差、调用效率低 等问题。
📍1.1.1 服务无状态化
📌 目的：让服务实例可以 随时扩缩容、快速恢复，避免单点故障。
🚨 可能的问题
| 现象 | 影响 |
|---|---|
| 本地存储 Session，导致用户粘连某个实例 | 实例挂掉后，用户重新登录 |
| 订单等业务逻辑依赖本地缓存 | 容器扩缩时数据丢失 |
| 静态文件（Excel/图片）存本地 | 实例销毁后文件丢失 |
✅ 解决方案
- 去掉本地 Session，使用 Redis / JWT 认证
- 去掉本地缓存，使用 Redis + 本地 LRU 缓存
- 对象存储代替本地存储，如 OSS / MinIO
💡 代码示例
方案 1：使用 Redis 共享 Session
@Configuration
@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 1800)
public class RedisSessionConfig {}
方案 2：JWT 代替 Session
String token = Jwts.builder()
.setSubject(userId)
.setExpiration(new Date(System.currentTimeMillis() + 86400000))
.signWith(SignatureAlgorithm.HS512, SECRET_KEY)
.compact();
📌 流程图
[用户请求] -> [Nginx 负载均衡] -> [多个服务实例] -> [Redis 存储会话]
📍1.1.2 负载均衡（Nginx + Spring Cloud Gateway）
📌 目的：优化请求调度，提高吞吐能力。
✅ 解决方案
- Nginx + 负载均衡（RR / LeastConn / IP Hash）
- Spring Cloud Gateway 提供 API 网关能力
- 长连接（HTTP2 / WebSocket）减少 TCP 开销
- 请求压缩（gzip / brotli）提高传输效率
📌 Nginx 负载均衡示例
upstream backend {
least_conn;
server service1:8080;
server service2:8080;
}
server {
listen 80;
location /api/ {
proxy_pass http://backend;
}
}
📌 Spring Cloud Gateway 配置
spring:
cloud:
gateway:
routes:
- id: user-service
uri: lb://USER-SERVICE
predicates:
- Path=/user/**
📍1.1.3 服务间调用优化（gRPC / HTTP2）
📌 目的：降低服务间延迟，提高 QPS。
✅ 解决方案
| 方案 | 优势 |
|---|---|
| gRPC 替换 Feign | 减少数据包开销，速度提升 7~10 倍 |
| HTTP2 复用连接 | 减少 TCP 建立消耗 |
| 批量请求合并 | 减少网络请求次数 |
💡 gRPC 代码示例
Server 端
public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {
@Override
public void getUser(UserRequest request, StreamObserver<UserResponse> responseObserver) {
UserResponse response = UserResponse.newBuilder().setName("张三").build();
responseObserver.onNext(response);
responseObserver.onCompleted();
}
}
Client 端
ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 50051).usePlaintext().build();
UserServiceGrpc.UserServiceBlockingStub stub = UserServiceGrpc.newBlockingStub(channel);
UserResponse response = stub.getUser(UserRequest.newBuilder().setUserId("123").build());
1.2 异步化 & 事件驱动架构
📌 解决问题：系统 同步阻塞，订单高并发压力大，需要 异步化 提高吞吐。
📍1.2.1 任务异步化（线程池、MQ）
📌 目的：避免业务阻塞，提升并发处理能力。
✅ 解决方案
| 场景 | 方案 |
|---|---|
| 下单扣库存 | MQ 异步处理 |
| 批量任务 | 线程池执行 |
| 延迟任务 | Redis / MQ 处理 |
💡 代码示例
线程池优化
@Bean
public Executor taskExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(10);
executor.setMaxPoolSize(50);
executor.setQueueCapacity(100);
executor.initialize();
return executor;
}
RocketMQ 异步下单
@RocketMQMessageListener(topic = "order", consumerGroup = "order-group")
public class OrderConsumer implements RocketMQListener<String> {
@Override
public void onMessage(String message) {
processOrder(message);
}
}
📍1.2.2 事件驱动架构（RocketMQ + Kafka）
📌 目的：解耦服务，提高系统扩展能力。
✅ 方案
| 场景 | 解决方案 |
|---|---|
| 订单创建 -> 库存扣减 | 事件驱动（MQ） |
| 订单支付 -> 物流发货 | 事件驱动（MQ） |
📌 事件流示意图
[用户下单] -> [订单中心] -> (MQ) -> [库存中心] -> (MQ) -> [物流中心]
1.3 分库分表 & 数据分片
📌 解决问题：数据库单点压力大，单表行数过多影响查询效率。
📍1.3.1 MySQL 水平/垂直拆分
📌 目的：减少单库压力，提高并发处理能力。
✅ 方案
| 拆分方式 | 方案 |
|---|---|
| 垂直拆分 | 拆分订单、用户、支付等 |
| 水平拆分 | 按 用户 ID 取模 分表 |
📌 分库分表示例
CREATE TABLE order_0 (...) PARTITION BY HASH(user_id) PARTITIONS 4;
📍1.3.2 ShardingSphere 代理层优化
📌 目的：屏蔽分库分表复杂性，提高开发效率。
✅ 解决方案
| 方案 | 作用 |
|---|---|
| 读写分离 | 让 查询走从库，写入走主库 |
| 分库分表 | 自动路由 SQL |
ShardingSphere 配置
sharding:
tables:
t_order:
actual-data-nodes: ds${0..1}.t_order${0..1}
key-generator:
column: order_id
type: SNOWFLAKE
🔚 总结
✅ 微服务高可用：服务无状态化 + 负载均衡 + gRPC
✅ 异步化处理：RocketMQ 异步下单 + 线程池优化
✅ 数据库优化：ShardingSphere 读写分离 + 分库分表