适用项目：线上商品的销售与运营平台
复习状态：已复习 1 次 (2026-05-22T07:44:57)
多层架构是一种按职责分层组织系统的软件架构风格，它把复杂系统拆分为若干相互协作但职责单一的层，每一层只向相邻层提供服务并调用相邻层接口，从而降低耦合度，提升系统的可维护性和可扩展性。线上商品的销售与运营平台包含商品管理、订单交易、库存管理、支付结算、营销活动、会员运营和数据统计等多个业务模块，如果把页面展示、交易规则和数据存储混在一起，后续修改活动规则或调整订单流程时就会影响整条链路。因此，在本项目中，我采用表示层、中间层和数据层的三层分层方式，将用户交互、业务处理和数据持久化分离开来，使系统更适合持续迭代和高并发访问。
首先，我在表示层重点处理用户交互和请求入口。表示层主要负责页面展示、表单输入、参数校验和请求分发，不直接处理复杂业务逻辑。在本项目中，买家端、商家端和运营端均采用统一的 Web 入口，前端通过页面组件分别展示商品搜索、购物车、订单确认、优惠券领取、商品上下架和活动配置等功能；同时，我在前端加入了手机号格式校验、地址必填校验、购买数量边界校验和优惠门槛校验，减少无效请求进入后端。例如，在购物车数量输入框中，系统会先拦截 0、负数和超过库存上限的输入；在活动配置表单中，系统会先校验结束时间是否早于开始时间。通过前端分层后，非法表单提交量减少了 72%，首页和核心列表页的平均首屏加载时间从 1.7 秒降到 0.9 秒，用户操作体验更稳定。
其次，我在中间层重点实现订单、库存、营销和支付等核心业务逻辑。中间层是多层架构中最关键的一层，负责完成业务规则判断、流程编排和事务控制，不直接依赖页面细节，也不直接操作数据库。在本项目中，我将订单服务、库存服务、营销服务、会员服务和支付服务统一放在中间层管理，用户提交订单后由中间层依次完成商品有效性校验、优惠券匹配、库存锁定、金额计算和订单状态流转；支付成功后，再由中间层完成订单确认、积分发放和库存真实扣减。对于满减、限购和会员折扣等规则，我把它们统一封装在业务层的规则组件中，避免页面直接写死逻辑。通过这种方式，核心交易链路被拆分为 10 个业务模块和 24 个内部接口，新增一个满减活动时只需要调整营销规则，不需要改动前端和数据层，活动配置上线时间由 1 天缩短到 30 分钟，订单链路平均处理时间从 2.8 秒降到 1.3 秒。
最后，我在数据层重点完成持久化、查询和缓存支持。数据层主要负责 MySQL 表结构设计、DAO 映射、索引优化和热点数据缓存，不参与上层业务判断，但要稳定支撑交易数据的存储和读取。在本项目中，我将订单表、订单明细表、库存表、优惠券表、会员表和支付流水表分开设计，并通过 MyBatis 封装数据访问接口，避免业务层直接拼接 SQL；对于秒杀商品和热销 SKU，我又将库存数量和活动配置缓存到 Redis，减少高频读取对数据库的压力。考虑到订单与库存的写入频率较高，我还对订单表按时间做了分区索引，对库存表增加了 SKU 编号索引，从而提升查询效率。分层优化后，核心订单查询接口的 95% 响应时间控制在 700 毫秒以内，数据库直接访问次数减少了 45%，高峰期库存查询和订单统计也能保持稳定，不会因为局部 SQL 变更影响整个业务链路。