基于WSO2 APIM的API全生命周期管理平台架构设计与研发

第４３卷　第４期

２０２０年１２月　　

上　海　船　舶　运　输　科　学　研　究　所　学　报

ＪＯＵＲＮＡＬＯＦＳＨＡＮＧＨＡＩＳＨＩＰＡＮＤＳＨＩＰＰＩＮＧＲＥＳＥＡＲＣＨＩＮＳＴＩＴＵＴＥ

Ｖｏｌ.４３Ｎｏ.４

Ｄｅｃ.２０２０

　　文章编号:１６７４￣５９４９(２０２０)０４￣００３９￣０６

基于ＷＳＯ

２

ＡＰＩＭ的ＡＰＩ全生命周期

管理平台架构设计与研发

李　翔

(中远海运科技股份有限公司ꎬ上海２００１３５)

摘　要:为了能集中高效地对企业中已有的各类应用程序编程接口(ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅꎬＡＰＩ)进行管

理ꎬ基于ＷＳＯ

２

ＡＰＩＭ的开源组件ꎬ设计并搭建一套支持定义、开发、测试、发布和调用管理等ＡＰＩ全生命周期管理的

ＡＰＩ管理平台ꎮ通过引入ＥＬＫ、Ｋａｆｋａ和ｅＣｈａｒｔｓ等第三方组件进行二次集成研发ꎬ实现对ＡＰＩ调用记录的保存和大

屏显示等功能ꎮ经在某大型集团公司实际应用ꎬ验证该平台具有良好的效果ꎮ

关键词:应用程序编程接口管理平台ꎻ全生命周期ꎻ集成研发

中图分类号:ＴＰ３１７.１　　　文献标志码:Ａ

ＡｒｃｈｉｔｅｃｔｕｒｅＤｅｓｉｇｎａｎｄＤｅｖｅｌｏｐｍｅｎｔｏｆＡＰＩＬｉｆｅｃｙｃｌｅ

ＭａｎａｇｅｍｅｎｔＰｌａｔｆｏｒｍＢａｓｅｄｏｎＷＳＯ

２

ＡＰＩＭ

(ＣＯＳＣＯＳＨＩＰＰＩＮＧＴｅｃｈｎｏｌｏｇｙＣｏ.ꎬＬｔｄ.ꎬＳｈａｎｇｈａｉ２００１３５ꎬＣｈｉｎａ)

Ａｂｓｔｒａｃｔ:ＯｎｅｏｆｔｈｅｍａｊｏｒｃｈａｌｌｅｎｇｅｓｆｏｒｅｎｔｅｒｐｒｉｓｅｍａｎａｇｅｒｉｓｈｏｗｔｏｍａｎａｇｅａｗｉｄｅｒａｎｇｅｏｆＡＰＩ(ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒ￣

ｂｕｉｌｔｔｏｓｕｐｐｏｒｔＡＰＩｍａｎａｇｅｍｅｎｔｉｎｔｈｅｆｕｌｌｌｉｆｅｃｙｃｌｅꎬｉｎｃｌｕｄｉｎｇｄｅｆｉｎｉｔｉｏｎꎬｄｅｖｅｌｏｐｍｅｎｔꎬｔｅｓｔｉｎｇꎬｒｅｌｅａｓｅａｎｄｉｎｖｏｋｉｎｇｍａｎａｇｅｍｅｎｔ.

ｓｕｌｔｓ.

ｆａｃｅ)ｅｆｆｉｃｉｅｎｔｌｙ.ＢａｓｅｄｏｎｔｈｅｏｐｅｎｓｏｕｒｃｅＡＰＩＭ(ＡＰＩ￣Ｍａｎａｇｅｒ)ｐｒｏｖｉｄｅｄｂｙＷＳＯ

２

ꎬａｎＡＰＩｍａｎａｇｅｍｅｎｔｐｌａｔｆｏｒｍｉｓｄｅｓｉｇｎｅｄａｎｄ

