程序化广告系统，包含的产品多见于DSP、DMP、ADX、聚合SDK。每个有一定技术实力的广告公司都会涉及其中一个或多个产品线。基于现在主流的技术路线，如何设计兼容多个产品的的架构将在本篇文章中给出大概的方向。
一、整体架构分层设计
基于广告业务（DSP/DMP/ADX/ 聚合 SDK）的核心流程（数据采集→用户画像→广告匹配→竞价投放→效果反馈），结合 Java 工程端、Python 算法端的技术栈要求，设计微服务架构 + 实时 / 离线数据双处理的分布式系统。整体架构分为 5 层，核心围绕 "高可用、高并发、低延迟、可扩展" 设计，以下是详细方案。
|-----------|------------------|
| 客户端层 | 面向用户/运营/广告主的交互入口 |
| 接入层 | 流量分发、网关控制、负载均衡 |
| 核心服务层 | 微服务集群，业务逻辑核心 |
| 数据层 | 存储+计算，支撑数据流转与分析 |
| 基础设施层 | 容器化、监控、安全等基础支撑 |
二、各层详细设计与技术选型
1. 客户端层（交互入口）
|---------|--------------------------|-------------------------|
| 角色 | 技术选型 | 核心功能 |
| 广告主管理后台 | Web 端（Vue3+Element Plus） | 创建广告计划、设置出价 / 定向、查看投放报表 |
| 运营管理后台 | Web 端（Vue3+Element Plus） | 广告审核、流量管理、系统监控、数据运营 |
| 聚合 SDK | Android/iOS/Web | 流量采集、广告渲染、行为 / 效果数据上报 |
2. 接入层（流量入口治理）
|---------------|----------------------------|---------------------------|
| 组件 | 技术栈 | 核心功能 |
| 反向代理 / 负载均衡 | Nginx | 分发管理后台 / SDK 请求，静态资源缓存 |
| API 网关 | Spring Cloud Gateway | 统一路由、认证授权、限流熔断、日志采集 |
| 高并发网关（ADX 专属） | Spring Cloud Gateway（独立部署） | 优化竞价请求路由，降低延迟（目标 100ms 内） |
核心设计：
- 网关按业务拆分：普通网关（管理后台 / 非竞价请求）+ 竞价网关（ADX 高并发请求），避免资源抢占；
- 限流策略：SDK 请求按 APP 维度限流，ADX 竞价请求按 DSP 维度限流，防止雪崩。
3. 核心服务层（微服务拆分）
基于领域驱动设计（DDD） 拆分微服务，采用 Spring Cloud Alibaba 生态，保证服务治理能力。
|----------------|----------------------------------------------|--------------------------------------------------------------------------------------------|
| 服务模块 | 技术栈 | 核心功能 |
| DMP 服务（用户数据平台） | Java 17 + Spring Boot 3.x + MyBatis-Plus | 1. 标签体系管理（静态标签 + 动态标签）；2. 用户画像构建（实时 + 离线）；3. 标签查询接口（支持多标签组合）；4. 数据合规处理（脱敏 + 授权） |
| DSP 服务（需求方平台） | Java 17 + Spring Boot 3.x + MyBatis-Plus | 1. 广告计划 / 创意管理；2. 定向条件配置（对接 DMP 标签）；3. 出价策略管理（固定出价 + 算法优化出价）；4. 投放效果统计（CTR/CVR/ 消耗） |
| ADX 服务（广告交易平台） | Java 17 + Spring Boot 3.x + Netty | 1. 流量对接（聚合 SDK + 第三方流量）；2. 竞价撮合（请求转发→出价收集→最优筛选）；3. 库存管理（流量质量分级）；4. 合规校验（广告审核 + 反作弊） |
| 聚合 SDK 服务 | Java 17 + Spring Boot 3.x+C++ Object (ios 端) | 1. SDK 版本管理；2. 广告位配置；3. 埋点规则下发；4. 效果数据校验 |
| 算法服务（Python） | Python 3.9 + FastAPI + TensorFlow/PyTorch | 1. 用户画像算法（RFM 模型 + 兴趣挖掘）；2. 出价优化算法（CTR/CVR 预测→动态调价）；3. 广告匹配算法（用户兴趣→广告相关性排序）；4. 模型训练 + 在线推理 |
| 数据处理服务 | Flink 1.17（实时）+ Spark 3.x（离线） | 1. 实时处理：Kafka 数据消费→用户画像更新→投放数据同步；2. 离线处理：批量计算标签 / 报表 / CTR 统计 |
| 管理平台服务 | Java 17 + Spring Boot 3.x | 1. 广告主 / 运营权限管理；2. 报表可视化；3. 系统配置（限流 / 黑名单） |
| 反作弊服务 | Java 17 + Spring Boot 3.x + Redis | 1. 设备 / 用户黑名单管理；2. 异常行为识别（点击作弊 + 刷量）；3. 实时拦截违规请求 |
4. 数据层（存储 + 计算）
| 数据类型 | 存储 / 计算组件 | 用途 |
|---|---|---|
| 结构化数据（广告主 / 计划 / 创意 / 账户） | MySQL 8.0（主从集群 + 读写分离） | 高一致性需求，支持事务，用于核心业务数据存储 |
| 半结构化数据（用户画像 / 标签） | MongoDB 6.0（副本集） | 灵活字段扩展，适合存储用户多维度标签、画像属性 |
| 缓存数据（热点画像 / 竞价结果 / 配置） | Redis 7.0（集群 + 哨兵模式） | 低延迟访问，支撑 ADX 竞价、DMP 标签查询、DSP 出价缓存 |
| 索引数据（标签检索 / 广告检索） | Elasticsearch 8.0 | 支持复杂标签组合查询（如 "25-35 岁 + 女性 + 一线城市 + 美妆兴趣"），提升查询效率 |
| 实时数据流（行为 / 效果 / 竞价） | Kafka 3.x（集群） | 高吞吐削峰，支撑实时数据传输（如 SDK 效果上报、ADX 竞价请求） |
| 离线数据（历史日志 / 训练数据） | HDFS + Hive 3.x | 海量数据存储，用于算法模型训练、离线报表计算 |
| 模型 / 素材存储 | MinIO（对象存储） | 存储 Python 算法模型文件、广告素材（图片 / 视频）、SDK 安装包 |
数据流向设计：
- 实时流：SDK 埋点 → Kafka → Flink → Redis/MongoDB/MySQL（实时更新）；
- 离线流：Kafka → HDFS → Hive → Spark → MySQL/MongoDB（批量更新）；
- 算法数据流：Hive（训练数据）→ Python 训练 → MinIO（模型存储）→ FastAPI（推理接口）→ Java 服务（调用）。
5. 基础设施层（基础支撑）
| 组件 | 技术选型 | 核心功能 |
|---|---|---|
| 容器化部署 | Docker + Kubernetes | 服务集群部署、弹性伸缩、环境一致性 |
| 服务治理 | Nacos（注册发现 + 配置中心） | 服务注册、配置动态下发、健康检查 |
| 熔断限流 | Sentinel | 服务容错、流量控制、降级保护 |
| 分布式追踪 | SkyWalking | 微服务调用链追踪、性能瓶颈定位 |
| 监控告警 | Prometheus + Grafana | 系统指标监控（QPS / 延迟 / 错误率）、自定义告警 |
| 日志收集 | ELK Stack（Elasticsearch+Logstash+Kibana） | 日志集中收集、检索、分析 |
| 安全防护 | Spring Security + JWT + 加密组件 | 接口认证、数据加密（用户数据 / 敏感配置）、广告内容审核 |
三、核心非功能需求设计
广告系统需满足高可用、高并发、低延迟、可扩展四大核心非功能需求：
1. 高可用（99.99%）
- 服务层：集群部署，Nacos 服务发现自动剔除故障节点；
- 数据层：MySQL 主从切换（MGR 集群）、Redis 哨兵模式、Kafka 多副本（3 副本）；
- 容灾设计：跨可用区部署，关键数据定时备份（MySQL 全量 + 增量备份，Hive 数据异地备份）。
2. 高并发（支持每秒 10 万 + 竞价请求）
- 削峰：Kafka 承接 SDK 请求，ADX 异步处理竞价流程；
- 缓存：Redis 缓存热点用户画像、广告创意、竞价结果，减少 DB 查询；
- 异步化：ADX 竞价请求转发→异步收集 DSP 出价，主线程仅负责筛选最优结果。
3. 低延迟（竞价流程≤100ms）
- 网络优化：ADX 与 DSP 服务就近部署，减少跨区域延迟；
- 本地缓存：ADX 节点本地缓存高频标签、广告配置，避免网络开销；
- 序列化：使用 Protobuf 替代 JSON，提升数据传输效率；
- 并发编程：Netty 处理 ADX 竞价请求，减少线程阻塞。
4. 可扩展
- 水平扩展：微服务独立部署，支持按业务峰值单独扩容（如 ADX 服务扩容应对流量高峰）；
- 弹性伸缩：K8s 基于 CPU / 内存使用率自动扩缩容；
- 功能扩展：标签体系支持自定义添加，出价策略支持插件化扩展（新增算法出价无需修改核心代码）。
四、架构优势总结
- 业务解耦：微服务拆分后，DMP/DSP/ADX 可独立迭代，支持单独对接第三方（如 DSP 对接外部广告主，ADX 对接第三方流量）；
- 技术栈适配：Java 负责高并发工程能力，Python 专注算法训练，各司其职；
- 数据闭环：从数据采集→画像构建→广告投放→效果反馈，形成完整闭环，支撑算法优化；
- 可落地性：基于开源框架，降低技术成本，同时支持从小规模试点到大规模扩容的平滑过渡
五、实施步骤
- 优先搭建核心骨架：ADX + 聚合 SDK + 基础 DMP，实现 "广告请求→竞价→展示" 的最小闭环；
- 算法迭代：先上线静态标签 + 固定出价，再逐步引入 Python 算法服务，实现动态画像和智能出价；
- 压测优化：针对 ADX 竞价流程进行专项压测，优化 Redis 缓存策略和 Kafka 分区配置；
- 合规先行：提前对接用户数据采集合规要求（如 GDPR / 国内个人信息保护法），设计数据脱敏和授权机制。