如何设计一个易扩展、易运维的内容下发服务架构?

开发 架构 运维
作者总结内容下发服务遇到的常见问题和挑战,设计出一套灵活架构来支持不断变化的业务,重点梳理在内容服务下发内容时需要关注的点、拆分内容下发服务各个环节,通过分层架构,最终达到易扩展、易运维的业务效果。

内容为王时代,任何一个To C的App都会有内容下发服务,内容包含商品、图文、视频等,比如在淘系App上,首页和各个垂类频道页充满了各类内容,这些页面业务变化非常较快,如何设计一个易扩展、稳定、低延迟的内容下发接口,需要开发同学不断思考摸索。作者总结内容下发服务遇到的常见问题和挑战,设计出一套灵活架构来支持不断变化的业务, 重点梳理在内容服务下发内容时需要关注的点、拆分内容下发服务各个环节,通过分层架构,最终达到易扩展、易运维的业务效果。

重要术语解释

  1. 内容 :包括商品、图文、视频等,服务端通过算法推荐,最终下发给客户端消费的内容
  2. 补齐数据源 :对于内容id,提供一个或多个维度的关联信息
  3. 内容补齐 :获取到内容id后,请求不同补齐数据源,获取内容周边素材,用于客户端展示

常见服务分类

作者在阿里做过和学习过不少服务实现,如下,给阿里服务体系中常见服务大致分一个类,每个类别有些是应用层,有些是中间层,这里不作赘述,这里我们重点讨论内容型服务

主要关注点

比如对于我们淘系业务,搭建一套服务,我们需要先想清楚下面的几个点

  1. 内容来源:从算法、运营配置或者其他渠道来,唯一标识内容id的key向量是哪些,基于这些id,如何进行相关内容补齐
  2. 内容约束:算法推荐比较稳定,但是运营配置的内容,可能会过期,不能满足客户端展示需求,我们需要保证内容完整性,校验内容的一致性
  3. 内容运维:内容下发服务上线后,业务会不断变化,内容筛选条件的增减,客户端也在不断迭代,接口设计需要考虑灵活性

常见问题及解决方案

面临问题

  1. 各种字段需要补齐 :不同字段来源于不同数据源,容易出现面条式代码,需要灵活的架构来处理这种复杂度
  2. 不同场景对于下发字段的校验要求不同 :需要基于标注的Validator模块来处理字段粒度判断
  3. 运营和产品的需求经常变化 :对于tab排序、筛选条件,接口设计要考虑扩展性,提供运营能力

解决方案

构建一套pipeline,每个处理节点关注一个问题解决

  1. Datasource :数据来源(算法推荐、数据库、缓存、运营配置、置顶数据)。方法名:fromXXX
  2. Transfer :类型转换。方法名:toXXX
  3. Filter :数据过滤(黑白名单,字段约束)。方法名:byXXX
  4. Sorter :数据排序。方法名:topXXX、shuffleXXX
  5. Completer :补数据。方法名:addXXX
  6. Validator :有效性验证,过滤不符合要求的数据,比如商品某个字段缺失。方法名:checkXXX
  7. Factory :基于基本元素,数据拼接生产。方法名:createXXX
  8. Iterator :保存各类遍历过程

是不是看起来有点类似Java8中stream的API,但这套pipeline具体还是偏内容下发业务,比Java原生API要更丰富,以淘宝的AR淘业务为例,pipeline如下:

代码实现效果

下面代码实现一套基于运营配置数据源的pipeline

1.首先,自定义Pipeline,没有使用Lambada,对java7及以下也适用

public class PipeLine<D, C> {
private List<PipeLineFunction<D, C>> functionList = new ArrayList<>();
public PipeLine<D, C> add(PipeLineFunction<D, C> pipeLineFunction) {
functionList.add(pipeLineFunction);
return this;
}
public D execute(D data, C context) throws Exception {
for (PipeLineFunction function : functionList) {
data = (D) function.execute(data, context);
}
return data;
}
}

2.其次管线,对于处理次序和节点进行指定:包括从配置读取数据--->通过arType过滤--->随机打乱数据--->置顶主题类数据--->翻页--->增加sku和item信息--->增加AR模型信息--->完整性校验

