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

李 翔

(中远海运科技股份有限公司， 上海 200135)

0 引 言

随着微服务架构的不断发展，各应用服务之间的数据交互越来越多地采用应用程序编程接口(Application Programming Interface，API)完成。API可完成系统内部各组件和各系统间的数据交换。以API的方式进行服务调用，可避免重复开发代码，从而提高系统集成的效率；同时，各应用系统间的数据孤岛可被打破，数据资源可得到更加高效的利用。公司或组织(即API提供者)通过API的方式将其数据资产或服务提供给内部或第三方(即API消费者)，能更好地开发和提升其业务价值[1]。目前，除了企业内部，越来越多的互联网企业开始采用API提供公共服务，即开放API(OpenAPI)。因此，企业内部应用系统可很好地利用OpenAPI为企业创新应用赋能，提高系统的处理能力，扩大其业务范围。

某大型集团公司在信息化系统建设过程中形成了大量内部API，如何便捷高效地对这些接口进行管理，是该公司未来提升整体信息化服务能力需考虑的重点问题之一。对此，该公司通过对行业内流行的商业和开源方案进行比较，综合考虑功能完整性、性能、定制开发能力和运营成本等多方面因素之后，最终选择由WSO2开源的API-Manager(APIM)搭建API管理平台，并在试运行期间针对原生平台存在的不足进行完善和二次研发，从而实现对API生成、管理和集成的全面管控，实现对应用系统、数据库和已存在的业务API的统一整合，提供连接各信息孤岛的数据通路，进而为数据融合、应用重组和业务重构奠定技术基础。

1 平台架构设计

API管理平台采用由WSO2开源的构建于轻量企业服务总线(Enterprise Service Bus, ESB)组件Apache Synapse上的APIM设计。整个管理平台采用微服务架构，各组件可实现动态伸缩，保证平台不存在性能瓶颈。平台提供完善的API管理能力，具有限流、分项授权、后端负载均衡和故障转移等功能。整个API管理平台由开发者门户、API发布组件、API网关、身份信息服务和统计服务等5部分组成，其架构见图1。

图1 API管理平台系统架构

图2 API生命周期管理流程

1.1 发布工具

API管理平台通过API发布工具对API进行生命周期管理，包括开发、发布、管理和监控。在API管理平台中，SOAP(Simple Object Access Protocol)风格接口和Restful风格接口都能得到良好的支持。

1) 对于Restful风格的接口，API管理平台通过集成Swagger工具提供支持。目前，基于Swagger YAML/JSON的API描述定义已成为Restful风格API的事实性标准。在业务系统的接口开发中，通过Swagger相关工具包，可自动生成API的描述文档。接口开发人员可通过将描述定义粘贴到发布工具中，完成对API的定义。

2) 对于SOAP风格的接口，在发布工具中，可直接通过提供WSDL(Web Services Description Language)接口定义的方式完成对API的定义。

在完成接口定义之后，接口发布人员可指定接口后端服务的测试环境地址和生产环境地址，便于接口使用者对接口进行测试和正式调用。考虑到对分布式大规模系统的支持，发布工具中允许对各类地址定义多个后端，通过负载均衡提供更大的吞吐量和更强的并发性。

整个API的生命周期包含创建、原型、发布、阻止、弃用和下线等6个阶段。各阶段的转换关系见图2。

API生命周期各阶段的含义如下。

1) 创建：API已在平台中定义，但还没有发布，此时API用户无法看到对应的API。

2) 原型：API以原型方式发布，已定义相关的接口，且通过平台的简单模拟实现对接口的反馈，该阶段可与API用户进行接口原型设计。

3) 发布：API接口正式发布，服务上线。此时用户可在开发者门户中看到对应的API。

4) 弃用：当API接口后端服务被弃用，或有新版本的接口上线时，可弃用老版本的接口。此时，新用户无法看到该API，但原用户可继续调用。

5) 下线：API接口终止服务，无法继续调用。

6) 阻止：调用被临时禁止，一般用于接口后端服务需进行临时维护的场景。

1.2 开发者门户

开发者门户为API的调用者提供API浏览和测试的支持。在开发者门户中，API调用者可直接浏览API接口的定义，包括描述信息、参数定义和相关接口文档等。同时，通过继承Swagger工具，调用者可直接在页面中对API接口进行调用测试。

在浏览API的同时，API调用者可对API接口进行订阅，API接口只有在被订阅之后才能调用。在订阅时可选择不同的并发等级，例如300次/s、500次/s等。不同的订阅等级可对应不同的费用级别，为后期API管理平台实行计费提供支持。

