关于数据库:极光笔记数据服务平台一期建设

背景
极光目前业务线较多，各个业务线都有数据服务 API 的开发需要，过来公司没有对立的数据服务总线，导致数据源反复开发、数据利用 API 反复开发景象较多，资源节约重大，数据服务平台次要旨在：
提供对立的对内对外的数据 API 接口，标准数据服务 API 的开发与治理
联合数据地图，买通数据利用和数据工程，实现数据价值和链路血统的补充
一、极光数据服务平台介绍
极光数据服务平台提供将数据表生成 API 的能力，反对可视化向导模式或脚本模式疾速开发 API 接口，反对关系型数据库和 NoSQL 数据库，可供外部和内部零碎通过调用 API 接口获取数据，对凋谢的 API 进行对立治理和公布。

【外围性能】：
【可视化 API 开发】提供可视化开发 API 性能，即可疾速配置一个 API，进步交付效率
【可视化 API 调试】提供最根本的可视化的 API 调试性能，缩小测试老本
【对立的 API 治理】提供对立的各业务线对内对外的 API 治理性能
【API 监控告警】提供接口调用统计可视化报表、监控、告警等性能
【API 市场】平台配置的 API 对立公布到 API 市场，各业务的数据开发 / 产品经理们可查看 API 市场公布的 API 是否可为本身业务发明价值，可依据业务须要申请应用

【应用对象】：
数据开发：配置数据源、配置 API 接口，用于产品接口 / 业务接口疾速开发
数据服务平台开发：治理业务接口、治理数据源、平台稳定性保障
产品经营：业务接口监控、产品接口应用状况数据分析

1.1 应用流程
API 发布者流程：

图 1 -1-1
API 使用者流程：

图 1 -1-2
1.2 数据源治理
数据服务平台提供数据源治理性能，数据开发工程将开发好的数据表注销到此平台，业务部门只能治理各自的数据源。

图 1 -2-1
一期数据源只反对 pika 和 redis 组件，后续会反对更多存储组件（hbase/mysql/es 等）
1.3 API 开发
有了数据源后，业务开发就能够基于该数据源配置 API 接口入参和出参等信息，疾速生成和公布 API，进步业务交付效率。

图 1 -3-1
通过数据服务开发的 API，能标准 API 接口定义，对立治理各业务线的 API 接口。
1.4 API 调试
配置 API 实现后，就进入到 API 调式阶段，在这里业务开发能够输出申请参数的值进行调用，查看申请详情和返回内容，验证 API 接口入参加出参是否合乎预期。

图 1 -4-1
1.5 API 公布
API 调试通过后，就能够公布 API，这里须要走工单审批，审批通过后，会主动公布的 API 网关。
1.6 API 网关
作为数据服务 API 网关，必须具备身份认证、权限验证、限频限流等性能。
身份认证：为了解决接口平安问题，会为每个产品线调配一对 devKey 和 devSecret，API 接口在调用时，须要带上 devKey 和签名信息能力拜访。
权限验证：对于每个已公布的 API，都要通过 API 负责人受权能力拜访。
限频限流：API 负责人在公布 API 时，能够设置接口的 QPS 和 QPD，超过设定的阈值，就会限度接口的拜访。
1.7 API 市场
API 公布胜利后，会上架到 API 市场，业务开发能够在 API 市场搜寻和查看曾经上架的 API 接口的入参、出参、错误码、发布者等信息，还能申请某些 API 的权限，审批通过后就能够间接调用该 API 接口获取数据。

图 1 -7-1

图 1 -7-2
1.8 服务概览
平台具备服务概览性能，蕴含已公布的 API 数量、未公布 API 数量、调用 API 胜利次数、调用 API 失败次数、错误码散布等统计性能，以及查看编辑且未公布（草稿状态）的 API 列表。

图 1 -8-1
二、极光数据服务平台架构设计

2.1 产品架构图

图 2 -1-1
数据服务平台从产品层面，次要分为四层：
1、应用层：业务依据需要能够申请调用某些 API 获取数据。
2、性能层：平台提供从 API 创立 ->API 调试 ->API 公布 ->API 监控等性能。
3、撑持层：撑持平台应用的一些根底性能，包含：用户治理、角色治理、日志治理、工单审批等性能。
4、数据源层：数据存储组件，包含：pika、redis、hbase、mysql、es 等。

2.2 技术架构图

图 2 -2-1
数据服务平台次要分为两局部：
【治理端】：
治理端次要提供给业务开发应用，通过治理端，业务开发可能疾速实现配置数据源 -> 开发 API -> 公布 API 等操作。
【服务端】：
服务端提供对内或对外 API 接口拜访，这里又分为三层：
网关层：API 调用入口，次要负责认证、权限、API 路由、限频、限流等工作。
接口层：提供 API 接口查问服务，依据 API 信息组装参数和返回查问后果。
数据拜访层：该层提供拜访业务数据存储组件。
2.3 整体交互图

图 2 -3-1
API 发布者通过治理端生成并公布 API 后，API 接口元数据信息（数据源、入参、出参、QPS、QPD 等信息）会被寄存到 redis，供认证核心、网关、可配置服务应用。
2.4 可配置化接口服务
在数据服务平台一期建设中，提供基于 pika 和 redis 可配置化（NoSQL API）接口能力，其数据源是通过 jcache 代理层连贯 pika 和 redis，业务数据 以 KV 形式存储，可依照简略的 key-value 对外提供服务，把 key 作为入参，value 作为出参来形象对外提供的 API 接口。
可配置化接口服务对外提供一个形象接口，在本形象接口中依照接口 id 获取接口的元数据信息（数据源、入参、出参等），再依照接口元数据信息创立数据源连贯，生成存储 key，获取 value 值，最初封装出参返回。

图 2 -4-1
用户身份认证、api 调用权限认证、限流等前置逻辑都通过后，进行 api 转发。在数据服务平台创立公布的任意门路 api（Jcache 可配置接口），通过网关都会转发到可配置接口服务的形象 api 中。

三、后续布局
尽管一期性能曾经上线，但只能满足局部业务需要，还有很多性能须要欠缺和开发，以下是二期性能：
数据源反对更多存储组件，如：hbase、mysql、es、hive 等
减少配置 API 的前置解决和后置解决能力
实现 API 服务编排性能，反对服务串行、并行、分支等能力
减少 API 接口的弹性伸缩和资源隔离性能
减少注册 API 性能，业务能够将现有的 API 注册到数据服务平台
在一期产品性能根底上，联合业务需要，欠缺平台性能