public void initSkuResultHotRecommendPipeLine() {
PipeLine<SkuResultVO, SkuQuery> skuResultHotRecommendPipeLine = new PipeLine();
skuResultHotRecommendPipeLine
.add((data, context) -> skuResultDataSource.fromConfig(context))
.add((data, context) -> skuResultSorter.shuffle(data))
.add((data, context) -> skuResultSorter.topTheme(data, context))
.add((data, context) -> skuResultSorter.page(data, context))
.add((data, context) -> skuResultCompleter.addSkuInfo(data))
.add((data, context) -> skuResultCompleter.addAREffect(data, context))
.add((data, context) -> skuResultValidator.check(data));
}

3.最后,搭建pipeline,接口收到请求后,通过管线处理,下发对应内容

public ResultVO<SkuResultVO> getSkuList(SkuQuery skuQuery) {
try {
SkuResultVO skuResultVO = skuResultHotRecommendPipeLine
.execute(new SkuResultVO(), skuQuery);
} catch (Exception e) {
log.error("", e.fillInStackTrace());
return ResultVO.failOf(e.getMessage());
}
return ResultVO.failOf(CameraArCause.No_Valid_Ar_Type
.toMessage(skuQuery.toString()));
}

4.我们再讨论一下对于有固定的遍历逻辑的情况,遍历方式也可以抽象成一个iterator,在不同的filter作为参数传入下,完成遍历功能,下图就是对商品的一种遍历,这个特性用到FunctionalInterface标注,需要java8及以上

(1) 定义遍历器

@FunctionalInterface
public interface FilterFunction<T> {
boolean execute(T t) throws Exception;
}
@FunctionalInterface
public interface IterateFunction<T> {
T execute(T t, FilterFunction filterFunction);
}

private IterateFunction<SkuResultVO> skuVOFilterIterator = (skuResultVO, filter) -> {
List<SkuFeedUnitVO> skuFeedUnitVOList = skuResultVO.getSkuFeedUnitVOList()
.stream().filter(skuFeedUnitVO -> {
List<SkuVO> filterSkuVOList = skuFeedUnitVO.getSkuVOList()
.stream().filter(skuVO -> {
try {
return filter.execute(skuVO);
} catch (Exception e) {
log.warn("", e);
return false;
}
}).collect(toList());
if (filterSkuVOList.size() == 0) {
return false;
}
skuFeedUnitVO.setSkuVOList(filterSkuVOList);
return true;
}).collect(toList());
if (skuFeedUnitVOList.size() == 0) {
log.warn(CameraArCause.No_Valid_Sku_Feed_Unit_List
.toMessage(skuResultVO.toString()));
}
skuResultVO.setSkuFeedUnitVOList(skuFeedUnitVOList);
return skuResultVO;
};

(2) 在Filter模块中使用遍历器,如果把skuResultVO换成一个返回SkuResultVO的Supplier,是不是有点柯里化的味道啦?

public SkuResultVO byArType(SkuResultVO skuResultVO) {
return skuResultIterator.getSkuVOFilterIterator()
.execute(skuResultVO, (FilterFunction<SkuVO>) skuVO ->
!CameraArSwitch.Black_List_Config.getArType()
.contains(skuVO.getArType()));
}

整体架构

  1. API & View层:为各类客户端、服务端提供接口
  2. Controller层:不同来源的调用适配,权限控制
  3. Manager层:每个接口pipeline的各个节点实现、二方和三方包封装
  4. Middleware层:集团常见中间件
  5. Model层:按照阿里Java规范的各个层级POJO
  6. Common层:自研公共组件,主要是切面类、native命令执行类等

Tips

淘系商品信息补全

对于补齐数据源的选择,要详细了解上游各个补齐数据源的业务定位和业务边界,选择合适的补齐数据源。比如淘系商品补全数据源常见服务有以下几个,要根据业务自身需求

数据补齐二方服务

优势

劣势

商品中心(IC)

最底层的数据源,有item和sku维度的信息

维度不够多,比如一些商品的运营信息

阿拉丁

维度比较多,比如商品白底图

