背景
极光目前业务线较多，各个业务线都有数据服务 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 注册到数据服务平台
在一期产品性能根底上，联合业务需要，欠缺平台性能