大数据之路—— 数据服务

6.1 架构演进

DWSOA

由需求驱动，一个需求开发几个接口，编写接口文档，开放给业务方调用。

缺点：接口力度粗，灵活度低，扩展性差，复用率低，开发效率低

OpenAPI

数据按照统计粒度聚合，同样维度的数据形成一张逻辑表，能有效收敛接口数量。

SmartDQ

OpenAPI接口变多，且带来大量对象关系映射的维护工作量。这里再抽象一层，用DSL（Domain Specific Language，领域专用语言） 来描述取数需求，采用标准的SQL语法，可以用对象关系对象映射框架，把接口减少到一个，且只需要关心逻辑表的结构（不需要关心地标数据，可以只变更映射关系，对调用法无感）。数据服务接口一定要尽可能抽象，接口数量尽可能收敛。

OneService

在满足简单的查询服务需求，满足个性化的垂直业务场景、实时数据推送、定时任务。

6.2 技术架构@

元数据模型：多种数据源 -> 物理表（具体数据源的一张表，要指明主键）-> 逻辑表（类似于视图，是一张虚拟表，可看作若干主键相同的物理表构成的大宽表）-> 主题

查询数据库：底层支持多种数据源 1. 实时任务写入 2.离线数据同步

服务层：元数据配置，物理表和逻辑表映射

主处理模块流程：

1. DSL解析：对查询DSL进行语法解析，构建查询树
2. 逻辑Query构建：遍历查询树，通过查找元数据模型，转变为逻辑Query
3. 物理Query构建：通过查找物理表和逻辑表映射，变成物理Query
4. Query拆分：如果设计多张物理表且查询条件允许拆分，变为多个SubQuery
5. SQL执行：SubQuery组装成SQL语句，交给DB执行
6. 结果合并：返回结果合并

其他模块： 日志记录，性能稳定优化

6.3 最佳实践@

6.3.1 性能

资源分配

如何合理的进行资源分配，能够提升性能？

1. 剥离计算资源。有些指标要多天数据的集合或者有复杂的逻辑计算，这些计算逻辑在调用接口时处理成本很高，推荐在底层的数据公共层处理
2. 查询资源分配。查询接口分为：GET接口（基本转为KV查询，时间短代价小）和 List接口（响应时间长，返回记录多，序列化和网络传输，代价高）。两个独立线程池（一个的话，快的会被慢的堵住）
3. 执行计划优化。方案一：查询拆分，并发执行。方案二：查询优化，符合条件的List请求变成GET

缓存优化

1. 元数据缓存。接口查询会频繁调用元数据信息（场景一：解析出映射关系，逻辑Query变成物理Query。场景二：SQL安全检查，调用参数是否合法，LIMIT是否超过上限。场景三：字段权限检查）
2. 模型缓存。把解析后的模型缓存在本地，类似于找个公式直接去套用就可以，可以省了DSL->SQL 的解析时间
3. 结果缓存。把复杂、响应时间比较长，变动比较少的数据缓存。

查询能力

1. 合并查询。日期是今天的话，展示的是实时数据；昨天的话是离线数据，需要切换。原因：两者数据存储的数据源不同，且查询方式不同，离线产出时间不定（可能延迟，但精准），实时对成本和性能考虑，用的算法不精准。可以使用离线数据，实时数据作为兜底
2. 推送服务。前端不是一致请求数据，而是监听数据提供者，推送的方式。设计一：对生产者监听做好消息过滤。设计二：重要消息单线程运转。设计三：消息推送基于Socket实现，基于高性能异步事件的网络通信框架Netty。设计四：多线程。设计五：设计优先级保障重要的主题。设计六：缓存

6.3.2 稳定性

发布系统

1. 元数据隔离。三个环境：日常环境、预发环境和线上环境，与之对应三套元数据，每个环境只会访问对应的元数据。要在预发环境测试后上线。
2. 隔离划分。 需要一：资源划分，确定最小隔离单位，隔离的力度控制在逻辑表层面。需要二：资源独占，修改时禁止其他用户改动。需要三：增量更新，同步用户修改的部分

隔离

1. 机房隔离。双机房容灾，保障内部调用优先
2. 分组隔离。调用者的优先级分层，明确服务对象和保障等级。动态调整规则

安全限制

1. 返回最大记录数。强制LIMIT限制
2. 必传字段。逻辑表配置主键
3. 超时时间。超时查询能终止并释放资源

监控

1. 调用日志采集。基础信息（调用时间、接口名），调用者信息（名称、IP地址），调用信息（调用指标，筛选条件），性能指标（响应时间、是否走缓存），错误信息（出错原因、类型）
2. 调用监控。性能趋势图（总体QPS趋势图、响应时长区间分布），零调用统计，慢SQL查找，错误排查

限流和降级

都是为了不再消耗系统资源

1. 限流。应用内的QPS保护，超出阈值后续的请求立即失败返回，不再继续处理。
2. 降级。方法一：限流措施，QPS为0对应所有访问全部立即失败。方法二：修改元数据，存在为你的资源置为失效状态。