| 题源类型 | 未标注 |
| 年份/批次 | |
| 适用项目 | 某互联网公司线上商品交易与运营平台 |
| 主题概念 | 它通过规定系统构件、连接件以及约束关系，为软件系统提供可复用的组织模式，使架构设计能够在较高层次上保持清晰和稳定 |
| 常见方法 | 数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格等 |
| 已选论文点 | 调用/返回风格中的层次架构 / 独立构件风格中的隐式调用 / B/S 架构风格 |
| 项目位置/技术/需求 | 在系统接入和业务服务层，我们采用调用/返回风格中的层次架构来满足多入口访问和业务边界清晰的要求 |
| 解决的问题 | 该平台涉及用户交易、运营管理、库存处理和支付对账等业务，如果接入控制、业务规则和数据访问逻辑混杂在一起，不但会增加开发和维护难度，也会导致后续业务调整时影响范围难以控制 |
| 解决的方法 | 为解决这一问题，我们将系统划分为接入层、业务服务层和数据支撑层 |
| 具体的实现 | 接入层采用 Spring Cloud Gateway 作为统一入口，集中完成登录校验、访问限流、请求路由和接口日志记录；业务服务层按照用户、商品、订单、库存、支付和运营等能力划分模块，并通过 Nacos 和 Dubbo 完成服务注册、发现和调用；数据支撑层主要由 MySQL 和 Redis 承担事务数据保存、热点库存缓存和幂等控制等工作 |
| 例子 | 以用户参与活动并提交订单为例，请求先经过统一入口完成身份校验和路由，再由订单、商品和库存等模块协同完成下单校验 |
| 效果 | 通过这种层次化组织，请求入口、业务规则和数据访问边界更加清晰，后续新增运营活动或调整库存策略时，可以主要在相关业务模块内完成修改，减少对支付、消息和后台管理等其他链路的影响 |
| 项目位置/技术/需求 | 在交易中间层，我们采用独立构件风格中的隐式调用来简化构件之间的交互复杂度，降低系统耦合度 |
| 解决的问题 | 线上商品交易具有明显的峰值特征，活动开始后的短时间内会产生大量浏览、下单和支付请求，如果订单创建、库存扣减、支付确认、消息通知和超时关闭全部采用同步调用，任一环节响应变慢都会影响用户主流程 |
| 解决的方法 | 经过调研和测试，我们选择 RocketMQ 作为消息连接件，将订单状态变化、支付结果确认、库存处理和交易关闭等过程通过消息方式进行衔接 |
| 具体的实现 | 实际运行过程中，用户下单成功后，订单模块只完成必要的订单创建和状态记录，库存处理、支付结果回传、消息通知以及未支付订单关闭等工作由相关模块根据消息异步完成 |
| 例子 | 实际运行过程中，用户下单成功后，订单模块只完成必要的订单创建和状态记录，库存处理、支付结果回传、消息通知以及未支付订单关闭等工作由相关模块根据消息异步完成 |
| 效果 | 通过这种发布订阅和异步协作机制，各业务模块只关注自身职责范围内的处理逻辑，活动高峰期可以利用消息队列削峰填谷，外部支付结果短暂延迟时也不会阻塞下单主流程，从而提高了交易链路的稳定性和可扩展性 |
| 项目位置/技术/需求 | 在应用系统层，我们主要采用 B/S 架构风格，解决系统推广难、维护难和多角色访问不一致的问题 |
| 解决的问题 | 该平台的使用人员既包括面向外部的普通用户和商户，也包括公司内部的运营、客服和财务人员，如果分别为各类人员建设厚客户端，不但安装升级成本较高，也会增加版本兼容和问题排查难度 |
| 解决的方法 | 为解决这一问题，我们将主要业务能力集中部署在服务端，用户侧通过移动端和 Web 页面访问交易功能，运营和客服人员通过浏览器访问后台管理功能 |
| 具体的实现 | 前端主要负责页面展示、表单校验和交互引导，复杂的交易规则、库存校验、支付处理和对账逻辑均由服务端统一完成 |
| 例子 | 系统上线后，当商品活动规则、支付校验方式或后台菜单权限发生调整时，项目组只需要在服务端和前端资源中统一发布，不需要逐台处理客户端环境 |
| 效果 | 通过这种 B/S 架构风格，系统在推广过程中对终端环境要求较低，维护工作更加集中，普通用户、商户和内部人员也能够通过统一入口获得较为一致的业务体验 |