只有item维度信息,但是有些数据源不稳定,比如品牌信息有些商品会缺失

搜索的Summary

跟主搜的信息保持一致,信息比较实时,比如优惠、销量信息

只有item维度信息,维度不够多

筛选能力

内容下发除了做好个性化,如果是一个公域产品,对内容的筛选能力决定用户是否能主动找到自己想要的商品,我们需要设计一个易扩展的筛选器接口,常见的垂直频道类产品,一级和二级tab页就满足业务诉求,但对应比较大的公域,比如搜索,需要支持多维度筛选+多筛选能力,都需要实现两个接口,这时, 我们需要设计一个通用的接口格式,做好两件事。

  1. 下发筛选器
  2. 上传用户选择的筛选项
  • 一级和二级tab页

只需要下发一级和二级的tab树状接口即可,用户通过先后选择一级和二级tab来过滤内容,这里不作过多的讨论。

  • 多维度筛选器

需要下发多维度筛选器,如果有一级Tab,多维度筛选器放在每个Tab内部,例子如下:

1.筛选器下发接口,格式如下,其中Name结尾的字段为前端展示,Id结尾的字段作为筛选上传的接口字段

{
"tabList": [
{
"tabName": "tab1",
"tabId": "xxx",
"filterList": [
{
"filterName": "xxx",
"filterId": "xxx",
"filterItemList": [
{
"filterItemName": "fitler1",
"filterItemId": "xxx"
},
{
"filterItemName": "fitler2",
"filterItemId": "xxx"
}
]
}
]
},
{
"tabName": "tab2",
"tabId": "xxx",
"filterList": [
{
"filterName": "xxx",
"filterId": "xxx",
"filterItemList": [
{
"filterItemName": "fitler1",
"filterItemId": "xxx"
},
{
"filterItemName": "fitler2",
"filterItemId": "xxx"
}
]
}
]
}
]
}

2.上传用户选择的筛选项,接口格式如下,tabId可以作为单独的字段传,filterList是另外一个字段

{
"tabId": "xxx",
"filterList": [
{
"filterId": "xxx",
"filterItemList": [
{
"filterItemId": "xxx"
},
{
"filterItemId": "xxx"
}
]
},
{
"filterId": "xxx",
"filterItemList": [
{
"filterItemId": "xxx"
},
{
"filterItemId": "xxx"
}
]
}
]
}

总结和展望

总结

本文通过大淘宝业务的例子,梳理出一套 内容服务下发内容时面临的问题和挑战、设计一套内容处理链路,用模块化的设计来控制系统的复杂度,并且对接口上线后,如何灵活运维进行了讨论,重点研究了保证易扩展、易运维的思路,希望对各位有所启发。

展望

内容下发服务已经有些团队推出了前后端一体的方案,客户端不用请求应用服务来拿商品数据,通过统一的平台接口,把客户端布局和内容填充一起请求来返回,这么做的好处是效率比较高,迭代起来快,带来的不便是客户端和平台耦合比较紧,灵活性变差,比如客户端有一块内容源不走平台,就会比较麻烦

责任编辑:张燕妮 来源: 淘系技术
相关推荐

2015-07-28 14:35:40

2011-06-29 17:53:24

维易IT运维

2020-02-14 08:05:05

数据网格高扩展易维护

2011-06-28 16:13:11

维易IT运维ITSM

2016-06-20 13:15:59

2017-03-29 14:40:34

互联网

2016-07-26 11:33:57

易维帮助台运维服务

2016-05-25 11:51:42

华西医院易维帮助台

2021-05-20 13:22:31

架构运维技术

2023-09-21 11:20:46

2022-11-08 08:35:53

架构微服务移动

2016-08-02 11:25:46

易维帮助台

2017-04-25 16:12:49

2017-03-27 17:49:40

戴尔服务器

2011-01-10 14:24:35

CIO快乐运维

2021-07-16 11:37:40

数字化

2021-11-16 13:19:04

数字化

2016-09-13 10:56:03

运维性能密度

2019-07-08 17:32:27

惠普

2015-08-18 10:00:53

点赞
收藏

51CTO技术栈公众号