API网关平台的制作方法

本发明涉及网络通信领域，尤其涉及一种api网关平台。

背景技术：

随着api的整体趋势发展，每个历史时代都面临着不同的挑战，架构也随之变化，从最原始的“传输协议通讯”到“简单的接口集成”再到“消息中间件”再到现在的“标准rest”，可以看到api的发展更趋向于简洁、集成、规范化。

api网关是系统边界上提供给外部访问内部接口服务的统一入口，api网关接收客户端的请求，根据一定的策略和路由将该请求转发到相应的后端系统服务上，处理后端服务端返回的结果等。即，api网关负责对整个api资源进行路由代理、性能分配等。

随着客户端上线的功能越来越多，所需调用的api也会越来越多，而且，网关装置对外面对多种不同类型的客户端，不同客户端所传输的数据类型也是不一样的，这就涉及到api网关配置维护的问题。而目前通常的做法为：根据需求对api网关的配置进行人工修改，并且需要每次修改后对api网关进行重启，因此，现有的api网关配置存在难以维护的问题。

技术实现要素：

本发明要解决的技术问题在于，针对现有技术存在的api网关配置难以维护的缺陷，提供一种api网关平台。

本发明解决其技术问题所采用的技术方案是：构造一种api网关平台，包括带有多个功能组件的网关装置，还包括管理中心，而且，

所述管理中心，用于发布与企业用户需求相关的自定义组件；

所述网关装置，用于在接收到终端用户的访问请求后，若根据所述访问请求无法从缓存中获取相应的功能组件，则从所述管理中心中获取相应的自定义组件，并通过自定义类加载器加载所获取的自定义组件，且执行所述自定义组件。

优选地，所述管理中心，还用于接收企业用户对所述功能组件、api进行设置的设置信息。

优选地，还包括监控中心，所述功能组件包括日志记录组件，而且；

所述日志记录组件，用于记录监控日志；

监控中心，用于收集所述网关装置的监控日志，并根据所述监控日志生成相应的报表，和/或，根据所述监控日志判断是否发生异常，并在异常时生成告警信息。

优选地，所述功能组件包括：

认证组件，用于在接收到访问请求后，采用以下认证方式中的至少一种对终端用户的身份进行认证：token、basic、ip地址；

鉴权组件：用于在身份认证通过后，检测所述终端用户是否有权限访问相应的api。

优选地，所述功能组件包括：

流量控制组件，用于判断预设时段内访问请求的次数是否超过阈值，若是，则对新接收的访问请求进行拦截。

优选地，所述功能组件包括：

协议转换组件，用于根据所接收的访问请求，对所述访问请求进行转换。

优选地，所述功能组件包括：

路由组件，用于将转换后的访问请求路由到相应的后端微服务节点。

优选地，所述功能组件包括：

超时熔断组件，用于在所有后端微服务节点都处于繁忙状态时，采用熔断形式阻止外部的访问请求。

优选地，所述功能组件包括：

数据缓存组件，用于在接收到访问请求后，判断所调用的api是否有设置缓存，若是，则直接从缓存中提取数据并将其返回至终端用户。

优选地，所述网关装置的数量为多个，且该api网关平台为分布式api网关平台；而且，

所述管理中心，用于在接收到设置信息后，向集群中的各网关装置发送更新消息；

所述网关装置，用于在收到更新消息时，对相应功能组件进行刷新。

在本发明所提供的技术方案可支持自定义组件，且可在网关装置中动态加载运行，可实现在不中断网关服务的情况下重新加载配置和运行组件。

附图说明

为了更清楚地说明本发明实施例，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。附图中：

图1是本发明api网关平台实施例一的逻辑结构图；

图2是本发明api网关平台实施例二的逻辑结构图；

图3是本发明api网关平台实施例三的逻辑结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1是本发明api网关平台实施例一的逻辑结构图，该实施例的api网关平台包括：网关装置100及管理中心200，其中，网关装置100包括有多个功能组件。而且，管理中心200用于发布与企业用户需求相关的自定义组件，网关装置100用于在接收到访问请求后，若根据访问请求无法从缓存中获取相应的功能组件，则从管理中心200中获取相应的自定义组件，并通过自定义类加载器加载所获取的自定义组件，且执行自定义组件。。

