通过电商系统的实际场景解释开发期和运行期质量属性

通过电商系统的实际场景解释开发期和运行期质量属性

6个开发期质量属性

1. 易理解性
   场景：电商系统的订单处理模块设计中，代码需清晰划分支付、库存扣减、物流分配等子模块，并采用分层架构（如Controller-Service-DAO）。新开发人员能快速理解模块分工和调用关系，降低学习成本。
   依据：设计被开发人员理解的难易程度直接影响开发效率（文档中“易理解性定义为设计被开发人员理解的难易程度”）。
2. 可扩展性
   场景：电商促销活动模块需要支持双11、618等多种规则（如满减、秒杀、拼团），通过策略模式实现不同促销策略的动态扩展。新增活动类型时，只需添加新策略类而无须修改核心逻辑。
   依据：文档指出可扩展性是“软件适应新需求或需求变化而增加功能的能力”，此场景体现系统应对变化的能力。
3. 可重用性
   场景：电商用户身份认证模块被设计为独立服务（如OAuth2.0），可供订单系统、积分系统等多个子系统复用，避免重复开发登录验证逻辑。
   依据：文档中可重用性定义为“重用软件系统或某一部分的难易程度”，此设计通过解耦提升复用性。
4. 可测试性
   场景：支付模块采用依赖注入（DI）设计，Mock第三方支付接口（如支付宝、微信）进行单元测试，确保不同支付场景下的逻辑正确性。
   依据：文档要求“对软件测试以证明其满足需求规范的难易程度”，此设计支持自动化测试的便捷性。
5. 可维护性
   场景：电商商品管理模块因需求变更需调整SKU字段，通过模块化的微服务架构及版本控制（Git），快速定位修改点并隔离影响范围。
   依据：文档定义可维护性为“识别修改点并实施修改的难易程度”，微服务架构保障修改局部化。
6. 可移植性
   场景：电商后台管理系统支持同时部署在公有云（如AWS）和私有云环境，通过容器化（Docker）和配置中心实现环境无缝迁移。
   依据：文档将可移植性定义为“软件系统从一个运行环境转移到另一环境的难易程度”，容器技术提升部署灵活性。

7个运行期质量属性

1. 性能（Performance）
   定义：系统及时提供服务的能力，体现为响应速度、吞吐量和并发容量。
   电商场景：用户在“双11”抢购时，系统需在 毫秒级 返回商品详情页、处理订单支付请求。若瞬时并发量达到 每秒10万次请求，系统需通过缓存（如Redis）、异步队列（如RabbitMQ）保障高性能。

2. 安全性（Security）
   定义：保护合法用户访问，阻止未授权操作。
   电商场景：
   支付安全：用户支付时需通过HTTPS加密通信，结合风控系统实时拦截可疑交易。
   数据保护：用户隐私数据（如地址、电话）存储时需加密，并防止类似 SQL注入 或 XSS跨站脚本攻击。
   权限控制：商家后台系统需通过RBAC（基于角色的访问控制）限制操作权限。

3. 可伸缩性（Scalability）
   定义：通过扩展资源应对用户量或数据增长，维持服务质量。
   电商场景：大促期间通过 横向扩容（如阿里云弹性扩容ECS实例数）快速提升处理能力；数据库采用分库分表（如ShardingSphere），避免单表数据量过亿导致的性能瓶颈。

4. 互操作性（Interoperability）
   定义：与其他系统高效交换数据和服务。
   电商场景：当用户支付完成后，系统需与 支付宝/微信支付 接口同步状态；订单生成后需调用 顺丰/中通物流API 推送运单信息，确保跨系统交互无歧义。

5. 可靠性（Reliability）
   定义：长时间无故障运行的能力。
   电商场景：订单系统需确保 最终一致性（如通过分布式事务Seata），即使某次调用失败，通过重试或补偿机制（如MQ消息重投）保证数据不丢失。例如，用户下单后若库存服务暂时宕机，系统应自动恢复，避免超卖。

6. 可用性（Availability）
   定义：系统正常工作时间占总时间的比例。
   电商场景：
   多活部署：核心业务（如商品搜索）采用 异地多活架构（如阿里单元化部署），单机房故障时流量自动切换。
   故障转移：通过Nginx+Keepalived实现负载均衡，某台服务器宕机时请求自动路由到健康节点。

7. 鲁棒性（Robustness，健壮性）
   定义：异常情况下（如错误输入、部分故障）仍能降级运行。
   电商场景：
   异常输入处理：若用户在搜索框中输入非法字符（如“SELECT * FROM users”），系统应拦截并返回友好提示，而非抛出数据库错误。
   服务降级：当推荐系统超负荷时，可暂时关闭个性化推荐功能，优先保障核心购物流程可用。