技术文档丨查询接口的演进过程

赵立贺

悠易互通丨技术专家

技术产品中心

数据组

本文是赵立贺所作的《查询接口的演进过程》，我们一起来看看吧：

对于业务系统而言，存在着各种显示形式，各种粒度的数据查看界面，而每一个数据查看界面都是由前端和后端的小伙伴配合来完成的，本文从后端开发的角度来分享接口的演进过程。

随着越来越多的广告主使用业务系统进行广告投放，那么系统也就需要满足不同广告主的数据需求，这对于开发人员而言苦不堪言。因为每一个数据需求都需要开发的小伙伴进行相应的开发来完成，那么有没有一种少开发或不开发只调整配置的方式来完成呢？

最开始的时候，产品提出一个数据查看需求，那么开发的小伙伴就要去了解数据查看的粒度，并且跟ETL的小伙伴沟通相应粒度的数据存储在什么地方，以及应该怎么查询（也就是一个数据需求，那么后台小伙伴就要开发一个接口），这样开发的结果就是ETL的一个结果集会有多个对外的数据查看接口，ETL工程师对结果集的任何一次升级，都需要后台数据查看开发的小伙伴修改多个对外的查看接口。示意图如下：

经过一段时间的开发和维护，会发现大部分接口的结构是类似的，有很大的优化的空间，从而有了第一次的重构。经过接口梳理和抽象，将接口按照主题域来进行归类，针对每一个主题域进行统一的数据预处理及查询加工处理来得到符合该主题域的所有结果集。这样做的好处是对于每一个主题域的处理逻辑是统一的，解决一个问题也就解决了该主题域的一类问题，比如ETL工程师对结果集的一次升级，只需要调整受影响的几个主题域即可，而且业务系统增加新的数据查看列表，开发的小伙伴先判断下该数据需要查询哪个数据主题域，对于该主题域，是否可以通过修改配置就能支持该数据查看列表，否则就扩展该主题的数据查询加工处理；缺点是会存在部分无效或冗余的字段，增加了网络传输的开销。示意图如下：

经过一段时间的使用，同时为了保证查询的性能，减少无效字段和冗余字段的传输，发现主题域越来越多，而且主题域的粒度也是越来越细（假设在极端的情况下，抽取的主题和接口的数量是一致的）。基于这样的现状，同时为了减少维护的成本，就有了第二次的重构，将前端的多个接口统一为一个，让前端来控制查询的内容，后端对于前端而言就类似于一张透明的大宽表，所有的业务需求都通过这张透明的大宽表来完成。示意图如下：

其中输入参数和返回结果的示例代码如下：

/** * 实体查询的输⼊入参数 */public class EntityQuery implements IQuery, Serializable {    // 查询字段    private List<String> queryFields;    // 过滤条件    private List<IFilter> filters;    // 开始时间    private String since;    // 结束时间    private String until;    // 排序信息列列表    private List<OrderItem> orderBys;    // 所属业务    private String owner;    // 分⻚页信息     private PageInfo pageInfo;    // 其他信息    private Object options;}
/** * 返回结果 */public class ResultData implements Serializable {    // 查询的字段顺序列列表    private List<String> headers;    // 查询的结果集    private List<Map<String, Object>> data;    // 查询的sql表达式        private String sqlScript;    // 总条⽬目数    private int totalSize;}

通过上述的输入对象，能够明确的表示界面需要的字段有哪些，以及对应的查询条件、排序和分页信息等，而且返回信息也相对统一了。这样做的好处是开发的小伙伴能够有一套完整的数据查看处理流程，而且能够有更多的精力来优化这套处理流程，使其有更强的稳定性和更高的扩展性。但是，这种一个接口承担所有的数据查看的形式也是存在缺点的，比如对于频次的查询、人群包的流量分析，用户画像分析等模块的数据查看都会有其特定的信息需要传递到后端才能进行相应数据的处理等。所以现阶段的接口统一也是在现有业务情况下来进行的。后续随着业务的不断变化，接口也会跟着不断的演进。 

总之，随着数据查看接口的不断演进，接口越来越少、而且越来越灵活的宗旨不变。但是，接口的演进是在公司的特定业务场景下进行的，并没有一种万能的方法，能够适应于所有的业务。期待着我们的接口更少更灵活。