经验分享：RTA/ADX 架构设计层面降本与稳定性优化-平芜编程栈

经验分享：RTA/ADX架构设计层面降本与稳定性优化（系列第九篇）

前面第七篇讲网络流量与序列化优化，第八篇讲并发、缓存、算力资源优化。本篇上升到架构设计维度，不再局限于单机代码、中间件调参，从整体系统分层、模块边界、流量治理、多实例部署、依赖治理等角度，拆解RTA/ADX如何通过架构精简，降低资源开销、减少故障、降低长期迭代成本。所有方案为实战经验，上线前需要做全链路压测与AB实验。

背景：架构带来的隐性成本

很多RTA系统性能瓶颈、资源浪费不完全来自代码或中间件，而是架构本身带来的损耗：

调用层级太深，多层透传、重复序列化反序列化，增加RT与CPU开销；
依赖臃肿，主竞价链路引入大量非必要模块，资源争抢；
流量没有分层治理，高低价值流量共用一套资源，低价值流量挤占核心资源；
模块耦合严重，新增渠道需要改动核心链路，迭代慢、故障风险高；
部署模型一刀切，所有服务统一规格，资源错配，产生大量闲置冗余；
数据链路混杂，实时竞价链路和离线统计/特征计算混在同一个服务里，互相影响。

架构优化核心目标：精简链路层级、隔离变化、按需分配资源、消除无效计算，从而降低机器成本、减少故障损失、降低研发维护成本。

架构成本来源	说明
多层服务透传	请求跨多服务转发，每次跨服务带来网络开销、序列化开销、超时叠加，P99延迟恶化
模块耦合	渠道、策略、日志、特征逻辑混杂，改动一处影响核心竞价链路，故障风险高
流量不隔离	垃圾流量、低价值曝光、测试流量与高价值竞价共用资源，抢占CPU、连接、下游配额
实时/离线混部	离线特征计算、报表统计、日志分析跑在实时竞价实例上，抢占资源
依赖膨胀	主链路引入大量非强依赖组件，内存占用上升，GC抖动变多
实例规格一刀切	所有服务使用相同容器配置，轻量网关和重策略服务资源规格一致，资源浪费

方案一：精简调用层级，缩短主交易链路

RTA主竞价链路对延迟极度敏感，每多一层服务调用，就叠加一次网络RT、序列化、超时风险。

合并不必要的转发层，避免多层网关透传。

反面示例：媒体请求 → 外层网关 → 业务网关 → 竞价服务 → 特征服务 → 返回，多达4层。
优化思路：去掉无业务逻辑的转发层，将简单鉴权、参数校验下沉到入口网关；核心竞价逻辑收敛，主链路尽量控制在2跳以内。
注意区分：不是无脑合并所有模块，只消灭单纯透传、无业务计算的中间层，有独立职责的模块不能强行合并，避免单体膨胀。

减少跨服务序列化次数
多层转发会重复做JSON/PB序列化反序列化。精简层级的附带收益：减少编解码CPU开销，降低GC压力。
本地内联轻量能力
小型配置校验、黑白名单、基础流量过滤，不需要单独拆成服务，直接在网关本地完成，省去一次RPC调用。

边界约束：精简层级不能牺牲隔离性。如果模块变更频率完全不同（例如渠道配置频繁改动，竞价核心极少改动），不能强行合并，否则会导致发布爆炸。

方案二：领域解耦 + 插件化架构（适配器+注册工厂）

第八篇简单提到适配器+注册工厂，站在架构层面完整说明：

拆分核心竞价内核与渠道适配器层

核心内核：出价、预算校验、竞价决策，稳定少变更，独立部署；
适配器插件：不同媒体/广告主协议转换、字段映射，作为可插拔模块。
新增媒体、广告主对接，只开发插件，不改动竞价核心代码，不重新发布内核。

职责单一划分：