关于该实施例，需说明的是，jvm中class是通过类加载器、全限定名来唯一标识的，组件以jar包的形式发布，但相同组件的多个版本的入口类名需要保持不变，因此要实现组件的热插拔和多版本并存就需要自定义类加载器来实现。在一个具体例子中，网关装置接收到访问请求(api调用请求)后根据请求参数从缓存里拿到api配置的组件列表，然后再逐一参数从缓存里获取组件对应的类实例，如果找不到则尝试通过自定义类加载器载入jar包，并初始化组件实例及缓存。另外，自定义类加载器可直接需要继承至urlclassloader，另外必须指定其父类加载器为执行器的加载器，否则组件没法引用网关的其它类。

通过该实施例的技术方案，网关装置中除产品内置的功能组件外，企业用户可根据实际需求自定义组件，输出成jar包，并通过管理中心上传发布。网关装置在接收到终端用户的访问请求后，可从管理中心获取相应的自定义组件，并加载、执行该自定义组件，实现组件的热插拔和多版本并存，而且，这种自定义组件的扩展方式无需重启网关装置。

进一步地，在一个可选实施例中，管理中心200还用于接收企业用户对功能组件、api进行设置的设置信息，例如，可通过提供统一的管理界面使用户对组件、api、系统的基础信息进行设置和维护。

图2是本发明api网关平台实施例二的逻辑结构图，该实施例的api网关平台相比图1所示的实施例，所不同的仅是，还进一步包括监控中心300，而且，网关装置的功能组件包括有日志记录组件，该日志记录组件用于记录监控日志，包括访问日志、行为日志。监控中心300用于收集网关装置的监控日志，并根据监控日志生成相应的报表，和/或，根据监控日志判断是否发生异常，并在异常时生成告警信息，从而实现系统的性能监控，或者供后期查询使用。

图3是本发明api网关平台实施例三的逻辑结构图，该实施例的api网关平台包括：网关装置100、管理中心200及监控中心300，其中，网关装置100负责终端用户的访问请求，调度、加载和执行组件，将请求路由到后端业务集群中的相应微服务节点，处理后端微服务节点返回的结果等。管理中心200提供统一的管理界面，以供用户进行api、功能组件、系统基础信息的设置及维护，具体包括：api管理设置、api分组管理设置、流量控制策略设置、文档生成设置、协议转换设置、日志记录设置、缓存设置、加解密设置、服务管理设置、告警设置等。监控中心300负责收集监控日志，进行趋势分析，，生成各种运维报告，自动告警等。

而且，网关装置100包括有的功能组件具体有：认证组件101、鉴权组件102、流量控制组件103、路由组件104、协议转换组件105、超时熔断组件106、数据缓存组件107、服务编排组件108、服务注册/发现组件109、负载均衡组件110、版本灰度/发布组件111、日志记录组件112。其中：

认证组件101用于在接收到访问请求后，采用以下认证方式中的至少一种对终端用户的身份进行认证：token、basic、ip地址。只有通过认证的终端用户才能进一步访问网关暴露的服务。鉴权组件102用于在身份认证通过后，检测终端用户是否有权限访问相应的api，只有在鉴权通过时才转给后面的服务。通过这种多维度的认证和授权策略，可保证数据传输的安全性。

流量控制组件103用于判断预设时段内访问请求的次数是否超过阈值，若是，则对新接收的访问请求进行拦截。针对目前存在的当有部分无效流量直接流入后端服务中时，通常由后端服务来判断流量是否有效而导致的后端服务压力大、易出现服务崩溃、影响用户正常体验的缺陷，该实施例在网关装置中配置了流量阈值，例如，每秒、每分、每小时的请求次数限制，当流量超过阈值，新来的请求会被网关拦截，确保后端服务可正常运行。

负载均衡组件110用于根据后端微服务节点的负荷情况进行动态的负载均衡调节。超时熔断组件106用于在所有后端微服务节点都处于繁忙状态时，采用熔断形式阻止外部的访问请求。在该实施例中，一旦内部的某个微服务实例负载很高，甚至不能及时响应，则负载均衡组件110就通过负载均衡策略减少或停止向这个微服务实例转发请求。当所有的微服务实例都处理不过来时，超时熔断组件106还可以采用熔断或限流的方式来阻止外部请求，以保证整个系统的可用性。

协议转换组件105用于根据所接收的访问请求，对访问请求进行转换。在该实施例中，由于网关装置对外是面向多种不同的用户终端的，例如，web、app、第三方合作伙伴等，而不同的终端所传输的数据类型可能是不一样的。因此，需要协议转换组件105具备数据转换功能，以将不同终端传输进来的数据转换成同一种类型再进行转发，这样便兼容了这些请求的多样性，保证了微服务的灵活性。另外，由于网关对外统一暴露的是rest服务，后端微服务又是多样的，开发人员也需要根据后端微服务节点的接口类型开发不同的协议转换组件。

