搭建一个网上商城平台是一项复杂的系统工程，涉及前端展示、后端逻辑、数据库设计以及高并发架构等多个技术维度。一个优秀的商城系统不仅要能支撑日常的商品浏览与交易，更需要在大促活动等流量高峰期保持稳定运行。这就要求我们在建设之初，从全局架构出发，合理规划业务边界，设计具备高扩展性的数据模型，并针对核心交易链路制定严密的并发控制策略。
业务领域驱动与微服务架构拆分
在商城系统发展的早期，团队往往会选择单体架构来快速验证业务模式。然而，随着商品类目的增加和业务逻辑的日益复杂，单体应用会变得极其臃肿，代码耦合度极高，每次发布都需要重新部署整个系统，严重影响了系统的迭代效率。引入微服务架构成为了解决这一痛点的必然选择。通过将庞大的单体应用拆分为多个独立运行的小型服务，每个服务专注于单一业务领域，可以实现独立开发、测试和部署。
如何合理地拆分微服务是架构设计的核心难点。我们可以采用领域驱动设计（DDD）的方法论，通过事件风暴梳理出商城的核心领域模型。通常，一个标准的电商平台可以划分为用户中心、商品中心、订单中心、支付中心、促销中心以及库存中心等几个核心微服务。用户中心负责账户管理与鉴权；商品中心维护SPU与SKU数据；订单中心处理订单状态机流转；支付中心对接第三方支付网关；促销中心计算优惠金额；库存中心则保障库存数据的准确性。这种划分方式不仅符合业务直觉，也能有效隔离不同业务线之间的相互影响。
服务拆分后，服务间的通信机制需要重新设计。对于同步调用场景，如订单创建时需要调用库存服务进行扣减，通常采用RESTful API或gRPC协议。gRPC基于HTTP/2和Protobuf，具有更高的传输效率和更低的延迟，非常适合内部微服务间的高频通信。而对于异步解耦场景，如支付成功后通知订单服务更新状态，则应该引入消息队列（如RabbitMQ或Kafka）进行异步处理。这种发布订阅模式不仅能削峰填谷，还能在服务故障时保证消息不丢失，提升系统的整体容错能力。
商品与订单核心链路的数据模型设计
商品中心是商城系统的基石，其数据模型设计直接决定了前端的展示灵活性和后端的处理效率。传统的单表设计无法满足多规格商品的存储需求。现代商城系统通常采用SPU（标准化产品单元）和SKU（库存量单位）分离的设计模式。SPU表存储商品的基础信息，如名称、品牌、详情描述等；SKU表则存储具体的规格组合、价格和库存信息。同时，还需要一张规格属性表来维护SPU与SKU之间的映射关系。这种设计能够灵活应对各种商品规格组合，避免数据冗余。
订单中心的数据模型设计则更为复杂。订单不仅需要记录用户的购买信息，还要反映交易的整个生命周期。订单状态机是订单系统的核心，它定义了订单从待支付、已支付、待发货、已发货到已完成或已取消的状态流转规则。在数据库层面，随着订单量的不断增长，单表很快就会遇到性能瓶颈。因此，在系统建设初期就应该规划好分库分表策略。通常可以采用用户ID作为分片键，将同一用户的订单路由到同一个数据库分片中，这样既能分散写入压力，又能保证单用户查询的高效性。
下面是一个基于状态模式实现的订单状态流转代码示例，通过定义不同的状态类来封装各自的行为，避免了冗长的条件判断语句。
public class OrderContext {
private OrderState currentState;
public OrderContext() {
this.currentState = new UnpaidState(this);
}
public void setState(OrderState state) {
this.currentState = state;
}
public void payOrder() {
currentState.pay();
}
public void shipOrder() {
currentState.ship();
}
}
interface OrderState {
void pay();
void ship();
}
class UnpaidState implements OrderState {
private OrderContext context;
public UnpaidState(OrderContext context) {
this.context = context;
}
@Override
public void pay() {
System.out.println("订单已支付，等待发货");
context.setState(new PaidState(context));
}
@Override
public void ship() {
System.out.println("未支付订单无法发货");
}
}
class PaidState implements OrderState {
private OrderContext context;
public PaidState(OrderContext context) {
this.context = context;
}
@Override
public void pay() {
System.out.println("订单已支付，请勿重复支付");
}
@Override
public void ship() {
System.out.println("订单已发货，等待收货");
context.setState(new ShippedState(context));
}
}
上述代码展示了如何利用状态模式将订单状态的流转逻辑解耦。每个状态类只关心自己能够处理的事件以及流转的下一个状态，使得订单逻辑的扩展变得非常容易。当需要增加新的状态或修改流转规则时，只需修改对应的状态类，而无需改动订单核心逻辑。
高并发场景下的库存扣减与一致性保障
在秒杀或大促活动期间，库存超卖是电商平台最容易发生也最严重的事故。当大量并发请求同时查询到库存充足并尝试扣减时，如果缺乏有效的并发控制，极易出现库存为负数的情况。解决超卖问题的方案通常有悲观锁、乐观锁和分布式锁。悲观锁虽然能保证强一致性，但在高并发下会严重阻塞线程，导致系统吞吐量骤降。乐观锁通过版本号控制，虽然无锁，但在高并发冲突频繁的场景下重试成本极高。
目前业界主流的解决方案是结合缓存与Lua脚本进行库存扣减。将库存数据预热到Redis中，利用Redis单线程执行Lua脚本的原子性，将查询库存与扣减操作封装在一个Lua脚本中。这样既能利用内存的高速读写特性提升并发能力，又能保证扣减操作的原子性，彻底杜绝超卖现象。当Redis扣减成功后，再通过消息队列异步通知数据库进行最终的库存同步。
然而，缓存扣减成功只代表用户获得了购买资格，后续还需要生成订单并扣减数据库库存。在这个跨服务、跨数据源的链路中，如何保证分布式事务的最终一致性是一个巨大的挑战。我们可以采用基于消息队列的可靠消息最终一致性方案。订单服务在创建订单时，先向本地数据库发送一条半消息，确保本地事务（创建订单）与消息发送的原子性。当本地事务提交后，消息队列将消息投递给库存服务，库存服务消费消息并扣减数据库库存。如果库存服务处理失败，消息队列会自动重试，直到成功为止。这种机制有效保障了在分布式环境下数据状态的最终一致。
下面是一个利用Redis执行Lua脚本进行原子性库存扣减的代码示例。
local key = KEYS[1]
local quantity = tonumber(ARGV[1])
local current_stock = tonumber(redis.call('get', key) or '0')
if current_stock >= quantity then
redis.call('decrby', key, quantity)
return 1 -- 扣减成功
else
return 0 -- 库存不足
end
这段Lua脚本在Redis服务器端原子执行，首先获取当前库存，判断是否大于等于请求扣减的数量，如果满足条件则执行扣减并返回成功标识，否则返回失败标识。由于整个过程在Redis内部是顺序执行的，不会被其他命令打断，因此从根本上避免了并发带来的超卖问题。