有赞订单搜索AKF架构演进之路

1、前情提要

时节如流，两年前的今天写了有赞订单管理的三生三世与十面埋伏，转眼两年过去了，这套架构发展的如何，遇到了什么新的挑战和收获，今天主要来一块儿整理回顾下有赞订单搜索AKF架构演进之路。

1.1 分久必合

以前将散落在 DB 多个分片中的数据在 ES 作了一次聚合，带来了巨大的好处，同步任务少，维护成本低。尤为是订单迁移这一块，以前因为是分片设计，因此当订单触发迁移时候，须要将数据插入新分片，确认无误后还须要删除老分片数据，流程繁琐易错，统一收拢后对于 ES 来讲，各个端订单迁移，都只是一次更新操做，无比简单。补充介绍下订单迁移：

• 买家订单迁移 针对新用户转变为关注用户，从系统 mock 的 buyerId 到真正分配的 buyerId 订单的迁移。
• 卖家订单迁移 针对店铺模型升级，好比从微商城到零售连锁，原门店独立须要迁移订单。

2、新的挑战

然而随着业务的不断发展，聚合后的索引也开始暴露各类问题。

• 数据量增加比预期要快不少，亿级别的索引，慢查也开始出现，像一个庞然大物蠢蠢欲动。
• 为了知足商家的一些个性搜索需求，不少搜索需求都属于极少数会查询到的，可是都会被加到同一个主索引中，使得主索引字段不断增多。

3、应对

3.1 合久必分

为了解决以上挑战，踏上了可扩展性架构拆分之路。简单介绍下有赞订单搜索的几个维度：

• B 端商家单店搜索（商家管理单店订单）
• B 端商家总店跨分店搜索（连锁总店管理分店订单）
• C 端买家跨店铺搜索（买家管理跨店全部订单）

因为既要 ToB 又要 ToC ，而 B 端零售连锁商家的引入，增长了很多复杂度，由于有总店 MU 来管理多个 BU 单元，须要跨多个店铺查询。不管怎么分片，单一维度都必然存在跨分片搜索的场景。计划优先按数据冷热分离来拆分，而如何区分和定义这个冷热数据？最近一天，一月，一段时间的搜索，都比较范，缺少数据支撑。

念念不忘，必有回响。

3.1.1 热状态索引

因而观察了下咱们的监控，发现了奇妙的规律。全部搜索场景中，常见的按支付方式，物流类型，商品名称，订单类型等搜索占比不多，而按订单状态搜索占比最多，约 53% ，也就是一半多的搜索流量所有来自于订单状态检索。

