关于api设计:api平台原理

5次阅读

共计 996 个字符,预计需要花费 3 分钟才能阅读完成。

数据仓库侧作为泛滥数据的汇合,除了提供报表和数据分析以外,还会以各种 api 的形式向外提供数据服务,供后端各种零碎应用。api 平台的实现形式多种多样,开源的 api 平台也有多种版本,简略梳理一下接口平台的性能和实现形式。

数据生产

各种接口的数据都不是凭空来的,api 平台的数据源能够简略的分为离线数据和实时数据,离线数据的存储有 mysql,postgresql,hive,presto 等,这部分的数据大都是有调度零碎通过定时工作写进去。实时的数据存储形式有 redis,hbase,ES 等,实时的数据大多数是由 spark,flink 或者其余生产实时音讯队列的零碎写入。尽管从存储上能够简略的依照上述的办法去划分,然而在应用上各种存储的介质提供的数据能力上却没有那么显著的界线,例如对一些实时性能要求没那么高的外部零碎,能够通过 presto 提供一些近实时的接口。

接口实现

无论各种数据源的解决其实都一个逻辑,前端抉择数据源,写入须要的 sql,sql 中能够抉择对应表字段的子集,sql 的限度局部能够用变量去标识,变量通过前端传入,后端的 adpter 拿到 sql 当前去将变量替换成要替换的值即可。对不同的数据源初始化不同的 client 去查问数据,将查问到的后果通过分页,纯文本等形式返回。存储在 mysql,postgresql 中的数据个别是一些离线数据,这部分数据应用方会每天定时的拉取,数据到应用方后做缓存解决,接着再去应用,同时对小数据集会提供实时查问,在须要的字段上加上索引即可。hive 中的数据个别有两种解决逻辑,第一是将 hive 数据同步到 mysql 和 postgresql 中,通过 mysql 和 postgresql 向外提供数据,第二是通过 presto 查问引擎去查问数据,presto 的这种形式适宜低频的离线批次查问,高频查问会受到 presto 集群的影响,在查问顶峰时段接口会超时。对上述的一部分 key value 类型的接口数据,提供了 redis 查问的性能,接口零碎会有定时工作将数据刷进 redis 中,查问的时候间接走 redis 查问。

数据应用

提供 http 和 dubbo 的形式供调用方拉取数据。离线局部的数据数据产出当前,定时工作会发消息进来,应用方可通过承受到的零碎来拉取数据。

权限治理

对窃密级别高的接口做了权限的限度,只有特定的内网 ip 能够拜访。同时整个零碎还有一层白名单和黑名单的限度,治理所有接口的权限。

正文完
 0