如何建设一个电子商务网站google收录提交入口
📌 第一章：架构优化
核心目标：提升系统 高并发 & 高可用能力，优化架构，提高吞吐量。
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-serviceuri: lb://USER-SERVICEpredicates:- Path=/user/**
📍1.1.3 服务间调用优化（gRPC / HTTP2）
📌 目的：降低服务间延迟，提高 QPS。
✅ 解决方案
| 方案 | 优势 |
|---|---|
| gRPC 替换 Feign | 减少数据包开销，速度提升 7~10 倍 |
| HTTP2 复用连接 | 减少 TCP 建立消耗 |
| 批量请求合并 | 减少网络请求次数 |
💡 gRPC 代码示例
Server 端
public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {@Overridepublic 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> {@Overridepublic 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_idtype: SNOWFLAKE
🔚 总结
✅ 微服务高可用：服务无状态化 + 负载均衡 + gRPC
✅ 异步化处理：RocketMQ 异步下单 + 线程池优化
✅ 数据库优化：ShardingSphere 读写分离 + 分库分表