一种智能交通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网关同时支持灰度测试，分布式部署管理。

为实现上述目的，本申请第一方面提供了一种智能交通API网关，用于 连接智能交通的API服务器和智能交通客户端；所述智能交通API网关包括：

网关服务模块，用于传递所述智能交通客户端与所述API服务器之间的 交互数据；网关配置存储模块，用于存储网关配置信息；网关管理模块，用 于接收API服务器发送的请求信息，并从请求信息中获取到API服务器的网 关配置信息，并变更网关配置存储模块中API服务器的网关配置信息；网关 事件模块，从所述网关配置存储模块读取所述网关配置信息，并根据所述网 关配置信息控制所述网关服务模块的重启，完成所述智能交通API网关的配 置管理。

优选的，所述网关管理模块还用于在接收到API服务器发送的请求信息 后，向所述API服务器返回消息。

所述网关还包括：

网关消息队列模块，用于接收所述网关管理模块发布的网关配置变化信 息，并将其加入消息队列；

所述网关管理模块还用于在接收到API服务器发送的请求信息后，向所 述网关消息队列模块发布网关配置变化信息

所述网关事件模块还用于实时从所述网关消息队列模块中监控所述网关 配置变化信息，并在监控到所述网关配置变化信息后从所述配置存储模块中 读取所述网关配置信息。

优选的，所述请求信息包括注册请求信息和注销请求信息。

优选的，所述网关还包括：负载均衡模块，用于按照设定的规则分布工 作负载至所述API服务器。

本申请第二方面提供一种智能交通业务系统，所述系统包括：

智能交通API网关集群，所述智能交通API网关集群包括至少一个上述 的智能交通API网关，API服务器和智能交通客户端，所述智能交通客户端 通过所述智能交通API网关与所述API服务器通信。

优选的，多个所述智能交通API网关共用一个网关配置存储模块。

优选的，多个所述智能交通API网关共用一个网关消息队列模块。

通过以上技术手段，可以看出本申请具有以下有益效果：

本申请提供的智能交通API网关可以实现同时支持灰度测试，分布式部 署管理的目的。本申请通过在智能交通API网关上增加网关事件模块，网关 事件模块根据网关配置信息对网关服务模块进行启动、关闭或重启操作。智 能交通API网关上增加网关管理模块，在多个网关部署时，可通过网关管理 模块实现统一管理，多网关可同时提供服务，在API服务器比较多时，可实 现有效的管理。

附图说明

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

图1为本申请实施例公开的一种智能交通API网关的功能模块示意图；

图2为本申请实施例公开的一种智能交通API网关集群的功能模块示意 图；

图3为本申请实施例公开的一种智能交通业务系统功能模块示意图；

具体实施方式

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

首先介绍本申请提供的一种智能交通API网关。如图1所示，所述网关 包括：

负载均衡模块，用于按照设定的规则分布工作负载至API服务器，可以 选择将负载平均分布至所有的API服务器上，也可以选择优先在某个API服 务器处理，在负载量超过预设值时将超出预设值的负载转载至其他API服务 器。

网关服务模块，用于根据设置传递所述智能交通客户端与所述API服务 器之间的数据。智能交通客户端发起API请求数据，网关服务模块根据API 请求数据的类型，以及预设规则将该API请求数据转发至相应的API服务器， 并接收API服务器返回的信息处理结果，将该信息处理结果转发至发起该API 请求数据的智能交通客户端。例如，可按照IP地址进行分配转发，将智能交 通客户端的IP为A的API请求数据转发至IP为a的API服务器上；可按照 API请求数据的参数进行转发，即若API请求数据中含有B参数则根据该参 数进行划分对应的API服务器；若API请求数据未触发任意一种预设的转发 规则，则转发至固定的API服务器上。对于API服务器还可以设定权重，根 据权重计算API请求数据发送至该服务器的概率。在本实施例中，网关服务 模块采用基于nginx的负载均衡和反向代理服务端。

网关管理模块，用于接收所述API服务器发送的请求信息，并从所述API 服务器获取网关配置信息。当需要接入新的API服务器或API服务器配置更 新时，API服务器向网关管理模块发送注册请求信息，网关管理模块将该API 服务器的接口信息以及服务器信息写入网关存储模块中，并向网关消息队列 模块发布网关配置变化信息。同理，当需要卸载某API服务器时，API服务 器发送注销请求信息至网关管理模块，网关管理模块将该API服务器的接口 信息以及服务器信息从网关存储模块中删除，然后网关管理模块向网关消息 队列模块发布网关配置变化信息至网关消息队列模块。本实施例中，网关管 理模块采用的是web服务。

网关配置存储模块，用于存储上述网关配置信息。网关配置存储模块存 储着可更新的网关配置信息，当有新的API服务器接入或API服务器配置更 新以及需要卸载某API服务器时，网关配置信息发生变化，更新后的网关配 置信息存储在网关配置存储模块。

网关事件模块，用于根据所述网关配置信息控制所述网关服务模块的启 动、关闭或重启。智能交通API网关启动时，网关事件模块先从网关配置存 储模块读取网关配置信息，使用该网关配置信息生成一份网关服务模块的配 置文件，根据该配置文件启动网关服务模块。网关事件模块在启动后向网关 消息队列模块订阅网关信息，实时从所述网关消息队列模块中监控所述网关 配置变化信息，并在监控到网关配置变化信息后从配置存储模块中读取网关 配置信息，使用该网关配置信息生成一份新的网关服务模块的配置文件，根 据该配置文件重新启动网关服务模块。