Ｂｙｉｎｔｒｏｄｕｃｉｎｇｓｏｍｅｔｈｉｒｄ￣ｐａｒｔｙｃｏｍｐｏｎｅｎｔｓｓｕｃｈａｓＥＬＫꎬＫａｆｋａꎬｅＣｈａｒｔｓꎬｔｈｅｆｕｎｃｔｉｏｎｓꎬｌｉｋｅｒｅｃｏｄｉｎｇｔｈｅｒａｗｌｏｇｏｆＡＰＩｃａｌｌｉｎｇａｎｄ

ｔｈｅｐｌａｔｆｏｒｍｄａｓｈｂｏａｒｄａｒｅｄｅｖｅｌｏｐｅｄ.Ｔｈｉｓｐｌａｔｆｏｒｍｈａｓｂｅｅｎｏｆｆｉｃｉａｌｌｙｌａｕｎｃｈｅｄｉｎａｌａｒｇｅｇｒｏｕｐｃｏｍｐａｎｙａｎｄａｃｈｉｅｖｅｄｅｘｃｅｌｌｅｎｔｒｅ￣

Ｋｅｙｗｏｒｄｓ:ＡＰＩｍａｎａｇｅｍｅｎｔｐｌａｔｆｏｒｍꎻｆｕｌｌｌｉｆｅｃｙｃｌｅꎻｓｙｓｔｅｍｉｎｔｅｇｒａｔｉｏｎ

ＬＩＸｉａｎｇ

０　引　言

　　随着微服务架构的不断发展ꎬ各应用服务之间的数据交互越来越多地采用应用程序编程接口(Ａｐｐｌｉｃａ￣

ｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅꎬＡＰＩ)完成ꎮＡＰＩ可完成系统内部各组件和各系统间的数据交换ꎮ以ＡＰＩ的方式

给内部或第三方(即ＡＰＩ消费者)ꎬ能更好地开发和提升其业务价值

[１]

ꎮ目前ꎬ除了企业内部ꎬ越来越多的互

联网企业开始采用ＡＰＩ提供公共服务ꎬ即开放ＡＰＩ(ＯｐｅｎＡＰＩ)ꎮ因此ꎬ企业内部应用系统可很好地利用

ＯｐｅｎＡＰＩ为企业创新应用赋能ꎬ提高系统的处理能力ꎬ扩大其业务范围ꎮ

收稿日期:２０２０￣０８￣１３

作者简介:李　翔(１９８５—)ꎬ男ꎬ湖南益阳人ꎬ工程师ꎬ主要从事系统架构设计、大数据处理方面的工作ꎮ

进行服务调用ꎬ可避免重复开发代码ꎬ从而提高系统集成的效率ꎻ同时ꎬ各应用系统间的数据孤岛可被打破ꎬ

数据资源可得到更加高效的利用ꎮ公司或组织(即ＡＰＩ提供者)通过ＡＰＩ的方式将其数据资产或服务提供

某大型集团公司在信息化系统建设过程中形成了大量内部ＡＰＩꎬ如何便捷高效地对这些接口进行管理ꎬ

李　翔:基于ＷＳＯ

２

ＡＰＩＭ的ＡＰＩ全生命周期管理平台架构设计与研发　　　　　　

４１

是该公司未来提升整体信息化服务能力需考虑的重点问题之一ꎮ对此ꎬ该公司通过对行业内流行的商业和

开源方案进行比较ꎬ综合考虑功能完整性、性能、定制开发能力和运营成本等多方面因素之后ꎬ最终选择由

ＷＳＯ

２

开源的ＡＰＩ￣Ｍａｎａｇｅｒ(ＡＰＩＭ)搭建ＡＰＩ管理平台ꎬ并在试运行期间针对原生平台存在的不足进行完善

和二次研发ꎬ从而实现对ＡＰＩ生成、管理和集成的全面管控ꎬ实现对应用系统、数据库和已存在的业务ＡＰＩ的

统一整合ꎬ提供连接各信息孤岛的数据通路ꎬ进而为数据融合、应用重组和业务重构奠定技术基础ꎮ

１　平台架构设计

Ｓｙｎａｐｓｅ上的ＡＰＩＭ设计ꎮ整个管理平台采用微服务架构ꎬ各组件可实现动态伸缩ꎬ保证平台不存在性能瓶

