一种API网关迁移方法及系统与流程

【技术领域】

本发明涉及api网关领域，具体涉及api网关迁移方法及系统。

背景技术：

随着公司的发展，老的网关系统和认证服务器的模型可能会出现无法继续迭代的情况，所以开发人员需要重新开发新的网关系统和认证服务器，此时，则需要将老系统的应用迁移到新系统，由于新系统在设计之初，没有参考老系统的模型，所以要完全兼容原来的请求跟响应存在困难。如果不兼容的话，就要推动老系统的应用进行不兼容改造。

网关迁移本质上也是一次系统的升级。一般来说，升级分为兼容性的升级和不兼容性升级，大部分系统选择兼容性的升级，兼容性升级的劣势在于，兼容性升级会带来很强的历史包袱，因为模型被老系统的模型限制，且需要照顾到原来系统的很多特殊逻辑，很难得到一个新的清晰的领域模型。不兼容升级的方案，优势是可以重新设计整个模型，让新系统更加清晰，劣势是推动成本非常高。

技术实现要素：

为解决前述问题，本发明提供了一种api网关迁移方法，解决新老网关系统的迁移成本问题。

为了达到上述目的，本发明采用如下技术方案：

一种api网关迁移方法，包括如下步骤：

app请求认证代理获取凭证；

认证代理判断app是否需要灰度配置，若是，同时请求新的认证服务器和老的认证服务器，创建新老凭证的映射，返回第一凭证，若否，则请求老的认证服务器，返回第二凭证；

app获取凭证后，请求网关代理；

网关代理根据灰度配置以及第一凭证或第二凭证，判断是否需要请求新网关，若是，则将请求转给新网关，拿到新网关的返回结果，返回给app，若否，则将请求转给老网关，拿到老网关的返回结果，返回给app。

可选的，认证代理读取配置中心的灰度规则判断app是否需要灰度配置，如果app在灰度名单中，同时请求新的认证服务器和老的认证服务器，创建的新老凭证的映射保存在共享存储中；如果app不在灰度名单中，则请求老的认证服务器。

可选的，共享存储使用开源的redis，以所述第一凭证为key。

可选的，所述第一凭证的位数和所述第二凭证的位数不同，网关代理从共享存储中获取新老凭证的映射，并从配置中心获取灰度配置。

可选的，新网关接收到请求后，执行新网关的核心处理流程，在核心处理流程的特定流程节点，判断该接口是否有插件，如果有，加载并运行插件，如果没有，则回到核心处理流程。

可选的，加载插件的逻辑包括本地模式和远程模式。

可选的，在本地模式下，插件不进行预加载和编译。

可选的，在远程模式下，插件存放在配置中心，插件进行预加载和编译。

可选的，在远程模式下，插件加载并运行插件的具体步骤包括：

app启动；读取配置中心的插件脚本并编译；注册变更回调，回调收到来自配置中心的变更通知后，重新获取插件脚本，编译后放在内存中。

本发明具有如下有益效果：

本发明提供了一个新老网关系统完全兼容的技术方案，不需要对老系统的应用进行不兼容改造，并且根据灰度配置判断是否请求新的认证服务器，卸下了现有技术中兼容性升级带来的沉重的历史包袱，提供了丰富的灰度特性来保证迁移的可靠性，有效降低了新老网关系统的迁移成本。

此外，本发明还提供了一种api网关迁移系统，包括：

认证代理，用以判断app是否需要灰度配置，若是，同时请求新的认证服务器和老的认证服务器，创建新老凭证的映射，返回第一凭证，若否，则请求老的认证服务器，返回第二凭证；

网关代理，包括新网关和老网关；

配置中心，供认证代理读取灰度规则，以判断app是否需要灰度配置，供网关代理获取灰度配置，存放插件脚本；

共享存储，存放新老凭证的映射，使用开源的redis，以所述第二凭证为key。

本发明所提供的api网关迁移系统的有益效果与前述api网关迁移方法的有益效果推理过程相似，在此不再赘述。

本发明的这些特点和优点将会在下面的具体实施方式以及附图中进行详细的揭露。本发明最佳的实施方式或手段将结合附图来详尽表现，但并非是对本发明技术方案的限制。另外，在每个下文和附图中出现的这些特征、要素和组件是具有多个，并且为了表示方便而标记了不同的符号或数字，但均表示相同或相似构造或功能的部件。