网关消息队列模块，用于接收所述网关管理模块发布的网关配置变化信 息，并将其加入消息队列。

由于网关管理模块在网关配置信息发生变化后将变化后的网关配置信息 发送至网关配置存储模块，并同时发送网关配置变化信息至网关消息队列模 块，网关事件模块实时从所述网关消息队列模块中监控所述网关配置变化信 息，在监控到所述网关配置变化信息后从所述配置存储模块中读取所述网关 配置信息，并根据该网关配置信息重新启动网关服务模块，从而实现在系统 API网关配置发生变化后及时更新系统配置，无需人工操作重启。

下面介绍本申请提供的一种智能交通业务系统，如图3所示智能交通业 务系统功能模块示意图。所述系统包括：智能交通API网关集群，API服务 器集群和智能交通客户端；该智能交通API网关集群包括至少一个智能交通 API网关，该API服务器集群包括至少一个API服务器；该智能交通客户端 通过该智能交通API网关与该API服务器连接。所述智能交通客户端可以为 手机客户端或浏览器以及其他程序调用需求。

在实际应用中，智能交通API网关通常采用多个，即采用智能交通API 网关集群的方式，在智能交通API网关集群中，如图2所示的一种能交通API 网关集群的功能模块示意图，多个智能交通API网关可共用一个网关配置存 储模块和网关消息队列模块，当一个智能交通API网关的配置发生变化时， 所有的智能交通API网关均可接收到网关配置变化的信息，并根据变化后的 网关配置信息重新启动智能交通API网关集群中的所有智能交通API网关。

为了更好的理解本申请的技术方案，下面以智能交通API网关应用于停 车场进行灰度测试来说明本申请具体应用。

停车场应用已有生产环境的版本A正常运行，此时开发了一个新的版本 B。

测试部门进行测试时，将安装好B版本的API测试服务器向智能交通API 服务网关的网关管理模块发送注册请求信息，注册时指定只有参数park_id值 为0000的API请求数据才会转发到B版本的API测试服务器上，其他的API 请求数据转发到A版本的API服务器上。停车场API网关在接收到API服务 器发送的注册请求信息后，整个智能交通API服务网关的网关配置发生变化， 停车场API服务网关根据新的网关配置无缝重启，无需人工重启也不影响系 统的正常使用。由测试人员对此功能进行测试。(此处假设测试环境的停车 场id为0000)，此时只有测试人员使用的是B版本，其他用户使用的还是A 版本。

当测试人员认为此版本趋于稳定时，计划在公司内部进行大范围alpha测 试，则API测试服务器向网关管理模块再发起一个注册请求信息，停车场API 网关在接收到API服务器发送的注册请求信息后，整个智能交通API服务网 关的网关配置再次发生变化，停车场API服务网关根据新的网关配置再次无 缝重启，完成停车场API网关配置管理。此次注册时指定来源ip为公司的出 口ip的，都转发到此API测试服务器，此时通过公司内部人员使用是B版本， 其他用户使用的还是A版本。

当内部alpha测试无其他问题时，开始进行bata测试，可设定停车场id 为123456的停车场可以用配合bata测试，那么此时API测试服务器再次向智 能交通API网关的网关管理模块发起注册，停车场API网关在接收到API服 务器发送的注册请求信息后，整个智能交通API服务网关的网关配置再次发 生变化，停车场API服务网关根据新的网关配置再次无缝重启，完成停车场 API网关配置管理。此次，注册时指定只有参数park_id值为123456的API 请求才会转发到API测试服务器上，此时在停车场id为123456的停车场停车 的用户以及公司内部员工使用的是B版本，其他用户使用的是A版本。

当指定的停车场bata测试无问题时，可逐步扩大范围，对一台或多台A 版本API服务器升级至B版本的API服务器，升级为B版本的API服务器需 向智能交通API网关重新发起注册，再次触发停车场API网关配置管理机制， 停车场API服务网关根据新的网关配置再次无缝重启完成配置的更新。若要 控制接入B版本的停车场比例，注册时指定自身的权重，比如对A版本的服 务器进行升级，指定这两台服务器的总权重为5％，那么此时有5％的停车场 在使用B版本，其他95％的用户继续使用A版本。

在一定比例的灰度测试中，若每个阶段无问题，可逐步提高B版本的用 户接入，比如5％，10％，15％，20％，40％，60％，80％，100％，不断的提 高B版本的比例，直到所有的用户都使用最新的B版本。

在整个灰度发布过程中，若出现重大问题影响用户的正常使用时，随时 可将B版本的API服务器从智能交通API网关上注销，停车场API网关在接 收到API服务器发送的注销请求信息后，整个智能交通API服务网关的网关 配置再次发生变化，不存在B版本的API服务器，停车场API服务网关根据 新的网关配置再次无缝重启，完成停车场API网关配置管理。用户继续使用 A版本的API服务器。

整个停车场API服务网关在网关配置发生变化后，均会根据新的网关配 置无缝重启，无需人工重启也不影响系统的正常使用，可实现对用户的影响 降到最低。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都 是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用 本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易 见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下， 在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例， 而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。