颈ꎮ平台提供完善的ＡＰＩ管理能力ꎬ具有限流、分项授权、后端负载均衡和故障转移等功能ꎮ整个ＡＰＩ管理

平台由开发者门户、ＡＰＩ发布组件、ＡＰＩ网关、身份信息服务和统计服务等５部分组成ꎬ其架构见图１ꎮ

ＡＰＩ管理平台采用由ＷＳＯ

２

开源的构建于轻量企业服务总线(ＥｎｔｅｒｐｒｉｓｅＳｅｒｖｉｃｅＢｕｓꎬＥＳＢ)组件Ａｐａｃｈｅ

图１　ＡＰＩ管理平台系统架构

１.１　发布工具

平台中ꎬＳＯＡＰ(ＳｉｍｐｌｅＯｂｊｅｃｔＡｃｃｅｓｓＰｒｏｔｏｃｏｌ)风格接口和Ｒｅｓｔｆｕｌ风格接口都能得到良好的支持ꎮ

ＡＰＩ管理平台通过ＡＰＩ发布工具对ＡＰＩ进行生命周期管理ꎬ包括开发、发布、管理和监控ꎮ在ＡＰＩ管理

ＪＳＯＮ的ＡＰＩ描述定义已成为Ｒｅｓｔｆｕｌ风格ＡＰＩ的事实性标准ꎮ在业务系统的接口开发中ꎬ通过Ｓｗａｇｇｅｒ相关

工具包ꎬ可自动生成ＡＰＩ的描述文档ꎮ接口开发人员可通过将描述定义粘贴到发布工具中ꎬ完成对ＡＰＩ的定

义ꎮ

２)对于ＳＯＡＰ风格的接口ꎬ在发布工具中ꎬ可直接通过提供ＷＳＤＬ(ＷｅｂＳｅｒｖｉｃｅｓＤｅｓｃｒｉｐｔｉｏｎＬａｎｇｕａｇｅ)

在完成接口定义之后ꎬ接口发布人员可指定接口后

端服务的测试环境地址和生产环境地址ꎬ便于接口使用

者对接口进行测试和正式调用ꎮ考虑到对分布式大规模

系统的支持ꎬ发布工具中允许对各类地址定义多个后端ꎬ

通过负载均衡提供更大的吞吐量和更强的并发性ꎮ

整个ＡＰＩ的生命周期包含创建、原型、发布、阻止、弃

用和下线等６个阶段ꎮ各阶段的转换关系见图２ꎮ

　　ＡＰＩ生命周期各阶段的含义如下ꎮ

ＡＰＩ用户无法看到对应的ＡＰＩꎮ

１)创建:ＡＰＩ已在平台中定义ꎬ但还没有发布ꎬ此时

图２　ＡＰＩ生命周期管理流程

１)对于Ｒｅｓｔｆｕｌ风格的接口ꎬＡＰＩ管理平台通过集成Ｓｗａｇｇｅｒ工具提供支持ꎮ目前ꎬ基于ＳｗａｇｇｅｒＹＡＭＬ/

接口定义的方式完成对ＡＰＩ的定义ꎮ

４２

上　海　船　舶　运　输　科　学　研　究　所　学　报２０２０年第４期　

可与ＡＰＩ用户进行接口原型设计ꎮ

２)原型:ＡＰＩ以原型方式发布ꎬ已定义相关的接口ꎬ且通过平台的简单模拟实现对接口的反馈ꎬ该阶段

４)弃用:当ＡＰＩ接口后端服务被弃用ꎬ或有新版本的接口上线时ꎬ可弃用老版本的接口ꎮ此时ꎬ新用户

６)阻止:调用被临时禁止ꎬ一般用于接口后端服务需进行临时维护的场景ꎮ

开发者门户为ＡＰＩ的调用者提供ＡＰＩ浏览和测试的支持ꎮ在开发者门户中ꎬＡＰＩ调用者可直接浏览ＡＰＩ

　　３)发布:ＡＰＩ接口正式发布ꎬ服务上线ꎮ此时用户可在开发者门户中看到对应的ＡＰＩꎮ

