详解API网关核心功能和API管理扩展

本文将详细讲解API网关的基础概念，使用场景和核心功能，以及基于API网关核心引擎做的API全生命周期管理功能扩展等，最后介绍当前主流的开源API网关引擎。

在微服务架构体系里面，我们一般会使用到微服务网关或叫API网关。

大家都比较清楚，在微服务架构体系下本身是去中心化的架构，通过服务注册中心来实现服务注册发现和消费调用，那么为何又需要使用API网关？

在传统的ESB总线进行服务集成的时候我们就经常谈到一个概念就是位置透明，即需要屏蔽底层业务模块提供API接口服务地址信息，并实现多个微服务API接口的统一出口。即类似设计模式里面经常谈到的门面模式。

如何给API网关一个定义？

简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来，统一接入进行管理，也正是通过统一拦截，就可以通过网关实现对API接口的安全，日志，限流熔断等共性需求。如果再简单说下，通过网关实现了几个关键能力。

内部的微服务对外部访问来说位置透明，外部应用只需和网关交互

统一拦截接口服务，实现安全，日志，限流熔断等需求

从这里，我们就可以看到API网关和传统架构里面的ESB总线是类似的，这些关键能力本身也是ESB服务总线的能力，但是ESB服务总线由于要考虑遗留系统的接入，因此增加了：

大量适配器实现对遗留系统的遗留接口适配，多协议转换能力

进行数据的复制映射，路由等能力

对于两者，我原来做过一个简单的对比，大家可以参考。

这个概念理解后，我们再回到微服务架构里面。

对于微服务架构大家经常说的最多的就是去中心化的架构，认为ESB中心化架构模式已经过时。而实际上经过上面分析你可以看到。在微服务架构里面的API网关仍然是中心化的架构模式，所有的API接口都要经过网关这个点。

非中心化架构-》走微服务里面的服务注册中心进行接口交互

中心化架构-》走网关进行接口服务暴露和共享交互

对于微服务架构里面有无去中心化的架构？当然是有的，即我们常说的微服务模块之间可以通过服务注册中心来实现服务发现查找，服务间的点对点调用即使去中心化的。

如果一个单体拆分为微服务后，完全不需要和外部应用打交道，也不需要共享自己的接口能力，那么这个微服务体系里面就不需要用API网关，仅仅使用服务注册中心即可。通过服务注册中心实现完全的去中心化和接口调用更高的性能。

什么时候需要使用API网关？

如果一个微服务架构下，虽然不会外部的其它应用进行交互和集成，但是整个应用本身存在APP应用端，而APP应用端通过前后端分析开发，同时需要通过互联网访问。本身存在需要一个统一访问API访问入口，同时也需要考虑和内部微服务模块进一步进行安全隔离。

当我们谈到这里的时候，你会发现我们常说的API网关的服务代理或透传能力，实际和我们常说的Ngnix反向代理或路由是一个意思。

如果你仅仅是为了统一API接口的访问出口，并考虑类似DMZ区的安全隔离，那么在你架构前期完全不需要马上实施API网关，直接采用Ngnix进行服务路由代理即可。因为在这种架构下，API接口消费端，提供端全部是一个开发团队开发，各种问题分析排查都相当方便，类似API接口安全访问等也可以通过JWT，Auth2.0等统一实现，而且这个过程也并不复杂。

能力开放或多应用外部集成对API管控治理需要

但是当我们面临是和多个外部应用集成，或者说将自己的API接口服务能力开放给外部多个合作伙伴使用的时候，这个时候对于API接口的管控治理要求自然增加。

即在常规的服务代理路由基础上，需要增加类似负载均衡，安全，日志，限流熔断等各种能力，而且我们不希望这些能力在API接口开发的时候考虑，而是希望这些能力是在API接入到网关的时候统一灵活配置来实现管控。

那么这个时候使用API网关作用就体现出来。

可以看到，API网关更多是一个底层引擎，而要实现完整的API管控，往往还需要配合API全生命周期管理能力。这个完全可以在底层API网关引擎基础上进行扩展开发。

API接口的定义

在定义API接口的时候首先要定义API分组，这个从京东，淘宝等OpenAPI能力开放平台的API文档都可以看到，首先要有API归类分组，然后再定义详细的API。

比如京东开放平台，有商品，店铺，仓储，支付等多个类目，然后各类目下有详细的API的定义。

API的定义包括两个部分，一个是API基本信息定义，一个是详细输入输出定义。

API基本信息仍然是包括了API的编码，API名称，API的分组，API的用途描述，API的缓存，安全等基本控制信息的定义等。还有就是这个API接口的访问路径定义，API接口是Get还是Post方法定义等。

API详细信息主要就是API的输入和输出信息定义。

API的输入参数注意实际有多种形式，一个就是在API访问路径上的路径参数，还有一个就是在访问路径后?参数后面的查询参数信息，还有就是一个完整的Request Body请求参数信息。

比如对于Http Rest查询接口，这类Get方法接口，可以看到并没有Body信息，更多的是通过路径和查询参数定义来完成查询。而对于Post接口往往就涉及到具体的Body信息定义。

