第４３卷㊀第４期２０２０年１２月㊀㊀上㊀海㊀船㊀舶㊀运㊀输㊀科㊀学㊀研㊀究㊀所㊀学㊀报ＪＯＵＲＮＡＬＯＦＳＨＡＮＧＨＡＩＳＨＩＰＡＮＤＳＨＩＰＰＩＮＧＲＥＳＥＡＲＣＨＩＮＳＴＩＴＵＴＥＶｏｌ.４３Ｎｏ.４Ｄｅｃ.２０２０收稿日期:２０２０￣０８￣１３
作者简介：李㊀翔(１９８５ )ꎬ男ꎬ湖南益阳人ꎬ工程师ꎬ主要从事系统架构设计㊁大数据处理方面的工作ꎮ㊀㊀文章编号:１６７４￣５９４９(２０２０)０４￣００３９￣０６
基于ＷＳＯ２ＡＰＩＭ的ＡＰＩ全生命周期
管理平台架构设计与研发
李㊀翔
(中远海运科技股份有限公司ꎬ上海２００１３５)
摘㊀要：为了能集中高效地对企业中已有的各类应用程序编程接口(ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅꎬＡＰＩ)进行管理ꎬ基于ＷＳＯ２ＡＰＩＭ的开源组件ꎬ设计并搭建一套支持定义㊁开发㊁测试㊁发布和调用管理等ＡＰＩ全生命周期管理的ＡＰＩ管理平台ꎮ通过引入ＥＬＫ㊁Ｋａｆｋａ和ｅＣｈａｒｔｓ等第三方组件进行二次集成研发ꎬ实现对ＡＰＩ调用记录的保存和大屏显示等功能ꎮ经在某大型集团公司实际应用ꎬ验证该平台具有良好的效果ꎮ
关键词：应用程序编程接口管理平台ꎻ全生命周期ꎻ集成研发
中图分类号:ＴＰ３１７.１㊀㊀㊀文献标志码:Ａ
ＡｒｃｈｉｔｅｃｔｕｒｅＤｅｓｉｇｎａｎｄＤｅｖｅｌｏｐｍｅｎｔｏｆＡＰＩＬｉｆｅｃｙｃｌｅＭａｎａｇｅｍｅｎｔＰｌａｔｆｏｒｍＢａｓｅｄｏｎＷＳＯ２ＡＰＩＭ
ＬＩＸｉａｎｇ
(ＣＯＳＣＯＳＨＩＰＰＩＮＧＴｅｃｈｎｏｌｏｇｙＣｏ.ꎬＬｔｄ.ꎬＳｈａｎｇｈａｉ２００１３５ꎬＣｈｉｎａ)
Ａｂｓｔｒａｃｔ:ＯｎｅｏｆｔｈｅｍａｊｏｒｃｈａｌｌｅｎｇｅｓｆｏｒｅｎｔｅｒｐｒｉｓｅｍａｎａｇｅｒｉｓｈｏｗｔｏｍａｎａｇｅａｗｉｄｅｒａｎｇｅｏｆＡＰＩ(ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒ￣ｆａｃｅ)ｅｆｆｉｃｉｅｎｔｌｙ.ＢａｓｅｄｏｎｔｈｅｏｐｅｎｓｏｕｒｃｅＡＰＩＭ(ＡＰＩ￣Ｍａｎａｇｅｒ)ｐｒｏｖｉｄｅｄｂｙＷＳＯ２ꎬａｎＡＰＩｍａｎａｇｅｍｅｎｔｐｌａｔｆｏｒｍｉｓｄｅｓｉｇｎｅｄａｎｄｂｕｉｌｔｔｏｓｕｐｐｏｒｔＡＰＩｍａｎａｇｅｍｅｎｔｉｎｔｈｅｆｕｌｌｌｉｆｅｃｙｃｌｅꎬｉｎｃｌｕｄｉｎｇｄｅｆｉｎｉｔｉｏｎꎬｄｅｖｅｌｏｐｍｅｎｔꎬｔｅｓｔｉｎｇꎬｒｅｌｅａｓｅａｎｄｉｎｖｏｋｉｎｇｍａｎ
微服务网关设计ａｇｅｍｅｎｔ.Ｂｙｉｎｔｒｏｄｕｃｉｎｇｓｏｍｅｔｈｉｒｄ￣ｐａｒｔｙｃｏｍｐｏｎｅｎｔｓｓｕｃｈａｓＥＬＫꎬＫａｆｋａꎬｅＣｈａｒｔｓꎬｔｈｅｆｕｎｃｔｉｏｎｓꎬｌｉｋｅｒｅｃｏｄｉｎｇｔｈｅｒａｗｌｏｇｏｆＡＰＩｃａｌｌｉｎｇａｎｄｔｈｅｐｌａｔｆｏｒｍｄａｓｈｂｏａｒｄａｒｅｄｅｖｅｌｏｐｅｄ.Ｔｈｉｓｐｌａｔｆｏｒｍｈａｓｂｅｅｎｏｆｆｉｃｉａｌｌｙｌａｕｎｃｈｅｄｉｎａｌａｒｇｅｇｒｏｕｐｃｏｍｐａｎｙａｎｄａｃｈｉｅｖｅｄｅｘｃｅｌｌｅｎｔｒｅ￣ｓｕｌｔｓ.Ｋｅｙｗｏｒｄｓ:ＡＰＩｍａｎａｇｅｍｅｎｔｐｌａｔｆｏｒｍꎻｆｕｌｌｌｉｆｅｃｙｃｌｅꎻｓｙｓｔｅｍｉｎｔｅｇｒａｔｉｏｎ０㊀引㊀言㊀㊀随着微服务架构的不断发展ꎬ各应用服务之间的数据交互越来越多地采用应用程序编程接口(Ａｐｐｌｉｃａ￣ｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅꎬＡＰＩ)完成ꎮＡＰＩ可完成系统内部各组件和各系统间的数据交换ꎮ以ＡＰＩ的方式进行服务调用ꎬ可避免重复开发代码ꎬ从而提高系统集成的效率ꎻ同时ꎬ各应用系统间的数据孤岛可被打破ꎬ数据资源可得到更加高效的利用ꎮ公司或组织(即ＡＰＩ提供者)通过ＡＰＩ的方式将其数据资产或服务提供给内部或第三方(即ＡＰＩ消费者)ꎬ能更好地开发和提升其业务价值[１]ꎮ目前ꎬ除了企业内部ꎬ越来越多的互联网企业开始采用ＡＰＩ提供公共服务ꎬ即开放ＡＰＩ(ＯｐｅｎＡＰＩ)ꎮ因此ꎬ企业内部应用系统可很好地利用ＯｐｅｎＡＰＩ为企业创新应用赋能ꎬ提高系统的处理能力ꎬ扩大其业务范围ꎮ
某大型集团公司在信息化系统建设过程中形成了大量内部ＡＰＩꎬ如何便捷高效地对这些接口进行管理ꎬ
是该公司未来提升整体信息化服务能力需考虑的重点问题之一ꎮ对此ꎬ该公司通过对行业内流行的商业和开源方案进行比较ꎬ综合考虑功能完整性㊁性能㊁定制开发能力和运营成本等多方面因素之后ꎬ最终选择由ＷＳＯ２开源的ＡＰＩ￣Ｍａｎａｇｅｒ(ＡＰＩＭ)搭建ＡＰＩ管理平台ꎬ并在试运行期间针对原生平台存在的不足进行完善和二次研发ꎬ从而实现对ＡＰＩ生成㊁管理和集成的全面管控ꎬ实现对应用系统㊁数据库和已存在的业务ＡＰＩ的统一整合ꎬ提供连接各信息孤岛的数据通路ꎬ进而为数据融合㊁应用重组和业务重构奠定技术基础ꎮ１㊀平台架构设计
ＡＰＩ管理平台采用由ＷＳＯ２开源的构建于轻量企业服务总线(ＥｎｔｅｒｐｒｉｓｅＳｅｒｖｉｃｅＢｕｓꎬＥＳＢ)组件Ａｐａｃｈｅ
Ｓｙｎａｐｓｅ上的ＡＰＩＭ设计ꎮ整个管理平台采用微服务架构ꎬ各组件可实现动态伸缩ꎬ保证平台不存在性能瓶颈ꎮ平台提供完善的ＡＰＩ管理能力ꎬ具有限流㊁分项授权㊁后端负载均衡和故障转移等功能ꎮ整个ＡＰＩ管理平台由开发者门户㊁ＡＰＩ发布组件㊁ＡＰＩ网关㊁身份信息服务和统计服务等５部分组成ꎬ其架构见图
１ꎮ图１㊀ＡＰＩ
管理平台系统架构
图２㊀ＡＰＩ生命周期管理流程１.１㊀发布工具
ＡＰＩ管理平台通过ＡＰＩ发布工具对ＡＰＩ进行生命周期管理ꎬ包括开发㊁发布㊁管理和监控ꎮ在ＡＰＩ管理
平台中ꎬＳＯＡＰ(ＳｉｍｐｌｅＯｂｊｅｃｔＡｃｃｅｓｓＰｒｏｔｏｃｏｌ)风格接口和Ｒｅｓｔｆｕｌ风格接口都能得到良好的支持ꎮ１)对于Ｒｅｓｔｆｕｌ风格的接口ꎬＡＰＩ管理平台通过集成Ｓｗａｇｇｅｒ工具提供支持ꎮ目前ꎬ基于ＳｗａｇｇｅｒＹＡＭＬ/ＪＳＯＮ的ＡＰＩ描述定义已成为Ｒｅｓｔｆｕｌ风格ＡＰＩ的事实性标准ꎮ在业务系统的接口开发中ꎬ通过Ｓｗａｇｇｅｒ相关工具包ꎬ可自动生成ＡＰＩ的描述文档ꎮ接口开发人员可通过将描述定义粘贴到发布工具中ꎬ完成对ＡＰＩ的定义ꎮ２)对于ＳＯＡＰ风格的接口ꎬ在发布工具中ꎬ可直接通过提供ＷＳＤＬ(ＷｅｂＳｅｒｖｉｃｅｓＤｅｓｃｒｉｐｔｉｏｎＬａｎｇｕａｇｅ)
接口定义的方式完成对ＡＰＩ的定义ꎮ
在完成接口定义之后ꎬ接口发布人员可指定接口后
端服务的测试环境地址和生产环境地址ꎬ便于接口使用
者对接口进行测试和正式调用ꎮ考虑到对分布式大规模
系统的支持ꎬ发布工具中允许对各类地址定义多个后端ꎬ
通过负载均衡提供更大的吞吐量和更强的并发性ꎮ
整个ＡＰＩ的生命周期包含创建㊁原型㊁发布㊁阻止㊁弃
用和下线等６个阶段ꎮ各阶段的转换关系见图２ꎮ㊀㊀ＡＰＩ生命周期各阶段的含义如下ꎮ
１)创建:ＡＰＩ已在平台中定义ꎬ但还没有发布ꎬ此时
ＡＰＩ用户无法看到对应的ＡＰＩꎮ１
４李㊀翔：基于ＷＳＯ２ＡＰＩＭ的ＡＰＩ全生命周期管理平台架构设计与研发㊀㊀㊀㊀㊀㊀
２４上㊀海㊀船㊀舶㊀运㊀输㊀科㊀学㊀研㊀究㊀所㊀学㊀报２０２０年第４期㊀２)原型:ＡＰＩ以原型方式发布ꎬ已定义相关的接口ꎬ且通过平台的简单模拟实现对接口的反馈ꎬ该阶段可与ＡＰＩ用户进行接口原型设计ꎮ
㊀㊀３)发布:ＡＰＩ接口正式发布ꎬ服务上线ꎮ此时用户可在开发者门户中看到对应的ＡＰＩꎮ
４)弃用：当ＡＰＩ接口后端服务被弃用ꎬ或有新版本的接口上线时ꎬ可弃用老版本的接口ꎮ此时ꎬ新用户无法看到该ＡＰＩꎬ但原用户可继续调用ꎮ
㊀㊀５)下线:ＡＰＩ接口终止服务ꎬ无法继续调用ꎮ
６)阻止：调用被临时禁止ꎬ一般用于接口后端服务需进行临时维护的场景ꎮ
１.２㊀开发者门户
开发者门户为ＡＰＩ的调用者提供ＡＰＩ浏览和测试的支持ꎮ在开发者门户中ꎬＡＰＩ调用者可直接浏览ＡＰＩ接口的定义ꎬ包括描述信息㊁参数定义和相关接口文档等ꎮ同时ꎬ通过继承Ｓｗａｇｇｅｒ工具ꎬ调用者可直接在页面中对ＡＰＩ接口进行调用测试ꎮ
在浏览ＡＰＩ的同时ꎬＡＰＩ调用者可对ＡＰＩ接口进行订阅ꎬＡＰＩ接口只有在被订阅之后才能调用ꎮ在订阅时可选择不同的并发等级ꎬ例如３００次/ｓ㊁５００次/ｓ等ꎮ不同的订阅等级可对应不同的费用级别ꎬ为后期ＡＰＩ管理平台实行计费提供支持ꎮ
１.３㊀ＡＰＩ网关
ＡＰＩ网关可看作一个复杂的反向代理ꎬ在ＡＰＩ管理平台中ꎬ所有的ＡＰＩ调用都由网关完成ꎮＡＰＩ
调用者的调用请求到达网关之后ꎬ由网关完成身份认证㊁调用并发限制和请求内容检查等操作ꎬ在满足相关要求之后ꎬ数据被转发至接口的后端服务中ꎬ完成接口调用ꎮ在完成请求转发的同时ꎬ整个调用过程被完整地记录下来ꎬ相关流水信息被发送至统计服务中进行后续分析处理ꎮ
１.４㊀身份信息服务
身份信息服务提供对平台整个用户信息体系的管理ꎮＡＰＩ管理平台在调用接口过程中ꎬ其身份验证采用的是ＯＡｕｔｈ２协议ꎮＴｏｋｅｎ的产生和生命周期管理等均由身份信息服务提供ꎮ同时ꎬ平台支持对单独ＡＰＩＥｎｄｐｏｉｎｔ进行授权ꎬ相关的权限检查也由身份信息服务完成ꎮ
１.５㊀统计服务
ＡＰＩ的调用流水数据由网关产生之后被发送至统计服务中ꎮ统计服务采用流式计算框架Ｓｉｄｄｈｉꎬ在接收到调用流水数据之后ꎬ在内存中进行实时聚合ꎬ并定期写入后台数据库中ꎬ形成各种维度的报表ꎮ同时ꎬ各ＡＰＩ接口的健康状况由统计服务进行分析ꎮ通过对得到的流水数据进行分析ꎬ统计服务可获得各ＡＰＩ接口的运行情况ꎬ当出现异常(例如１ｍｉｎ内调用量发生急剧变化)时ꎬ能通过邮件等方式及时通知相关人员ꎮ
１.６㊀平台部署
结合目前业界流行的容器管理技术ꎬ整个ＡＰＩ管理平台以微服务的方式部署在集团内部的Ｋｕｂｅｒｎｅｔｅｓ容器平台中ꎮ通过充分利用容器平台高可用㊁高冗余的管理能力[２]ꎬＡＰＩ管理平台能根据负载进行高效弹性伸缩和自动故障恢复的部署ꎮ同时ꎬ平台拥有一定的 自愈 能力ꎬ当某个微服务因出现故障而失效时ꎬ容器云会自动对其进行重启ꎬ实现快速恢复ꎮ在重启期间ꎬ流量会定向至其他正常运行的微服务ꎬ保证服务不中断ꎮ
２㊀平台二次集成研发
通过使用ＡＰＩＭ已有组件ꎬ整个ＡＰＩ管理平台能满足企业内部的大部分功能需求ꎬ但随着平台的部署实施和上线使用ꎬ已有组件逐渐无法满足部分管理需求ꎬ如调用流水记录㊁终端授权㊁用户信息透传和大数据监控等ꎮ对此ꎬ还需引入其他组件ꎬ并进行二次集成研发ꎬ对平台的功能进行完善和增强ꎮ
２.１㊀ＡＰＩ调用流水记录
在已有的功能组件中ꎬＡＰＩ调用的流水记录仅用于产生统计汇总数据ꎬ原始流水记录并没有保存ꎬ这对于服务于整个集团的ＡＰＩ管理平台而言是一个较大的功能缺失项ꎮ
从使用的便捷性和功能的完整性的角度来说ꎬ日志管理平台首推ＥＬＫ(ＥｌａｓｔｉｃＳｅａｒｃｈ㊁Ｌｏｇｓｔａｓｈ㊁Ｋｉｂａｎａ)ꎮ通过查阅统计分析服务的相关手册得知ꎬＳｉｄｄｈｉ支持ＲＤＢＭＳ㊁ＫＡＦＫＡ㊁ＥＳ和ＨＴＴＰ等方式的数据输出ꎮ对
此ꎬ参考已有的统计分析应用ꎬ直接将ＡＰＩ的流水记录发送给ＥｌａｓｔｉｃＳｅａｒｃｈ集ꎮ
上线运行一段时间之后ꎬ发现该方案存在以下不足:１)无法对数据的格式进行调整ꎮ由于是直接从统计分析服务中写入ＥＳ集ꎬ中间没有任何数据处理ꎬ无法利用Ｌｏｇｓｔａｓｈ强大的ｆｉｌｔｅｒ插件ꎮ２)稳定性有一定的欠缺ꎮ由于统计分析服务中对流水记录不作任何缓存ꎬ当因某些外部原因导致连接中断时ꎬ流水记录会丢失ꎮ
参考文献[３]ꎬ引入ＫＡＦＫＡ组件对消息进行暂存ꎬ借以减轻Ｌｏｇｓｔａｓｈ的压力ꎬ避免日志在处理之前丢失ꎮ新的消息传输机制见图
３ꎮ图３㊀新的消息传输机制㊀㊀消息发送到ＫＡＦＫＡ中暂存ꎬ由Ｌｏｇｓｔａｓｈ消费ＫＡＦＫＡ获取流水记录ꎬ经过Ｆｉｌｔｅｒ调整格式之后ꎬ发送至ＥＳ集中进行保存和后续查询分析ꎮ２.２㊀单个ＡＰＩＥｎｄｐｏｉｎｔ的授权ＡＰＩＭ发布工具可对整个ＡＰＩ接口进行授权ꎬ实现不同角的人员查看不同的ＡＰＩꎮ但是ꎬ在平台运维过程中可能会出现一些特殊的权限管理要求ꎬ如ＡＰＩ调用对象是一个系统而不是开发者ꎬ需分别对ＡＰＩ中的Ｅｎｄｐｏｉｎｔ单独授权ꎮ对此ꎬ采用ＸＡＣＭＬ实现ꎮ
可扩展访问控制标记语言(ｅＸｔｅｎｓｉｂｌｅＡｃｃｅｓｓＣｏｎｔｒｏｌＭａｒｋｕｐＬａｎｇｕａｇｅꎬＸＡＣＭＬ)定义一种基于属性的声明性细粒度访问控制策略语言㊁体系结构和处理模型ꎬ描述如何根据策略中定义的规则评估访问请求[４]ꎮ通过ＸＡＣＭＬꎬ可描述如何控制某个具体ＡＰＩＥｎｄｐｏｉｎｔ的访问权限ꎬ如要求调用者属于某个角ꎬ或角名符合某个表达式等ꎮ
在身份信息服务中ꎬ采用内置的ＸＡＣＭＬ编辑器编写相应的业务控制规则ꎬ如某个ＡＰＩＥｎｄｐｏｉｎｔ需用户属于特定的角ꎮ在规则发布之后ꎬＡＰＩ网关将在调用ＡＰＩ时按对应的规则检查ꎮ若符合规则要求ꎬ则正常转发请求至后端服务ꎬ否则返回ＨｔｔｐＣｏｄｅ４０３(Ｆｏｒｂｉｄｄｅｎ)ꎬ禁止用户调用该ＡＰＩＥｎｄｐｏｉｎｔꎮＸＡＣＭＬ编辑器界面见图４ꎮ
图４㊀ＸＡＣＭＬ编辑器界面
２.３㊀用户信息透传
由于ＡＰＩ管理平台具有透明性ꎬ在后端接口的服务中ꎬ默认无法获取当前调用的用户信息ꎮ一般的ＡＰＩ３
４李㊀翔：基于ＷＳＯ２ＡＰＩＭ的ＡＰＩ全生命周期管理平台架构设计与研发㊀㊀㊀㊀㊀㊀
４４上㊀海㊀船㊀舶㊀运㊀输㊀科㊀学㊀研㊀究㊀所㊀学㊀报２０２０年第４期㊀
对接流程是ꎬＡＰＩ的后端服务不进行身份验证ꎬ由ＡＰＩ管理平台实现用户管理ꎬ对于后端系统而言ꎬ所有的接口调用均匿名ꎮ在部分接口发布过程中ꎬ后端系统明确要求将当前用户的信息传输至后端系统中ꎮ对此ꎬ需对ＡＰＩ管理平台的传输机制进行调整改造ꎮ
ＡＰＩＭ平台采用ＯＡｕｔｈ２.０的身份认证机制ꎬ在默认配置下ꎬ采用ＡｃｃｅｓｓＴｏｋｅｎ进行身份信息交互ꎬ简单将该Ｔｏｋｅｎ传输至后端系统中无法满足需求ꎮ由此ꎬ对身份验证服务的配置进行调整ꎬ使其在传输调用信息至后端接口时生成一个包含当前用户信息的ＪＷＴＴｏｋｅｎꎬ附加在Ｈｅａｄｅｒ中ꎮ后端接口通过对应的Ｈｅａｄｅｒ字段获取ＪＷＴＴｏｋｅｎꎬ经过解码之后即可获得相关的用户信息ꎮ
在ＡＰＩＭ平台中ꎬ已存在相关的内置类(ＤｅｆａｕｌｔＣｌａｉｍｓＲｅｔｒｉｅｖｅｒ)实现Ｔｏｋｅｎ的生成和注入ꎮ由于此内置
类提供的用户属性较少ꎬ不满足业务需求ꎬ需自行编程实现其他属性的注入ꎮ编写相应的Ｊａｖａ代码ꎬ继承ＡＰＩＭ框架的ＡｂｓｔｒａｃｔＪＷＴＧｅｎｅｒａｔｏｒ类ꎬ通过ｐｏｐｕｌａｔｅＳｔａｎｄａｒｄＣｌａｉｍｓ方法实现用户指定属性的注入ꎮ相关代码如下:
ｐｕｂｌｉｃＭａｐ<ＳｔｒｉｎｇꎬＳｔｒｉｎｇ>ｐｏｐｕｌａｔｅＳｔａｎｄａｒｄＣｌａｉｍｓ(ＴｏｋｅｎＶａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ)ｔｈｒｏｗ
ｓＡＰＩＭａｎａｇｅｍｅｎｔＥｘｃｅｐ￣ｔｉｏｎ{
ｌｏｎｇｃｕｒｒｅｎｔＴｉｍｅ＝Ｓｙｓｔｅｍ.ｃｕｒｒｅｎｔＴｉｍｅＭｉｌｌｉｓ()ꎻ
ｌｏｎｇｅｘｐｉｒｅＩｎ＝ｃｕｒｒｅｎｔＴｉｍｅ＋ｇｅｔＴＴＬ()∗１０００ꎻ
ＳｔｒｉｎｇａｐｐｌｉｃａｔｉｏｎＩｄ＝ｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶａｌｉｄａｔｉｏｎＩｎｆｏＤＴＯ().ｇｅｔＡｐｐｌｉｃａｔｉｏｎＩｄ()ꎻ
Ｓｔｒｉｎｇｔｉｅｒ＝ｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶａｌｉｄａｔｉｏｎＩｎｆｏＤＴＯ().ｇｅｔＴｉｅｒ()ꎻ
ＳｔｒｉｎｇｅｎｄＵｓｅｒＮａｍｅ＝ｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶａｌｉｄａｔｉｏｎＩｎｆｏＤＴＯ().ｇｅｔＥｎｄＵｓｅｒＮａｍｅ()ꎻ
ＳｔｒｉｎｇｋｅｙＴｙｐｅ＝ｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶａｌｉｄａｔｉｏｎＩｎｆｏＤＴＯ().ｇｅｔＴｙｐｅ()ꎻ
ＳｔｒｉｎｇａｐｐｌｉｃａｔｉｏｎＴｉｅｒ＝ｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶａｌｉｄａｔｉｏｎＩｎｆｏＤＴＯ().ｇｅｔＡｐｐｌｉｃａｔｉｏｎＴｉｅｒ()ꎻ
ｉｆ(ｅｎｄＵｓｅｒＮａｍｅ.ｅｎｄｓＷｉｔｈ("＠ｃａｒｂｏｎ.ｓｕｐｅｒ")){
ｅｎｄＵｓｅｒＮａｍｅ＝ｅｎｄＵｓｅｒＮａｍｅ.ｒｅｐｌａｃｅ("＠ｃａｒｂｏｎ.ｓｕｐｅｒ"ꎬ"")ꎻ
}
Ｍａｐ<ＳｔｒｉｎｇꎬＳｔｒｉｎｇ>ｃｌａｉｍｓ＝ｎｅｗＬｉｎｋｅｄＨａｓｈＭａｐ<ＳｔｒｉｎｇꎬＳｔｒｉｎｇ>(２０)ꎻ
ｃｌａｉｍｓ.ｐｕｔ("ａｐｐｌｉｃａｔｉｏｎｉｄ"ꎬａｐｐｌｉｃａｔｉｏｎＩｄ)ꎻ
ｃｌａｉｍｓ.ｐｕｔ("ａｐｐｌｉｃａｔｉｏｎｔｉｅｒ"ꎬａｐｐｌｉｃａｔｉｏｎＴｉｅｒ)ꎻ
ｃｌａｉｍｓ.ｐｕｔ("ｅｎｄｕｓｅｒ"ꎬｅｎｄＵｓｅｒＮａｍｅ)ꎻ
ｃｌａｉｍｓ.ｐｕｔ("ｅｘｐ"ꎬＳｔｒｉｎｇ.ｖａｌｕｅＯｆ(ｅｘｐｉｒｅＩｎ))ꎻ
ｃｌａｉｍｓ.ｐｕｔ("ｋｅｙｔｙｐｅ"ꎬｋｅｙＴｙｐｅ)ꎻ
ｃｌａｉｍｓ.ｐｕｔ("ｔｉｅｒ"ꎬｔｉｅｒ)ꎻ
ｃｌａｉｍｓ.ｐｕｔ("ｖｅｒｓｉｏｎ"ꎬｖａｌｉｄａｔｉｏｎＣｏｎｔｅｘｔ.ｇｅｔＶｅｒｓｉｏｎ())ꎻ
ｒｅｔｕｒｎｃｌａｉｍｓꎻ
}
２.４㊀ＡＰＩ管理平台监控大屏
在发布工具中ꎬＡＰＩ管理平台提供对ＡＰＩ情况的分析ꎬ可从ＡＰＩ调用次数㊁ＡＰＩ调用者和我的ＡＰＩ调用
等维度进行统计分析ꎮ但是ꎬ从ＡＰＩ管理平台管理的角度出发ꎬ已有的分析数据还不足以反映整个ＡＰＩ管理
平台的运行情况ꎮ
为获取已有ＡＰＩ的统计数据和实时调用数据ꎬ从系统文档出发ꎬ仔细对ＡＰＩ管理平台的开发者门户和统
计服务提供的相关ＡＰＩ进行梳理ꎮ针对２个方面的需求ꎬ逐一对照整理ꎬ形成以下结论:
１)对于ＡＰＩ数量和分类等静态信息ꎬ可调用开发者门户的接口ꎻ
２)对于ＡＰＩ调用次数和最近调用ＡＰＩ等动态信息ꎬ可调用统计分析服务的接口ꎮ
统计分析服务使用的Ｓｉｄｄｈｉ组件采用的是类似大数据的处理方式ꎬ通过调用接口提交一个类ＳＱＬ语

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。