无法看到该ＡＰＩꎬ但原用户可继续调用ꎮ

　　５)下线:ＡＰＩ接口终止服务ꎬ无法继续调用ꎮ

１.２　开发者门户

接口的定义ꎬ包括描述信息、参数定义和相关接口文档等ꎮ同时ꎬ通过继承Ｓｗａｇｇｅｒ工具ꎬ调用者可直接在页

面中对ＡＰＩ接口进行调用测试ꎮ

在浏览ＡＰＩ的同时ꎬＡＰＩ调用者可对ＡＰＩ接口进行订阅ꎬＡＰＩ接口只有在被订阅之后才能调用ꎮ在订阅

时可选择不同的并发等级ꎬ例如３００次/ｓ、５００次/ｓ等ꎮ不同的订阅等级可对应不同的费用级别ꎬ为后期ＡＰＩ

１.３　ＡＰＩ网关

管理平台实行计费提供支持ꎮ

ＡＰＩ网关可看作一个复杂的反向代理ꎬ在ＡＰＩ管理平台中ꎬ所有的ＡＰＩ调用都由网关完成ꎮＡＰＩ调用者

的调用请求到达网关之后ꎬ由网关完成身份认证、调用并发限制和请求内容检查等操作ꎬ在满足相关要求之

后ꎬ数据被转发至接口的后端服务中ꎬ完成接口调用ꎮ在完成请求转发的同时ꎬ整个调用过程被完整地记录

１.４　身份信息服务

下来ꎬ相关流水信息被发送至统计服务中进行后续分析处理ꎮ

身份信息服务提供对平台整个用户信息体系的管理ꎮＡＰＩ管理平台在调用接口过程中ꎬ其身份验证采

用的是ＯＡｕｔｈ２协议ꎮＴｏｋｅｎ的产生和生命周期管理等均由身份信息服务提供ꎮ同时ꎬ平台支持对单独ＡＰＩ

１.５　统计服务

Ｅｎｄｐｏｉｎｔ进行授权ꎬ相关的权限检查也由身份信息服务完成ꎮ

收到调用流水数据之后ꎬ在内存中进行实时聚合ꎬ并定期写入后台数据库中ꎬ形成各种维度的报表ꎮ

ＡＰＩ的调用流水数据由网关产生之后被发送至统计服务中ꎮ统计服务采用流式计算框架Ｓｉｄｄｈｉꎬ在接

同时ꎬ各ＡＰＩ接口的健康状况由统计服务进行分析ꎮ通过对得到的流水数据进行分析ꎬ统计服务可获得

各ＡＰＩ接口的运行情况ꎬ当出现异常(例如１ｍｉｎ内调用量发生急剧变化)时ꎬ能通过邮件等方式及时通知相

１.６　平台部署

容器平台中ꎮ通过充分利用容器平台高可用、高冗余的管理能力

[２]

ꎬＡＰＩ管理平台能根据负载进行高效弹性

伸缩和自动故障恢复的部署ꎮ同时ꎬ平台拥有一定的“自愈”能力ꎬ当某个微服务因出现故障而失效时ꎬ容器

云会自动对其进行重启ꎬ实现快速恢复ꎮ在重启期间ꎬ流量会定向至其他正常运行的微服务ꎬ保证服务不

中断ꎮ

结合目前业界流行的容器管理技术ꎬ整个ＡＰＩ管理平台以微服务的方式部署在集团内部的Ｋｕｂｅｒｎｅｔｅｓ

关人员ꎮ

２　平台二次集成研发

通过使用ＡＰＩＭ已有组件ꎬ整个ＡＰＩ管理平台能满足企业内部的大部分功能需求ꎬ但随着平台的部署实

施和上线使用ꎬ已有组件逐渐无法满足部分管理需求ꎬ如调用流水记录、终端授权、用户信息透传和大数据监

２.１　ＡＰＩ调用流水记录

控等ꎮ对此ꎬ还需引入其他组件ꎬ并进行二次集成研发ꎬ对平台的功能进行完善和增强ꎮ