但是要注意，为了实现Http Rest接口和SOAP WS接口服务的互相转换，对于SOAP WS查询服务接口在自动转换为Http Rest接口服务的时候实际上仍然为转换为Post方法+Body参数模式。

对于API接口定义，仍需要预留标准的系统级参数部分内容。这部分内容是API网关实现统一标准化管理的基础，不能随便修改和变动。比如京东API平台预留的API名称，方法，版本，Token，APP_Key，Date等都是使用系统级别的参数定义，是每一个接口API暴露后都需要增加的参数头信息。

API快速开发的支持

在API接口服务定义完成后，一方面是可以通过类似WADL或RAML等标准的Rest接口定义规范文件，另外一个就是需要提供客户端和服务端的开发框架代码。

在这个基础上，还可以提供完整的示例代码下载，方便开发商或合作伙伴对API接口进行快速开发。开发完成的后端原始服务接口，在注册接入前还可以提供接口服务的模型匹配自校验功能，确认开发的服务完全遵循从上到下方式-》API开发框架生成和API后端服务开发。

对于API接口管理，如果是标准的从顶朝下模式，即在定义了API接口后，实现生成类似WADL或RAML标准接口规范。后端服务基于我们标准的API接口契约进行开发，那么开发完成后就方便快速代理方式接入，在接入过程中就不再有参数映射和转换的问题，否则我们的API接入过程会比较复杂。

API接口服务的注册和接入

API接口定义过程和API接口的注册接入最好分开。

在API接口定义完成后进行API接口服务的注册，即选择具体的后端服务，然后对服务进行接入。同时将后端服务对应到我们在前面定义的API接口代理服务上。注意在前面谈到的API路径定义，方法类型定义，实际上也可以在API接口服务注册和接入的时候来完成。

API接口服务的后续变更发布，还可以考虑和DevOps平台配合并支持灰度发布功能。

反向的后端服务快速接入并发布为API接口服务，即直接对后端已有的API服务进行快速接入，将API后端服务发布为代理服务，在整个接入过程中需要定义API接口名称，API访问路径，API方法类型等信息。在发布为API接口服务后，对于后端服务的API参数信息也需要进行快速导入，以方便在API接口查询中看到详细的接口内容定义。

在将后端业务服务发布为API接口服务的时候，发布的代理服务要自动增加系统级的输入参数信息，这个输入参数最好的方式是在访问路径中进行增加，以减少对已有的后端服务的影响。

API接口在注册和接入完成后，将自动进行服务部署和服务发布，即注册接入完成后的服务可以通过发布的访问路径地址进行访问。

服务接入适配能力

服务注册接入本身分为两个层面，一个是已有服务的注册接入，一个是需要适配后的服务发布。在设计的时候需要考虑到两个方面的需求。

对于已有服务的存代理接入最简单，即只需要提供业务系统的Rest接口服务地址即可，在接入的时候，对相关的日志，安全，流控，负载均衡等策略进行配置，配置完成后即完成服务接入和注册。同时对于路由服务接入需要单独考虑，对于路由服务在接入的时候可以适配到多个原始业务系统的接口服务地址。

服务发布是对原来我们服务适配功能的一个改进，即直接从底向上的进行服务发布，而不需要实现定义服务元数据或模型，制定服务契约格式等，在服务发布完成后再生成相关的基础数据到服务元数据库即可。对于服务发布参考服务适配的能力，我们可以考虑如下场景下的需求。

将一个已有的SOAP WS服务发布和注册为一个Http Rest接口服务。

将一个数据库表，或存储过程发布为一个Http Rest接口服务。

将一个JMS消息接口发布为一个Http Rest接口服务。

将一个JAR包中的API接口方法或函数发布为一个Http Rest接口服务。

对于服务发布而言，如果不仅仅是微服务网关能力，而是一个微服务支撑或微服务快速开发平台的话，还可以提供完整的服务开发和设计能力。即在微服务平台首先定义数据或对象模型，然后将对象模型转换为Http Rest中的资源对象，并发布对应的Get，Post各种Http Rest接口服务。

对应发布的接口服务可以直接在微服务平台上进行拦截，模拟生成相关的输入或输出数据。当然也可以直接将数据模型对象生成到对应的数据库，同时将微服务API接口的实现生成对应的Java代码框架并给出参考实现。而我们剩余的工作，仅仅是填充代码逻辑即可。通过这种方式可以极大的提高我们进行微服务架构开发的速度。

API接口在线模拟测试功能

这个功能参考当前的OpenAPI能力开放平台的做法来实现即可。即对于已经发布完成的API接口服务，提供在线测试工具进行在线测试。同时对接口服务调用的输入参数进行结构化展示，方便用户对测试需要的各种参数进行输入。在输入完成后形成完整的提交参数完整字符串。通过测试，可以返回最终的模拟调用返回结果字符串信息。

同样，这里可以采用Swagger工具来完成，Swagger不仅仅是API接口的定义，接口文档的生成，同时还可以根据可以接口定义，自动生成接口测试用例，对接口进行测试工作。我们也很容易将Swagger能力整合都API网关的管理平台中。

