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