在已有的功能组件中ꎬＡＰＩ调用的流水记录仅用于产生统计汇总数据ꎬ原始流水记录并没有保存ꎬ这对

于服务于整个集团的ＡＰＩ管理平台而言是一个较大的功能缺失项ꎮ

从使用的便捷性和功能的完整性的角度来说ꎬ日志管理平台首推ＥＬＫ(ＥｌａｓｔｉｃＳｅａｒｃｈ、Ｌｏｇｓｔａｓｈ、Ｋｉｂａｎａ)ꎮ

通过查阅统计分析服务的相关手册得知ꎬＳｉｄｄｈｉ支持ＲＤＢＭＳ、ＫＡＦＫＡ、ＥＳ和ＨＴＴＰ等方式的数据输出ꎮ对

李　翔:基于ＷＳＯ

２

ＡＰＩＭ的ＡＰＩ全生命周期管理平台架构设计与研发　　　　　　

４３

此ꎬ参考已有的统计分析应用ꎬ直接将ＡＰＩ的流水记录发送给ＥｌａｓｔｉｃＳｅａｒｃｈ集群ꎮ

１)无法对数据的格式进行调整ꎮ由于是直接从统计分析服务中写入ＥＳ集群ꎬ中间没有任何数据处理ꎬ

２)稳定性有一定的欠缺ꎮ由于统计分析服务中对流水记录不作任何缓存ꎬ当因某些外部原因导致连接

参考文献[３]ꎬ引入ＫＡＦＫＡ组件对消息进行暂存ꎬ借以减轻Ｌｏｇｓｔａｓｈ的压力ꎬ避免日志在处理之前丢

失ꎮ新的消息传输机制见图３ꎮ

上线运行一段时间之后ꎬ发现该方案存在以下不足:

无法利用Ｌｏｇｓｔａｓｈ强大的ｆｉｌｔｅｒ插件ꎮ

中断时ꎬ流水记录会丢失ꎮ

　　消息发送到ＫＡＦＫＡ中暂存ꎬ由Ｌｏｇｓｔａｓｈ消费ＫＡＦＫＡ获取流水记录ꎬ经过Ｆｉｌｔｅｒ调整格式之后ꎬ发送至

２.２　单个ＡＰＩＥｎｄｐｏｉｎｔ的授权

ＥＳ集群中进行保存和后续查询分析ꎮ

ＡＰＩＭ发布工具可对整个ＡＰＩ接口进行授权ꎬ实现不同角色的人员查看不同的ＡＰＩꎮ但是ꎬ在平台运维

图３　新的消息传输机制

过程中可能会出现一些特殊的权限管理要求ꎬ如ＡＰＩ调用对象是一个系统而不是开发者ꎬ需分别对ＡＰＩ中的

Ｅｎｄｐｏｉｎｔ单独授权ꎮ对此ꎬ采用ＸＡＣＭＬ实现ꎮ

可扩展访问控制标记语言(ｅＸｔｅｎｓｉｂｌｅＡｃｃｅｓｓＣｏｎｔｒｏｌＭａｒｋｕｐＬａｎｇｕａｇｅꎬＸＡＣＭＬ)定义一种基于属性的声

明性细粒度访问控制策略语言、体系结构和处理模型ꎬ描述如何根据策略中定义的规则评估访问请求

[４]

ꎮ

通过ＸＡＣＭＬꎬ可描述如何控制某个具体ＡＰＩＥｎｄｐｏｉｎｔ的访问权限ꎬ如要求调用者属于某个角色ꎬ或角色名符

合某个表达式等ꎮ

在身份信息服务中ꎬ采用内置的ＸＡＣＭＬ编辑器编写相应的业务控制规则ꎬ如某个ＡＰＩＥｎｄｐｏｉｎｔ需用户

属于特定的角色ꎮ在规则发布之后ꎬＡＰＩ网关将在调用ＡＰＩ时按对应的规则检查ꎮ若符合规则要求ꎬ则正常

转发请求至后端服务ꎬ否则返回ＨｔｔｐＣｏｄｅ４０３(Ｆｏｒｂｉｄｄｅｎ)ꎬ禁止用户调用该ＡＰＩＥｎｄｐｏｉｎｔꎮ