API接口查询功能

对于API接口查询功能也是一个标准的功能，实际上可以考虑将查询功能和API接口服务的分类浏览分开。对于API接口的分类浏览参考开放平台的API接口文档做法来实现接口。对于API接口查询，即可以设置不同的动态查询条件，对API接口进行查询，返回结果集。对于查询到的API接口清单列表，可以点击详细进入到API接口详细的输入和输出信息查看界面。

API状态管理功能

对于已经注册和发布的API接口可以对其状态进行管理。其中主要的状态包括了待发布，上线，暂停，下线废弃等几种关键状态。对于API状态本身还需要和后续的API监控管理结合，能够通过API性能监控动态的调整API接口的状态。比如在API触发熔断后，自动对API接口状态调整为暂停。

API版本管理能力

对于API需要启用版本管理能力。当前一些API接口服务实现方法会在路径参数中增加API版本信息，以确定究竟访问哪个版本。但是由于不同的API版本可能存在返回的结果集的数据结构不一样的问题，因此对于这种场景需要针对该API定义不同的大版本，不同的大版本实际上对应不同的后端原始服务。

在这里我们介绍下当前主流的一些API网关功能供参考。

首先我们来看下阿里云提供的API网关产品的功能介绍：

API 网关（API Gateway），是提供API托管服务，涵盖API发布、管理、运维、售卖的全生命周期管理。辅助用户简单、快速、低成本、低风险的实现微服务聚合、前后端分离、系统集成，向合作伙伴、开发者开放功能和数据。

阿里提供的API网关提供的关键功能，参考产品本身的功能文档说明，主要如下：

API生命周期管理

支持包括API注册和接入发布、API测试、API下线等生命周期管理功能。支持API日常管理、API版本管理、API快速回滚等维护功能。基本需要覆盖API管理全生命周期。

全面的安全防护

支持多种认证方式，支持HMAC（SHA-1，SHA-256）算法签名。支持HTTPS协议，支持SSL加密。防攻击、防注入、请求防重放、请求防篡改。（没看到是否支持Auth2.0和具体的Token验证机制）

灵活的权限控制

用户以APP作为请求API的身份，网关支持针对APP的权限控制。只有已经获得授权的APP才能请求相应的API。API提供者可以将调用某个API的权限主动授予给某个APP。若 API上架到 API 市场，购买者可以将已购买的API授权给自己的APP。(没看到是否基于IP进行控制，还是基于Token进行控制，即对于消费方分配独立的Token信息)

精准的流量控制

流量控制可以用于管控API的被访问频率、APP的请求频率、用户的请求频率。流量控制的时间单位可以是分钟、小时、天。支持流控例外，允许设置特殊的APP或者用户。（流量控制只支持服务运行频率，没看到可以基于数据量进行流控）

请求校验

支持参数类型、参数值（范围、枚举、正则、Json Schema）校验，无效校验会被API网关直接拒绝，以减少无效请求对后端造成的资源浪费，大幅降低后端服务的处理成本。（这个功能实际有一定的用处，并不会牺牲太多的性能，但是会实现一些简单的参数完整性校验能力。）

数据转换

通过配置映射规则，实现前、后端数据翻译。支持前端请求的数据转换。支持返回结果的数据转换。(暂时不清楚数据转换功能能够实现的能力）

监控报警

提供可视化的API实时监控，包括：调用量、流量大小、响应时间、错误率，在陆续增加维度。支持历史情况查询，以便统筹分析。可配置预警方式（短信、Email），订阅预警信息，以便实时掌握API运行情况。

自动工具

自动生成API文档，可供在线查看。API网关提供多种语言SDK的示例。降低API的运维成本。提供可视化的界面调试工具，快速测试，快速上线。(当前网上也有不少的API接口文档自动生成工具可选）

API市场

可将API上架到API市场，供更多开发者采购和使用。

从整个功能的介绍可以看到对于API的全生命周期管理（注册，接入，代理，路由，负载均衡），安全，权限，流量控制，监控和告警等是所有API网关都必须具备的功能。而对于API市场，API文档自动生成，请求的参数校验，数据的转换等则可以看做是扩展功能。

对于API市场往往是一个重要的扩展能力，即对于API接口服务可以作为商品一样进行订购和使用，并根据相应的调用次数，调用的数据量等条件进行计费处理。这我们我们说的PaaS平台的服务层能力作为产品和服务发布，能够进行订购生产订单，能够进行计费等完全是一个道理。

对于公有云上API网关存在的背景说明

对于类似亚马逊，华为云，阿里云等公有云上为何要提供API网关类产品，其关键点还是在于一个企业如果内部的主动业务应用和系统都迁移到公有云后，那么当企业需要将内部多个业务系统的共享或发布给外部使用的时候如何做？这个时候必须要有一个API网关，来进行能力的统一发布，最基本是提供统一的服务目录访问，更加重要的是实现统一的安全管理，授权，服务日志监控预警能力。

因此一个企业迁移到公有云后，只要存在内部多业务系统，多组件都需要发布API接口能力给外部使用的时候，一定存在API网关的应用场景。

来源：银行科技研究社