测试环境演示：

运营统计中台 （ 账号/密码 speed2025 ）

用户端H5商城

为了解决之前外包开发留下的历史遗留问题，我们对整体系统架构进行了改造。

技术栈与架构改造

为替代原来前后端高度耦合导致的开发效率低、UI/UX 表达受限等问题，我们使用了现代化全栈开源框架（基于 Vue3 + Element Plus UI + Laravel）进行重构。
原平台端与代理商端代码模块各自独立、复用率低，相同逻辑需要多处改动，代码量大且容易产生 BUG。新版运营中台将多个角色端口统一到同一套代码，通过 RBAC 实现按钮级权限控制，配合 CRUD 代码生成器，显著提升中台开发效率。

低侵入性重构

为了用数据分析辅助运营决策，同时兼顾新老系统共用数据库的兼容性，在对系统没有全盘了解的情况下，我们采用了侵入性最小的重构方案：

• 基于 数据库 View（视图） 在数据库层完成主要指标计算；
• 通过 ORM 层对多个 View 虚拟表之间进行关联查询，快速覆盖十几张电商关键指标报表的开发；
• 相比用定时任务生成大量物理报表（用空间换时间），数据库视图在业务体量不大时更优：实时性高（接近 0 延迟）、灵活性高（可随时修改 View 定义而不用重跑脚本修复数据）。

自研商品曝光采集

为收集用户对商品的兴趣并记录曝光转化率，我们对比了商用 SDK（如神策数据、GrowingIO 等），它们功能全面但成本较高。权衡后选择自研实现，并借鉴厂商技术文档中对有效曝光等指标的定义：

• 使用浏览器 Intersection Observer API 实现商品曝光收集；
• 仅当用户真正看到商品（可见比例 ≥ 50% 且停留 ≥ 5 秒）才计为“有效曝光”；
• 支持定时与批量上报，避免频繁请求造成性能和网络负担。

虚拟商品池与自动化排序

为让广告投放不同人群包能定制化商品库、排序、分类乃至装修元素（便于 A/B 测试等），我提出并实现了 虚拟商品池 概念：

• 基于现有上架的几千款商品，建立一层抽象：可无限新建虚拟分类、商品池，并灵活绑定到当天的多个推广计划人群包；
• 技术上需要设计多个 ORM 关联模型并处理复杂的数据关系。

同时，针对大量商品手动排序效率低、效果差的问题，我们基于访问与销售指标报表实现了自动化排序机制：

• 程序自动读取商品表现报表，过滤噪声指标，定时任务刷新排序；
• 经过多轮渐进式迭代后，系统趋于稳定，具备 全自动化排序 + 人工干预 的能力。

UI/UX 优化与可观测性

在运营中台做了大量 UI/UX 优化，例如：

• 分类拖拽排序；
• 跨表格分页的多选/反选交互。

由于后台存在大量自动化行为（技术侧较“黑盒”），为避免隐性 BUG 导致运营误判，中台设计强调 系统可观测性：

• 明确最终数据的计算来源；
• 支持多处交叉验证；
• 中台可实时预览虚拟商品排序结果（与真实用户访问一致）、量化指标排序依据等，提升运营对系统行为的信任度。

运维与安全

为应对业务增长，在运维架构上做了以下工作：

• 多机部署，后端通过 ALB（应用负载均衡） 分发流量；
• 前端静态资源（代码、图片等）托管在 OSS，并通过 CDN 加速；
• 使用开源发布系统 SPUG 实现基于 Git 多分支的快速发布与回滚，解决多人并行开发、测试和独立环境隔离问题。

监控与安全方面：

• 统一收集业务日志与 Web 日志，配置监控告警规则，实时监测系统可用性与关键业务指标；
• 发现 CDN 被恶意刷量后，升级为带 WAF 的 EAS 边缘加速服务；
• 为保障系统与数据安全，聘请外部白帽团队进行渗透测试，发现并修复了若干漏洞（SQL 注入、账号越权、XSS、Cookie 漏洞等）；
• 在框架层增加 API 限流防脚本爆破，并对管理后台登录入口做路由随机编码（仅内部可知、可随时更换）以提高安全性。

小结

在不大范围侵入原系统的前提下，通过技术选型、架构调整与流程优化，达成了以下目标：

• 提升开发效率与代码复用率（统一中台、按钮级 RBAC、代码生成器）；
• 用低侵入性的数据视图方案快速实现关键报表，兼顾实时性与灵活性；
• 自研曝光采集与虚拟商品池实现高度可定制化投放与自动化排序；
• 强化系统可观测性与安全防护，保障运营与数据可靠性；
• 运维支持快速发布回滚与多机弹性扩展，支撑 10 万+ DAU 的业务规模。