ＸＡＣＭＬ编辑器界面见图４ꎮ

图４　ＸＡＣＭＬ编辑器界面

２.３　用户信息透传

由于ＡＰＩ管理平台具有透明性ꎬ在后端接口的服务中ꎬ默认无法获取当前调用的用户信息ꎮ一般的ＡＰＩ

４４

上　海　船　舶　运　输　科　学　研　究　所　学　报２０２０年第４期　

对接流程是ꎬＡＰＩ的后端服务不进行身份验证ꎬ由ＡＰＩ管理平台实现用户管理ꎬ对于后端系统而言ꎬ所有的接

口调用均匿名ꎮ在部分接口发布过程中ꎬ后端系统明确要求将当前用户的信息传输至后端系统中ꎮ对此ꎬ需

对ＡＰＩ管理平台的传输机制进行调整改造ꎮ

ＡＰＩＭ平台采用ＯＡｕｔｈ２.０的身份认证机制ꎬ在默认配置下ꎬ采用ＡｃｃｅｓｓＴｏｋｅｎ进行身份信息交互ꎬ简单

将该Ｔｏｋｅｎ传输至后端系统中无法满足需求ꎮ由此ꎬ对身份验证服务的配置进行调整ꎬ使其在传输调用信息

至后端接口时生成一个包含当前用户信息的ＪＷＴＴｏｋｅｎꎬ附加在Ｈｅａｄｅｒ中ꎮ后端接口通过对应的Ｈｅａｄｅｒ字

段获取ＪＷＴＴｏｋｅｎꎬ经过解码之后即可获得相关的用户信息ꎮ

在ＡＰＩＭ平台中ꎬ已存在相关的内置类(ＤｅｆａｕｌｔＣｌａｉｍｓＲｅｔｒｉｅｖｅｒ)实现Ｔｏｋｅｎ的生成和注入ꎮ由于此内置

类提供的用户属性较少ꎬ不满足业务需求ꎬ需自行编程实现其他属性的注入ꎮ编写相应的Ｊａｖａ代码ꎬ继承

ＡＰＩＭ框架的ＡｂｓｔｒａｃｔＪＷＴＧｅｎｅｒａｔｏｒ类ꎬ通过ｐｏｐｕｌａｔｅＳｔａｎｄａｒｄＣｌａｉｍｓ方法实现用户指定属性的注入ꎮ相关代

码如下:

