广告业务系统 之 框架沉淀 —— “数据消费型服务框架”

数据消费型服务统一框架

由于 ADX 系统中，大量数据以流式涌动，整个链路中出现了 “多处流转都需要以消费中间件数据的模式完成“ 的奇观。为了提升代码的复用性、及可扩展性，我们将 ”数据消费“ 逻辑做抽象隔离成统一框架，业务逻辑以 “组件” 的形式进行嵌入。

在具体的实现中，需要用到的就是 Goland 中的 Plugin 功能。

主流程

我们将消费中间件数据的逻辑 确认后，在处理数据的时候，以 抽象函数做接口 实现。

如图，我们把消费数据放置于 channel 中，在 抽象函数 Deal() 中做数据处理。各个业务服务只需实现 Deal() 函数 以组件形式构建就可以直接复用 公共库A’ 。

Plugin 构建

在业务服务 A\B\C 中，我们需要实现对应的 处理函数 Deal()。

在 服务 A 中，除了 消费处理 Deal () 外，还可以覆盖实现 主流程中的 Init() 函数，做一切附带的其他功能实现。

#!/bin/bash

# build
export GOPROXY=https://goproxy.cn,direct
export GONOPROXY=*XXXX*
export GOINSECURE=*XXXX*

mkdir -p target/bin

git config --global url."ssh://git@XXXX:PPPP".insteadOf "https://XXXX"
GOBIN=`pwd`/bin go install XXXX/A'
mv bin/A' bin/A'_consumer

go build -buildmode=plugin -o bin/A.so  ./main
if [[ $? -eq 0 ]]; then
    echo "succeed to build."
else
    echo "fail to build!!!"
fi

实际构建中，我们将 公共库A’ 进行构建后，在把 业务A 以组件模式进行构建。这时构建路径中会存在两个文件，一个为 公共库A’ 的编译文件，一个以 .so 结尾的组件文件。

此时，执行 主流程/公共库A’ 的启动命令即可。

在 ADX 系统中，涵盖多条数据链路，且流转经历的微服务繁多。总结归类，在最大程度提升服务的可维护性，健壮性的同时，降低人智、资源成本 也是我们追寻的目标之一。

---

见后续文章！

推荐阅读：
暨 广告、推荐、搜索 三大顶级复杂业务之 “广告业务系统详叙”
广告业务系统 之 承前启后 —— “消息中心”
广告业务系统 之 数据中转站 —— “日志中心-实时服务监控”
广告业务系统 之 数据桥梁 —— “日志中心-曝光数据流转结算”
广告业务系统 之 核心通道 —— “日志中心-s2s监测上报”
广告业务系统 之 辅助决策 —— “ AB 实验平台”

---

三行代码搞定 —— 反转链表…
Kafka 高吞吐、高性能核心技术及最佳应用场景…
HTTPS 如何保证数据传输安全 —— TLS 协议…
五分钟搭建基于 Prometheus + Grafana 实时监控系统…