接入层：流量鉴权、限流、协议转换、无效流量前置过滤
竞价核心层：出价决策、缓存读取、下游询价调度
异步事件层：埋点、转化回调、计费消息投递，完全和实时链路隔离

收益：

隔离变更风险，插件发布不影响核心竞价服务，减少线上故障；
独立扩缩容：渠道适配器流量波动大，可以单独扩容，不需要扩容竞价核心，节省资源。

方案三：流量分层与资源隔离架构

不同流量价值差异巨大，不能全部放到同一个资源池。架构上做流量分级：

流量分级：高价值付费流量、普通流量、低质量爬虫/异常流量、测试流量。
入口网关做前置分流：

低价值流量：网关直接拦截或轻量兜底返回，根本不进入后端竞价链路，节约下游所有资源；
高价值流量：独享资源池，保障SLA；
测试流量：独立隔离资源池，禁止打生产广告主RTA接口，避免抢占线上资源。

多租户资源隔离：不同广告主/媒体的出站请求使用独立信号量、独立连接池，故障不会横向扩散。

收益：防止劣币驱逐良币，低价值流量不挤占高价值流量算力、带宽。峰值时不需要为了扛垃圾流量扩容整套集群。

方案四：实时链路与离线链路物理隔离，避免混部干扰

很多RTA踩坑：实时竞价实例上同时跑特征更新、离线计算、日志落盘。离线任务会抢占CPU、内存、磁盘IO，引发GC抖动、延迟毛刺。
架构上严格拆分两套体系：

实时集群：只处理同步竞价请求，资源预留给低延迟交易链路；特征只读，不做大量计算。特征更新由离线集群计算好，推送到Redis，实时服务只读取。
离线集群：特征工程、报表统计、预算预计算、日志分析，单独资源池，允许高延迟、高CPU消耗。

特征推送模式：离线集群预计算特征，写入Redis；RTA实时服务只查询，不在主链路内做特征加工。

方案五：依赖裁剪与轻量内核，控制服务体积

主竞价内核剥离非强依赖组件
埋点上报、监控采集、日志组件做可配置开关；非核心组件不要在主请求路径初始化、加载。
配置中心化，本地缓存
使用配置中心，但是配置变更推送到本地内存缓存，主链路不同步远程拉配置，消除额外远程调用。
包瘦身，减少启动内存，降低GC压力。
大依赖包、无用工具类从核心竞价服务移除，减少内存占用。

方案六：部署架构优化，资源错配治理

按模块特性做容器规格差异化

网关：高网络IO，CPU需求低；选择高网络、小CPU规格
竞价核心：IO密集，搭配虚拟线程；内存按需分配
异步消费服务：高吞吐，可弹性伸缩
不再全部使用统一规格容器，避免资源浪费。

就近部署、多region架构
媒体接入网关部署在离媒体就近的可用区，减少跨区流量；核心竞价集群按需部署，跨区流量单独控制。
弹性扩缩容架构
基于QPS、队列长度、P99延迟自动扩缩容。夜间流量低谷自动缩容，释放闲置资源，降低云服务器成本。

方案七：数据链路架构：读写分离，冷热分离

Redis冷热分离
热点设备出价缓存放在内存（Caffeine+Redis）；冷设备数据不常驻内存，避免Redis大内存、高成本。
MySQL读写分离
订单、结算、广告主配置：主库写，从库读；主链路只读取配置，不在竞价主链路写MySQL。所有写入操作交给MQ异步消费。
日志冷热分层
Kafka原始日志短期保存，冷数据转存对象存储，降低存储成本。

配套架构监控指标

指标	用途
服务调用跳数、链路深度	识别过长调用链路，评估精简收益
各模块资源使用率（CPU/内存）	识别资源错配，区分模块负载特征
流量分级占比（高价值/低价值）	评估前置过滤拦截效果
模块变更次数、发布故障数	评估插件化解耦带来的稳定性收益
跨区流量大小	评估就近部署带来的带宽节省
实例空闲资源占比	识别闲置资源，优化容器规格