干货 | 跨多业务线挑战下，携程订单索引服务的1.0到2.0

作者简介

唐巍，携程用户平台部订单服务组资深后端开发，在互联网尤其是移动互联网方面有丰富的经验，目前主要负责OrderIndex的维护和架构升级工作。

经过团队几个月的努力，我们最近终于完成了OI（订单索引服务）从1.0到2.0升级的里程碑，上线了新的数据同步平台和对应的数据查询服务。在这里我们总结了其中的经验和心得，希望能给大家，尤其是有做跨多业务线或者复杂系统需要升级改造的同学们，一点启发或者是帮助。

 

一、什么是OI？

携程的众多业务线订单信息分布在各业务线不同的订单系统之中，有各自独立的查询服务，而公司内部又存在着大量跨业务线查询统一订单信息的诉求，为解决这样的痛点，OI 项目应运而生。

OI的全称是OrderIndex（订单索引服务），是“携程APP-我的携程-订单列表”的订单信息数据源，是一个以“聚合不同数据来源的订单信息，并提供统一分类查询功能”为核心业务的系统。

 

二、OI 1.0

OI1.0是目前支撑OI业务的主力系统，上线于2013年。查询服务基于公司的SOA服务治理平台开发。订单同步和辅助Job基于公司的作业调度平台（JosWS）开发。

      

其中核心机制如下图。

OI 1.0的订单同步机制

                           

数据同步以及下发流程如下：

1）对应业务线订单的订单同步Job，从业务线的订单数据库通过扫描相关表的时间戳，来感知订单变化（获取变化的订单号orderid）；

2）通过业务线提供的拉取订单详情的SQL从业务线订单数据库读取订单详情相关数据；

3）根据业务线提供的业务，将从业务线数据库拉取的订单详情相关数据转化为实际的订单数据，并规整后保存到OI的数据库中；

4）在OI的接口调用方通过SOA服务来查询订单信息的时候，将我们同步过来的订单信息透传下发；

 

基于这样的架构和机制，截止目前，OI 1.0聚合了超过50+数据源，160+业务线的订单数据，总量超过5亿条。并通过实时数据查询服务以及订单变更消息通知以毫秒级的订单同步延迟，支撑了下游超过200个系统共计日均4亿+次的订单查询需求，并且，这些数字还在不断的变大。可以预见，OI 在之后还会承担更重要的责任。

虽然目前OI 1.0看起来仍然运行良好，但是随着 OI 业务的不断扩展，我们也发现了一些问题。

 

1）业务线提供的数据源只支持直连DB，并且需要提供的接入信息非常复杂

• 需要Db提供生产核心订单库的访问权限，有安全风险

• 需提供所有相关表的表结构以及字段说明，并提供跟实际订单信息之间的关联转化逻辑

• 绝大部分情况下，订单的信息变更必须反映到订单主表的时间戳变更上，否则无法感知到订单变化

 

2）业务线提供的订单数据源结构各不相同，还需结合配套业务使用

• 订单接入和修改需要我