ｔｉｏｎ{

ｐｕｂｌｉｃＭａｐ<ＳｔｒｉｎｇꎬＳｔｒｉｎｇ>ｐｏｐｕｌａｔｅＳｔａｎｄａｒｄＣｌａｉｍｓ(ＴｏｋｅｎＶａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ)ｔｈｒｏｗｓＡＰＩＭａｎａｇｅｍｅｎｔＥｘｃｅｐ￣

ｌｏｎｇｃｕｒｒｅｎｔＴｉｍｅ＝Ｓｙｓｔｅｍ.ｃｕｒｒｅｎｔＴｉｍｅＭｉｌｌｉｓ()ꎻ

ｌｏｎｇｅｘｐｉｒｅＩｎ＝ｃｕｒｒｅｎｔＴｉｍｅ＋ｇｅｔＴＴＬ()∗１０００ꎻ

ＳｔｒｉｎｇａｐｐｌｉｃａｔｉｏｎＩｄ＝ｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶａｌｉｄａｔｉｏｎＩｎｆｏＤＴＯ().ｇｅｔＡｐｐｌｉｃａｔｉｏｎＩｄ()ꎻ

Ｓｔｒｉｎｇｔｉｅｒ＝ｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶａｌｉｄａｔｉｏｎＩｎｆｏＤＴＯ().ｇｅｔＴｉｅｒ()ꎻ

ＳｔｒｉｎｇｅｎｄＵｓｅｒＮａｍｅ＝ｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶａｌｉｄａｔｉｏｎＩｎｆｏＤＴＯ().ｇｅｔＥｎｄＵｓｅｒＮａｍｅ()ꎻ

ＳｔｒｉｎｇｋｅｙＴｙｐｅ＝ｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶａｌｉｄａｔｉｏｎＩｎｆｏＤＴＯ().ｇｅｔＴｙｐｅ()ꎻ

ＳｔｒｉｎｇａｐｐｌｉｃａｔｉｏｎＴｉｅｒ＝ｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶａｌｉｄａｔｉｏｎＩｎｆｏＤＴＯ().ｇｅｔＡｐｐｌｉｃａｔｉｏｎＴｉｅｒ()ꎻ

ｉｆ(ｅｎｄＵｓｅｒＮａｍｅ.ｅｎｄｓＷｉｔｈ("＠ｃａｒｂｏｎ.ｓｕｐｅｒ")){

}

ｅｎｄＵｓｅｒＮａｍｅ＝ｅｎｄＵｓｅｒＮａｍｅ.ｒｅｐｌａｃｅ("＠ｃａｒｂｏｎ.ｓｕｐｅｒ"ꎬ"")ꎻ

Ｍａｐ<ＳｔｒｉｎｇꎬＳｔｒｉｎｇ>ｃｌａｉｍｓ＝ｎｅｗＬｉｎｋｅｄＨａｓｈＭａｐ<ＳｔｒｉｎｇꎬＳｔｒｉｎｇ>(２０)ꎻ

ｃｌａｉｍｓ.ｐｕｔ("ａｐｐｌｉｃａｔｉｏｎｉｄ"ꎬａｐｐｌｉｃａｔｉｏｎＩｄ)ꎻ

ｃｌａｉｍｓ.ｐｕｔ("ｅｎｄｕｓｅｒ"ꎬｅｎｄＵｓｅｒＮａｍｅ)ꎻ

ｃｌａｉｍｓ.ｐｕｔ("ｋｅｙｔｙｐｅ"ꎬｋｅｙＴｙｐｅ)ꎻ

ｃｌａｉｍｓ.ｐｕｔ("ｔｉｅｒ"ꎬｔｉｅｒ)ꎻ

ｃｌａｉｍｓ.ｐｕｔ("ａｐｐｌｉｃａｔｉｏｎｔｉｅｒ"ꎬａｐｐｌｉｃａｔｉｏｎＴｉｅｒ)ꎻ

ｃｌａｉｍｓ.ｐｕｔ("ｅｘｐ"ꎬＳｔｒｉｎｇ.ｖａｌｕｅＯｆ(ｅｘｐｉｒｅＩｎ))ꎻ

ｃｌａｉｍｓ.ｐｕｔ("ｖｅｒｓｉｏｎ"ꎬｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶｅｒｓｉｏｎ())ꎻ

ｒｅｔｕｒｎｃｌａｉｍｓꎻ

２.４　ＡＰＩ管理平台监控大屏

在发布工具中ꎬＡＰＩ管理平台提供对ＡＰＩ情况的分析ꎬ可从ＡＰＩ调用次数、ＡＰＩ调用者和我的ＡＰＩ调用

等维度进行统计分析ꎮ但是ꎬ从ＡＰＩ管理平台管理的角度出发ꎬ已有的分析数据还不足以反映整个ＡＰＩ管理

平台的运行情况ꎮ

为获取已有ＡＰＩ的统计数据和实时调用数据ꎬ从系统文档出发ꎬ仔细对ＡＰＩ管理平台的开发者门户和统

计服务提供的相关ＡＰＩ进行梳理ꎮ针对２个方面的需求ꎬ逐一对照整理ꎬ形成以下结论:

１)对于ＡＰＩ数量和分类等静态信息ꎬ可调用开发者门户的接口ꎻ

２)对于ＡＰＩ调用次数和最近调用ＡＰＩ等动态信息ꎬ可调用统计分析服务的接口ꎮ

}

统计分析服务使用的Ｓｉｄｄｈｉ组件采用的是类似大数据的处理方式ꎬ通过调用接口提交一个类ＳＱＬ语

李　翔:基于ＷＳＯ

２

ＡＰＩＭ的ＡＰＩ全生命周期管理平台架构设计与研发　　　　　　