【附图说明】

下面结合附图对本发明作进一步说明：

图1为本发明实施例一的流程图；

图2为本发明实施例一中代理认证进行灰度控制的示意图；

图3为本发明实施例一中网关代理进行灰度控制的示意图；

图4为本发明实施例一插件运行的流程图；

图5为本发明实施例一插件加载的流程图。

【具体实施方式】

下面结合本发明实施例的附图对本发明实施例的技术方案进行解释和说明，但下述实施例仅为本发明的优选实施例，并非全部。基于实施方式中的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得其他实施例，都属于本发明的保护范围。

在本说明书中引用的“一个实施例”或“实例”或“例子”意指结合实施例本身描述的特定特征、结构或特性可被包括在本专利公开的至少一个实施例中。短语“在一个实施例中”在说明书中的各位置的出现不必都是指同一个实施例。

实施例：

如图1所示，本实施例提供一种api网关迁移方法，过代理的方式来实现流量的转发，将老网关的流量代理到新网关，并且通过配置中心来进行灰度控制，保证迁移过程的可靠性，通过插件的方式来实现兼容性，具体包括如下步骤：

app请求认证代理获取凭证。

如图2所示，认证代理读取配置中心的灰度规则，判断app是否需要灰度配置，如果app在灰度名单中，则需要灰度配置，同时请求新的认证服务器和老的认证服务器，创建新老凭证的映射，保存在共享存储中，供网关代理查询使用。新老凭证的映射以后，返回第一凭证。共享存储使用开源的redis，以第一凭证为key；如果app不在灰度名单中，则不需要灰度配置，请求老的认证服务器，返回第二凭证。

app获取凭证后，请求网关代理。

如图3所示，第一凭证的位数和第二凭证的位数不同，网关代理从配置中心获取灰度配置，根据灰度配置以及第一凭证或第二凭证，判断是否需要请求新网关，若是，则将请求转给新网关，网关代理从共享存储中获取新老凭证的映射，拿到新网关的返回结果，返回给app，若否，则将请求转给老网关，拿到老网关的返回结果，返回给app。

如图4所示，新网关接收到请求后，执行新网关的核心处理流程，在核心处理流程的特定流程节点，判断该接口是否有插件，如果有，加载并运行插件，如果没有，则回到核心处理流程。插件是一段动态编译的脚本，理论上可以兼容任意的特殊逻辑。

加载插件的逻辑包括本地模式和远程模式，在本地模式下，插件不进行预加载和编译，这样能够让插件的改动实时生效，加快调试的效率；在远程模式下，插件存放在配置中心，插件进行预加载和编译。因为配置中心有很好的预览功能，并且具有动态下发功能，因此在远端模式下，插件是预加载的。

如图5所示，在远程模式下，插件加载并运行插件的具体步骤包括：

app启动；读取配置中心的插件脚本并编译；注册变更回调，回调收到来自配置中心的变更通知后，重新获取插件脚本，编译后放在内存中。

本实施例提供了一个新老网关系统完全兼容的技术方案，不需要对老系统的应用进行不兼容改造，并且根据灰度配置判断是否请求新的认证服务器，卸下了现有技术中兼容性升级带来的沉重的历史包袱，提供了丰富的灰度特性来保证迁移的可靠性，有效降低了新老网关系统的迁移成本。

实施例二

本实施例提供了一种api网关迁移系统，应用于实施例一的api网关迁移方法，包括：

认证代理，用以判断app是否需要灰度配置，若是，同时请求新的认证服务器和老的认证服务器，创建新老凭证的映射，返回第一凭证，若否，则请求老的认证服务器，返回第二凭证；

网关代理，包括新网关和老网关；

配置中心，供认证代理读取灰度规则，以判断app是否需要灰度配置，供网关代理获取灰度配置，存放插件脚本；

共享存储，存放新老凭证的映射，使用开源的redis，以第二凭证为key。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，熟悉该本领域的技术人员应该明白本发明包括但不限于附图和上面具体实施方式中描述的内容。任何不偏离本发明的功能和结构原理的修改都将包括在权利要求书的范围中。