1.3 API网关

API网关可看作一个复杂的反向代理，在API管理平台中，所有的API调用都由网关完成。API调用者的调用请求到达网关之后，由网关完成身份认证、调用并发限制和请求内容检查等操作，在满足相关要求之后，数据被转发至接口的后端服务中，完成接口调用。在完成请求转发的同时，整个调用过程被完整地记录下来，相关流水信息被发送至统计服务中进行后续分析处理。

1.4 身份信息服务

身份信息服务提供对平台整个用户信息体系的管理。API管理平台在调用接口过程中，其身份验证采用的是OAuth2协议。Token的产生和生命周期管理等均由身份信息服务提供。同时，平台支持对单独API Endpoint进行授权，相关的权限检查也由身份信息服务完成。

1.5 统计服务

API的调用流水数据由网关产生之后被发送至统计服务中。统计服务采用流式计算框架Siddhi，在接收到调用流水数据之后，在内存中进行实时聚合，并定期写入后台数据库中，形成各种维度的报表。

同时，各API接口的健康状况由统计服务进行分析。通过对得到的流水数据进行分析，统计服务可获得各API接口的运行情况，当出现异常(例如1 min内调用量发生急剧变化)时，能通过邮件等方式及时通知相关人员。

1.6 平台部署

结合目前业界流行的容器管理技术，整个API管理平台以微服务的方式部署在集团内部的Kubernetes容器平台中。通过充分利用容器平台高可用、高冗余的管理能力[2]，API管理平台能根据负载进行高效弹性伸缩和自动故障恢复的部署。同时，平台拥有一定的“自愈”能力，当某个微服务因出现故障而失效时，容器云会自动对其进行重启，实现快速恢复。在重启期间，流量会定向至其他正常运行的微服务，保证服务不中断。

2 平台二次集成研发

通过使用APIM已有组件，整个API管理平台能满足企业内部的大部分功能需求，但随着平台的部署实施和上线使用，已有组件逐渐无法满足部分管理需求，如调用流水记录、终端授权、用户信息透传和大数据监控等。对此，还需引入其他组件，并进行二次集成研发，对平台的功能进行完善和增强。

2.1 API调用流水记录

在已有的功能组件中，API调用的流水记录仅用于产生统计汇总数据，原始流水记录并没有保存，这对于服务于整个集团的API管理平台而言是一个较大的功能缺失项。

从使用的便捷性和功能的完整性的角度来说，日志管理平台首推ELK(Elastic Search、Logstash、Kibana)。通过查阅统计分析服务的相关手册得知，Siddhi支持RDBMS、KAFKA、ES和HTTP等方式的数据输出。对此，参考已有的统计分析应用，直接将API的流水记录发送给Elastic Search集群。

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

1) 无法对数据的格式进行调整。由于是直接从统计分析服务中写入ES集群，中间没有任何数据处理，无法利用Logstash强大的filter插件。

2) 稳定性有一定的欠缺。由于统计分析服务中对流水记录不作任何缓存，当因某些外部原因导致连接中断时，流水记录会丢失。

参考文献[3]，引入KAFKA组件对消息进行暂存，借以减轻Logstash的压力，避免日志在处理之前丢失。新的消息传输机制见图3。

图3 新的消息传输机制

消息发送到KAFKA中暂存，由Logstash消费KAFKA获取流水记录，经过Filter调整格式之后，发送至ES集群中进行保存和后续查询分析。

2.2 单个API Endpoint的授权

APIM发布工具可对整个API接口进行授权，实现不同角色的人员查看不同的API。但是，在平台运维过程中可能会出现一些特殊的权限管理要求，如API调用对象是一个系统而不是开发者，需分别对API中的Endpoint单独授权。对此，采用XACML实现。

可扩展访问控制标记语言(eXtensible Access Control Markup Language，XACML)定义一种基于属性的声明性细粒度访问控制策略语言、体系结构和处理模型，描述如何根据策略中定义的规则评估访问请求[4]。通过XACML，可描述如何控制某个具体API Endpoint的访问权限，如要求调用者属于某个角色，或角色名符合某个表达式等。

在身份信息服务中，采用内置的XACML编辑器编写相应的业务控制规则，如某个API Endpoint需用户属于特定的角色。在规则发布之后，API网关将在调用API时按对应的规则检查。若符合规则要求，则正常转发请求至后端服务，否则返回Http Code 403(Forbidden)，禁止用户调用该API Endpoint。

XACML编辑器界面见图4。

图4 XACML编辑器界面

2.3 用户信息透传

