前言
有人说过：“在以业务及运营驱动的互联网公司，唯一不变的就是业务需求的不断变化”。作为在一个业务快速发展的互联网公司的技术团队，尤其是公司的业务模式开始逐渐地稳定时，应该越来越注重“技术沉淀” --将各业务系统中的某些“通用能力”平台化/中台化（如，货&车源信息的检索平台、数据中台（产出诸如供需模型、‘相似度计算’模型实时计算的数据，供排序、推荐系统使用）、搜索与推荐策略平台、交易引擎等等, ），且随着系统的不断深入，你会发现，这些系统有着诸多的‘架构’相似之处。也唯有此，作为“兵工厂”的技术团队，才能在业务变化需求中快速组装、提供源源不断的“武器保障”。
01. 一个‘简单’的数据产品架构，是数据中台、货&车源搜索引擎的微观版
这个数据产品的需求说起来比较简单也很常见（相信每个公司都有一个类似的BI报表系统给各个‘老大’、运营、产品看App端的用户指标变化、App界面中各‘元素’的流量变化），本质上是Web端需要基于Echart 库将App产品端的各个请求入口的流量数据，在服务端进行统计计算输出各个业务指标（如，PV，UV，留存，转化率等）后，以各种图形报表展现。Echart Sample 如图（真实产品的后端界面由于业务敏感，暂不贴出来了）：
其中，需求的复杂点（“相对来看”）在于，
- 业务数据指标随着产品的需求变化会越来越多（即，增加新的业务指标，比如新增的数据主题，车货匹配类、交易类、评论等等，都会有各自的指标类别及计算）
- 前端展示的Echart 图形类别也会不断变化（可能为不同的数据指标新增折线图、饼图、柱状图，亦或在现有图形上增加新的维度）
因此，在后端的系统设计时，有如下架构决策与实现：
- 服务端的数据查询接口（当各个报表图形做数据查询调用时）保持不变（即一个接口承接所有不同种类的数据查询，减轻前端开发复杂度）
- 服务端查询逻辑的编码实现，采用‘事务脚本’设计模式，将查询过程抽象成 -- ‘入参查询条件’的解析与转换、‘SQL查询模板的映射与变量替换’、‘SQL’执行、‘抽取查询结果集’，‘响应数据补齐’、‘结果集排序’这几个步骤.
由此可以看出，从系统架构角度，无论是这个简单的BI报表系统，还是承接线上各业务应用的‘数据中台’系统（注：这类系统的成功践行者可以参见阿里的数据平台，有本书对此讲的比较好《阿里巴巴大数据实践》）、亦或‘货&车’源信息检索中台，均有有很大的共通之处，如：
- 源数据可以任由业务方变化，服务层维护数据的元模型定义（元模型定义可能不同），而编程实现则基于元模型。举个例子，‘数据中台’里的元模型可以为逻辑表名称、逻辑表可查询字段、索引字段、过滤字段、物理数据源类型、物理库、物理表....; ‘货&车’源信息检索中台的元模型可以定义为‘索引名模板’、'索引时间后缀'、'索引Doc必填字段 - 如type: Cargo / Truck等等’, ‘索引Doc自定义检索字段’ )
- 过滤与排序的DSL可配置，支持过滤条件与排序逻辑脚本化（如Groovy脚本）。报表系统中过滤与排序设置是在DB中存了一份JSON定义，定义了按哪个字段进行过滤补齐以及排序，返回响应数据时，按配置解析执行；同样的思想，也可以放到检索平台，在过滤与排序时，由端来传入DSL，且可以引用和映射到后端填入的Groovy脚本来执行过滤与排序的逻辑
可见，一旦这样来设计实现，服务层的‘代码扩张’将是‘纵向’的，而‘横向扩张’的业务代码将越来越少（侵入性降低，不会再见到服务层代码里面各种业务VO对象了），从而也就能快速的支持业务扩展与变化了。
“技术沉淀”后续系列文章，计划从实际业务中的一些具有代表性的案例说开去。自我期待一下...