路由组件104用于将转换后的访问请求路由到相应的后端微服务节点。在该实施例中，所有的全部请求都先发到网关装置，然后由路由组件104根据不同的请求去路由到不同的微服务节点上，例如，可以根据路径来转发，也可根据参数来转发。而且，由于内部微服务节点也会随着业务调整而变更，增加或删除节点，此时，路由组件104可以与服务注册/发现组件109协同工作，保证将外部请求转发到最合适的微服务节点上。

数据缓存组件107用于在接收到访问请求后，判断所调用的api是否有设置缓存，若是，则直接从缓存中提取数据并将其返回至终端用户。在该实施例中，对于查询类型且数据变化不频繁的api，适当的缓存设置可以有效降低后端微服务节点的压力，具体地，管理人员可根据api的特点配置是否需要缓存，当网关装置接收到访问请求后会判断所需调用的api是否有设置缓存，如果有且缓存未过期，则直接从缓存提取数据并返回给终端用户，如果已经过期则通过路由组件104访问后端微服务后，再更新缓存。这种通过对api、功能组件等关键内容进行数据缓存的方式，可使网关装置在运行时尽可能减小对数据库(db)的访问，同时，由于运行过程不写磁盘io，避免了磁盘io性能影响网关吞吐。

进一步地，在一个可选实施例中，网关装置的数量为多个，且该api网关平台为分布式api网关平台，该架构的特点是：分布式缓存基于redis，数据库基于mysql，分布式配置基于zookeeper。而且，管理中心200用于在接收到设置信息后，向集群中的各网关装置发送更新消息；网关装置100用于在收到更新消息时，对相应功能组件进行刷新。在该实施例中，当在管理中心对api或功能组件进行配置调整后，可采用zookeeper集群数据同步机制将配置信息及时更新到各网关装置，具体地，管理中心往消息中心发布一条消息，各网关装置收到消息后刷新缓存数据。另外，网关装置在启动时也可向zookeeper节点进行注册，以被动更新配置信息。

另外，本发明的api网关平台还具有docker容器华支持，拆分网关装置、管理服务、第三方中间件依赖等镜像，便于灵活扩容。

该实施例的技术方案具有以下有益效果：

1.降低后端微服务相互调用链的复杂度

后端需求采用微服务的方式的进行部署，部分需求可能涉及到用户权限的鉴定。但是现有的权限限制使用本地函数的方式进行鉴定，包括push服务、开源图库都是通过http协议的方式请求原有后端接口来实现获取用户信息的，随着后期的相互调用的服务越来越多，会造成服务之间依赖性过强、还需要维护服务之间错综复杂的依赖关系，这样的解决方案显然是不明智的。每次更新其它的模块的时候，都需要关注服务之间的调用链，造成部署、更新服务复杂度的提升。而本方案通过在网关装置内进行认证、鉴权，通过后才转发至后端微服务节点，因此，可大大降低后端微服务相互调用链的复杂度。

2.降低因为后端服务更新带来的问题

当对某个微服务使用新的技术或者重构逻辑时，按现有的架构，该微服务在测试环境通过后就可以发布正式环境了，但由于正式环境与测试环境的不同，例如，用户行为是未知的、流量大小以及数据都是不统一的。在这些因素下虽然测试环境通过了，但正式环境依然可能会带来部分未知的问题。而本方案通过在网关装置中设置协议转换组件、流量控制组件等，且可通过管理中心对该组件进行配置维护，可降低后端服务更新带来的问题。

3.降低维护api复杂度

随着应用上线的功能越来越多，api会越来越多，也就需要维护更多的api。而本方案可在管理中心中对api进行管理，降低了维护api复杂度。

4.设置统一的监控点

后端微服务越来越多时需要自行根据服务实现方式来部署监控api，现有监控方式是后端服务、push服务、开源图库等这些是分开部署的，每个服务都是需要自行在服务内部进行监控状态、展示状态，但这样随着后端服务越来越多时操作会越来越复杂。而本方案通过统一设置监控中心，并根据业务名称进行监控请求状态、处理时间。

5.减轻后端服务压力

针对现有方式中有部分无效流量会直接流入后端服务中，由后端服务来判断流量是否有效，这样会加大后端服务的压力，甚至导致后端服务崩溃，影响用户正常体验。而本方案通过在网关装置中设置流量控制组件、超时熔断组件、负载均衡组件来减轻后端服务压力，提升用户体验。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何纂改、等同替换、改进等，均应包含在本发明的权利要求范围之内。