由于API管理平台具有透明性，在后端接口的服务中，默认无法获取当前调用的用户信息。一般的API对接流程是，API的后端服务不进行身份验证，由API管理平台实现用户管理，对于后端系统而言，所有的接口调用均匿名。在部分接口发布过程中，后端系统明确要求将当前用户的信息传输至后端系统中。对此，需对API管理平台的传输机制进行调整改造。

APIM平台采用OAuth 2.0的身份认证机制，在默认配置下，采用Access Token进行身份信息交互，简单将该Token传输至后端系统中无法满足需求。由此，对身份验证服务的配置进行调整，使其在传输调用信息至后端接口时生成一个包含当前用户信息的JWT Token，附加在Header中。后端接口通过对应的Header字段获取JWT Token，经过解码之后即可获得相关的用户信息。

在APIM平台中，已存在相关的内置类(DefaultClaimsRetriever)实现Token的生成和注入。由于此内置类提供的用户属性较少，不满足业务需求，需自行编程实现其他属性的注入。编写相应的Java代码，继承APIM框架的AbstractJWTGenerator类，通过populateStandardClaims方法实现用户指定属性的注入。相关代码如下：

public Map populateStandardClaims(TokenValidationContext validationContext) throws APIManagementException {

long currentTime = System.currentTimeMillis();

long expireIn = currentTime + getTTL() * 1000;

String applicationId = validationContext.getValidationInfoDTO().getApplicationId();

String tier = validationContext.getValidationInfoDTO().getTier();

String endUserName = validationContext.getValidationInfoDTO().getEndUserName();

String keyType = validationContext.getValidationInfoDTO().getType();

String applicationTier = validationContext.getValidationInfoDTO().getApplicationTier();

if (endUserName.endsWith("@carbon.super")) {

endUserName = endUserName.replace("@carbon.super", "");

}

Map claims = new LinkedHashMap(20);

claims.put("applicationid", applicationId);

claims.put("applicationtier", applicationTier);

claims.put("enduser", endUserName);

claims.put("exp", String.valueOf(expireIn));

claims.put("keytype", keyType);

claims.put("tier", tier);

claims.put("version", validationContext.getVersion());

return claims;

}

2.4 API管理平台监控大屏

在发布工具中，API管理平台提供对API情况的分析，可从API调用次数、API调用者和我的API调用等维度进行统计分析。但是，从API管理平台管理的角度出发，已有的分析数据还不足以反映整个API管理平台的运行情况。

为获取已有API的统计数据和实时调用数据，从系统文档出发，仔细对API管理平台的开发者门户和统计服务提供的相关API进行梳理。针对2个方面的需求，逐一对照整理，形成以下结论：

1) 对于API数量和分类等静态信息，可调用开发者门户的接口；

2) 对于API调用次数和最近调用API等动态信息，可调用统计分析服务的接口。

统计分析服务使用的Siddhi组件采用的是类似大数据的处理方式，通过调用接口提交一个类SQL语句，可根据要求对统计数据进行汇总计算，实现监控大屏的数据源获取。

例如，对于最近调用的API数据，可通过发送以下请求到统计分析服务中来获取。

{

appName: "APIM_ACCESS_SUMMARY",

query: "from ApiLastAccessSummary on lastAccessTime > 1590984000000L select apiName, lastAccessTime order by lastAccessTime DESC;"

}

API管理平台监控大屏采用eCharts作为前端开发组件，采用Node.js开发后端服务，与统计分析和开发者门户等服务进行数据交互。最终的API管理平台监控大屏见图5。

图5 API管理平台监控大屏

通过一系列的功能完善，API管理平台已能满足整个公司内部的API管理需求。通过引入Kafka并结合ELK，使得API管理平台对API调用流水记录的保存能力明显增强，为后续基于流水数据的统计分析奠定了基础。APIM组件提供了完整的API，可实现与其他应用的数据集成。

3 结 语

目前，API管理平台已正式服务于该公司，共发布API 100多个，接入的相关用户和系统超过60个，累积调用次数已接近4 000万次。通过建设API管理平台，各业务系统间的数据和能力交换得以顺利、高效进行，各业务系统的开发效率得到明显提升。通过引入外部的语音识别和文字识别等OpenAPI，业务系统的服务能力也得到明显增强。

API管理平台以微服务架构部署在公司内部的容器云上，平台的可用性得到了较好的保障，为公司内各关键应用提供了高质量的数据服务。得益于APIM的开放性，API管理平台可根据业务需求进行一系列的增强完善。通过对API管理平台各组件的数据流进行分析，并结合行业中的最佳实践，平台的整体服务能力得到了进一步提升。