４５

句ꎬ可根据要求对统计数据进行汇总计算ꎬ实现监控大屏的数据源获取ꎮ

{

例如ꎬ对于最近调用的ＡＰＩ数据ꎬ可通过发送以下请求到统计分析服务中来获取ꎮ

ａｐｐＮａｍｅ:"ＡＰＩＭ＿ＡＣＣＥＳＳ＿ＳＵＭＭＡＲＹ"ꎬ

ｃｅｓｓＴｉｍｅＤＥＳＣꎻ"

}

ｑｕｅｒｙ:"ｆｒｏｍＡｐｉＬａｓｔＡｃｃｅｓｓＳｕｍｍａｒｙｏｎｌａｓｔＡｃｃｅｓｓＴｉｍｅ>１５９０９８４００００００ＬｓｅｌｅｃｔａｐｉＮａｍｅꎬｌａｓｔＡｃｃｅｓｓＴｉｍｅｏｒｄｅｒｂｙｌａｓｔＡｃ￣

者门户等服务进行数据交互ꎮ最终的ＡＰＩ管理平台监控大屏见图５ꎮ

ＡＰＩ管理平台监控大屏采用ｅＣｈａｒｔｓ作为前端开发组件ꎬ采用Ｎｏｄｅ.ｊｓ开发后端服务ꎬ与统计分析和开发

　　通过一系列的功能完善ꎬＡＰＩ管理平台已能满足整个公司内部的ＡＰＩ管理需求ꎮ通过引入Ｋａｆｋａ并结

了基础ꎮＡＰＩＭ组件提供了完整的ＡＰＩꎬ可实现与其他应用的数据集成ꎮ

图５　ＡＰＩ管理平台监控大屏

合ＥＬＫꎬ使得ＡＰＩ管理平台对ＡＰＩ调用流水记录的保存能力明显增强ꎬ为后续基于流水数据的统计分析奠定

３　结　语

目前ꎬＡＰＩ管理平台已正式服务于该公司ꎬ共发布ＡＰＩ１００多个ꎬ接入的相关用户和系统超过６０个ꎬ累积

调用次数已接近４０００万次ꎮ通过建设ＡＰＩ管理平台ꎬ各业务系统间的数据和能力交换得以顺利、高效进

行ꎬ各业务系统的开发效率得到明显提升ꎮ通过引入外部的语音识别和文字识别等ＯｐｅｎＡＰＩꎬ业务系统的服

务能力也得到明显增强ꎮ

ＡＰＩ管理平台以微服务架构部署在公司内部的容器云上ꎬ平台的可用性得到了较好的保障ꎬ为公司内各

关键应用提供了高质量的数据服务ꎮ得益于ＡＰＩＭ的开放性ꎬＡＰＩ管理平台可根据业务需求进行一系列的

增强完善ꎮ通过对ＡＰＩ管理平台各组件的数据流进行分析ꎬ并结合行业中的最佳实践ꎬ平台的整体服务能力

得到了进一步提升ꎮ

参考文献:

[１]　黄若虹.开放银行体系构建及商业模式研究[Ｊ].区域金融研究ꎬ２０２０(６):３０￣３５.

４１(３):５１￣５７.

[２]　王骏翔ꎬ郭磊.基于Ｋｕｂｅｒｎｅｔｅｓ和Ｄｏｃｋｅｒ技术的企业级容器云平台解决方案[Ｊ].上海船舶运输科学研究所学报ꎬ２０１８ꎬ

[３]　阮晓龙ꎬ贺路路.基于ＥＬＫ＋Ｋａｆｋａ的智慧运维大数据分析平台研究与实现[Ｊ].软件导刊ꎬ２０２０ꎬ１９(６):１５０￣１５４.

[４]　维基百科.ＸＡＣＭＬＷｉｋｉｐｅｄｉａ[ＥＢ/ＯＬ].(２０２０￣０７￣２４)[２０２０￣０８￣０９].ｈｔｔｐｓ://ｅｎ.ｗｉｋｉｐｅｄｉａ.ｏｒｇ/ｗｉｋｉ/ＸＡＣＭＬ.