而细化了下这 53% 的订单状态搜索中，其中 3% 左右搜索终态订单(已完成，已关闭),其中 50% 全部流量所有都是搜热状态订单(待付款，待发货，待成团，待接单，已发货），-_- 忽略比较乱的枚举，历史多个版本统计合一。

不由让人兴奋，为何？由于不管订单量如何激增，处于热状态的订单数不会持续暴增，由于全部订单都会陆续流转到终态，好比超时 30 分钟未付款，订单从待支付变成已关闭状态，好比订单发货 7 天后，从已发货状态变成已完成。统计了下，热状态订单总量在千万级别，且一直比较平稳的进行流转。

也就是说咱们用这个千万级小索引，就承接了整个订单搜索一半左右的流量。不管是统计，总店查询，各类跨分片维度查询，均可以支持。由于它是一个热状态订单数据全集，包含全部分片场景，无比兴奋。目前该索引已在线上平稳运行近一年。

3.1.2 时间分片索引

那么对于那些终态订单，数据量随着订单状态流转会变得愈来愈大，如何扩展，时间分片是个不错的选择，有赞订单搜索早期最先作的切分就是按下单时间分片，以前业务数据量小，每半年一个，到后来发展改为了每 3 个月一个，到如今即便每个月一个索引都显得有些庞大。具体仍是要结合搜索场景，理论上终态订单检索的量比较小，也能够换个思惟从产品层面有个引导，好比默认只展现最近半年订单，也是一种思路。

3.2 扩展依据

3.2.1 AKF 扩展立方体

在《架构即将来》与《架构真经》中都反复提到这个立方体，结合咱们的实际状况，确实受益不浅，给了咱们指引的方法论。

X 轴 : 关注水平的数据和服务克隆，好比主备集群，数据彻底同样复制。克隆多个系统(加机器)负载均衡分配请求。

• 优势：成本最低，实施简单
• 缺点：当个产品过大时，服务响应变慢
• 场景：发展初期，业务复杂度低，须要增长系统容量

Y 轴 : 关注应用中职责的划分，好比数据业务维度拆分。好比交易库，商品库，会员库拆分。

• 优势：故障隔离，提升响应时间，更聚焦
• 缺点：成本相对较高
• 场景：业务复杂，数据量大，代码耦合度高，团队规模大

Z 轴 : 关注服务和数据的优先级划分，数据用户维度拆分。好比常见的按用户维度买卖家切分数据分片。

• 优势：下降故障风险，影响范围可控，能够带来更大的扩展性
• 缺点：成本最高
• 场景：用户指数级快速增加

上面介绍的热状态订单拆分其实就是朝 Y 轴方向扩展，固然 AKF 可扩展立方体的精髓就在于不要一直只在一个轴方向上扩展，要根据不一样的业务场景，数据规模，作到有针对性的扩展，理论上 XYZ 轴能够作到某种程度的无限扩展。目前有赞订单搜索的整体索引架构以下，涵盖 3 个轴方向。

3.3 现状

4、收获

上面简单介绍了下有赞订单搜索 AKF 扩展之路，下面再简单聊下过程当中的几个意外收获，受益良多，能够给相似业务同窗一个能够尝试的参考。

4.1 可扩展性索引字段设计

以前迁移到 ES 里就是看中 ES 的多索引检索能力，然而多变的产品需求经过不断加字段的模式，也会使索引变得愈来愈大，很差维护，有没有一种可扩展性的方式，来以不变或者以小变应对需求的万变呢。答案是确定的，list< String > 字段设计，好比目前开放了搜索扩展点给有赞云，商家能够自定义的创建本身的检索字段，K 和 V 都有商家本身把控，如何作到代码可配置化，业务代码无感知呢，按照咱们的约定须要检索的字段进入 list< k_v > 格式，便可作到。关于细节订单管理系列博文之可配置化订单搜索博文中会详细进一步介绍。

4.2 轻量级统计

统计一直是各大公司比较重要的一块，有赞也是，几乎有订单的地方都会看到各类订单数统计，早期统计场景比较简单，好比统计待发货，已发货，退款订单等均可以经过一个 sql 或者一个脚本任务就能够统计出来，可是随着有赞业务发展的愈来愈快，好比统计一个加入担保交易+已经完成7天内+发生退款的订单数，普通的统计模式经过更改统计 sql ,再刷个离线数据也是能作到的，可是周期每每较长，并且不够灵活，一旦有部分统计失败报错的，排查问题很困难，只能再全量从新统计。而这里咱们采用了另外一种视角，用搜索来作统计，依赖于ES搜索默认返回的 total 做为统计值，能够无缝利用现有数据作任意维度任意组合的任意统计，随时提需求，即用即拿，很是轻量。关于细节也会在订单管理系列博文之配置化订单统计博文中会作详细进一步介绍。

5、展望

回望有赞订单管理 4 年的心路历程，收获良多，配置化订单搜索，配置化订单统计，配置化订单同步系列博文也会陆续发出(配置化订单导出博文已发)，目前已从订单管理顺利毕业，后续主要负责有赞搜索中台业务线，诚邀有成长型思惟，大数据思惟和业务敏感度的同窗加入，共建有赞搜索中台大业，简历直邮 wangye@youzan.com