CN112965700A - 基于路由的微服务处理方法、装置、计算机设备和介质 - Google Patents

Abstract

本申请涉及一种基于路由的微服务处理方法、装置、计算机设备和介质。所述方法包括：启动共用基线微服务；接收待处理微服务注册请求，并根据所述注册请求注册对应的待处理微服务，注册完成的待处理微服务用于配置数据库中的路由配置信息；接收终端发送的微服务处理请求，所述微服务处理请求携带有微服务标识；获取路由配置信息，根据所述路由配置信息在所述共用基线微服务中确定与所述微服务标识对应的待调用微服务；调用所述待调用微服务得到处理结果。采用本方法能够减少本地资源占用。

Description

基于路由的微服务处理方法、装置、计算机设备和介质

技术领域

本申请涉及微服务技术领域，特别是涉及一种基于路由的微服务处理方法、装置、计算机设备和介质。

背景技术

随着微服务应用技术的发展，出现了网关等组件，网关是具体核心业务服务的流量入口，相比具体实现业务的***服务来说它是一个边缘服务，主要提供动态路由、监控、弹性和安全性等功能。在分布式的微服务***中，***被拆为了多套***，通过网关来对用户的请求进行路由，转发到具体的后台服务***中，为网关服务的提供动态路由配置的能力可以大幅提升开发、测试能力，缩减配套成本。

传统技术中，在开发或者时测试微服务的时候，需要在本地部署开发或者测试环境，该开发或者测试环境需要将与待开发的微服务存在依赖关系的微服务均进行部署，从而使得开发或者测试的时候本地资源占用量大。

发明内容

基于此，有必要针对上述技术问题，提供一种能够实现减少本地资源占用的基于路由的微服务处理方法、装置、计算机设备和介质。

一种基于路由的微服务处理方法，所述方法包括：

启动共用基线微服务；

接收待处理微服务注册请求，并根据所述注册请求注册对应的待处理微服务，注册完成的待处理微服务用于配置数据库中的路由配置信息；

接收终端发送的微服务处理请求，所述微服务处理请求携带有微服务标识；

获取路由配置信息，根据所述路由配置信息在所述共用基线微服务中确定与所述微服务标识对应的待调用微服务；

调用所述待调用微服务得到处理结果。

在其中一个实施例中，所述待处理微服务为正在开发的微服务；所述根据所述路由配置信息在所述共用基线微服务中确定与所述微服务标识对应的待调用微服务之前，还包括：

判断所述微服务标识对应的微服务是否为正在开发的微服务；

当所述微服务标识对应的微服务为正在开发的微服务，则根据所述路由配置信息获取正在开发的微服务的微服务标识对应的正在开发的微服务。

在其中一个实施例中，所述待处理微服务为测试微服务；所述根据所述路由配置信息在所述共用基线微服务中确定与所述微服务标识对应的待调用微服务，包括：

根据所述路由配置信息调用对应的测试环境下的与所述微服务标识对应的测试微服务，其中所述测试环境包括多个，且至少一个测试环境中启动所有的共用基线微服务，剩余的测试环境仅启动对应的测试微服务。

在其中一个实施例中，所述剩余的测试环境所启动的对应的测试微服务相同或不相同。

在其中一个实施例中，所述方法还包括：

监听是否存在预设应用事件；

当存在预设应用事件时，则获取配置文件中的初始路由信息和数据库中的动态路由信息；

根据所述初始路由信息和所述动态路由信息进行路由配置。

在其中一个实施例中，所述获取配置文件中的初始路由信息和数据库中的动态路由信息，包括：

通过扩展路由***调用简单路由***中的预设方法；

通过简单路由***中的预设方法调用所述扩展路由***的对应的规则；

根据所调用的规则查找配置文件中的初始路由信息和数据库中的动态路由信息。

在其中一个实施例中，所述预设应用事件的生成方式包括：

接收动态路由信息，并将所述动态路由信息存储至数据库中，所述动态路由信息是根据注册完成的待处理微服务生成的；

接收针对所述动态路由信息的配置触发请求；

根据所述配置触发请求生成预设应用事件。

一种基于路由的微服务处理装置，所述装置包括：

启动模块，用于启动共用基线微服务；

注册模块，用于接收待处理微服务注册请求，并根据所述注册请求注册对应的待处理微服务，注册完成的待处理微服务用于配置数据库中的路由配置信息；

接收模块，用于接收终端发送的微服务处理请求，所述微服务处理请求携带有微服务标识；

路由模块，用于获取路由配置信息，根据所述路由配置信息在所述共用基线微服务中确定与所述微服务标识对应的待调用微服务；

处理模块，用于调用所述待调用微服务得到处理结果。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述任一项所述的方法的步骤。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的方法的步骤。

上述基于路由的微服务处理方法、装置、计算机设备和介质，启动共用基线服务，并且将待处理微服务进行注册，以重新配置路由配置信息，这样当接收到终端发送的微服务处理请求时，根据路由配置信息即可以在共用基线微服务中确定对应的待调用微服务，不需要在本地启动所需要的所有的微服务，减少了本地的资源占用。

附图说明

图1为一个实施例中基于路由的微服务处理方法的流程示意图；

图2为一个实施例中的应用开发调试方法的应用环境图；

图3为一个实施例中的应用测试方法的应用环境图；

图4为一个实施例中的动态路由配置方法的流程图；

图5为一个实施例中的动态路由配置方法的流程框图；

图6为图4所示实施例中步骤S404的流程图；

图7为一个实施例中的业务请求处理流程图；

图8为一个实施例中的路由刷新过程的流程图；

图9为一个实施例中的动态路由配置方法的时序图；

图10为一个实施例中基于路由的微服务处理装置的结构框图；

图11为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

在一个实施例中，如图1所示，提供了一种基于路由的微服务处理方法，本实施例以该方法应用于本地服务平台进行举例说明，可以理解的是，该方法也可以应用于服务器或终端，还可以应用于包括终端和服务器的***，并通过终端和服务器的交互实现。本实施例中，该方法包括以下步骤：

S102：启动共用基线微服务。

具体地，共用基线微服务是指在进行微服务处理时，所启动的一包含当前所有微服务的处理环境，其中该处理环境部署在本地服务平台，以保证每个微服务至少在处理环境中正常运行。

其中需要说明的是该共用基线微服务是用于处理微服务的所有的终端均可以访问的，从而实现对该些共用基线微服务的调用。

S104：接收待处理微服务注册请求，并根据注册请求注册对应的待处理微服务，注册完成的待处理微服务用于配置数据库中的路由配置信息。

具体地，待处理微服务是指当前正在处理的微服务，例如当前正在开发的微服务，其可能在开发的调试阶段，还可以是当前正在测试的微服务，其中测试的微服务可以是对同一个微服务的不同的功能进行测试，此时，可以通过路由配置以将对同一个微服务的不同的功能进行测试的微服务调用请求路由至不同的测试环境，以实现对同一个微服务的不同的功能进行并行测试。

其中注册是指在微服务的注册中心进行注册，其中本地服务平台还包括一注册中心，该注册中心中存储有所有微服务的信息，其中当微服务的功能发生改变时，则注册中心生成新的微服务。需要说明的是一个微服务可以在注册中心中注册不同的版本，版本的不同是由微服务的功能的变化导致的。

当待处理微服务在注册中心处理完成后，则注册中心将注册完成的待处理微服务发送至路由模块，路由模块根据注册完成的待处理微服务进行路由配置以得到路由配置信息。其中可选地，路由模块可以获取待处理微服务对应的原始微服务的路由配置信息，然后将待处理微服务的地址替换该路由配置信息中原始微服务的地址以得到新的路由配置信息。此外，若是路由模块不存在待处理微服务对应的原始微服务的路由配置信息，则可以由用户来对该待处理微服务进行初始路由配置信息的配置。

其中针对具体的路由配置信息，其可以携带有对应的终端的标识，这样后续在使用具体的路由配置信息时，可以根据终端的标识确定路由配置信息的选择范围。

S106：接收终端发送的微服务处理请求，微服务处理请求携带有微服务标识。

具体地，微服务处理是指对微服务的调试或者是测试，该微服务处理请求则是在调试或者是测试的时候，针对所需要调用的微服务所产生的调用请求，因此其所携带的微服务标识即为需要调用的微服务的标识，其可以是正在处理的微服务，或者是位于基线微服务中的微服务。

S108：获取路由配置信息，根据路由配置信息在共用基线微服务中确定与微服务标识对应的待调用微服务。

具体地，路由配置信息是动态更新的，即在存在新的微服务注册时，对路由配置信息进行动态更新，具体可以参见下文。其中各个微服务是存在依赖关系的，该依赖关系即路由关系，因此通过路由配置可以实现微服务的调用。

其中本地服务平台在接收到微服务处理请求后，可以先获取到发送微服务处理请求的终端的标识，根据该终端的标识确定所需要查询的路由配置信息，然后根据微服务标识确定所需要的路由配置信息，最后根据所需要的路由配置信息获取到待调用微服务。

其中，该待调用微服务可以是共用基线微服务中的，即并不是终端中正在处理的微服务，这样终端不需要在本地启动所有的微服务，仅需要启动正在处理的待处理微服务即可，在需要调用其他的微服务时，直接根据路由配置信息进行调用，从而减少了终端的资源占用。

S110：调用待调用微服务得到处理结果。

具体地，本地服务平台调用微服务以得到处理结果并发送给终端，从而使得终端完成对待处理微服务的开发中的调试或者是测试中的测试。

上述基于路由的微服务处理方法，启动共用基线服务，并且将待处理微服务进行注册，以重新配置路由配置信息，这样当接收到终端发送的微服务处理请求时，根据路由配置信息即可以在共用基线微服务中确定对应的待调用微服务，不需要在本地启动所需要的所有的微服务，减少了本地的资源占用。

在其中一个实施例中，结合图2所示，图2为一个实施例中的应用开发调试方法的应用环境图，待处理微服务为正在开发的微服务；根据路由配置信息在共用基线微服务中确定与微服务标识对应的待调用微服务之前，还包括：判断微服务标识对应的微服务是否为正在开发的微服务；当微服务标识对应的微服务为正在开发的微服务，则根据路由配置信息获取正在开发的微服务的微服务标识对应的正在开发的微服务。

其中如图2所示，本地开发环境是指终端中部署的开发环境，在该开发环境可以仅启动待处理微服务，如图2中，其可以为综合服务（开发）和客户服务（开发），在其他的实施例中，待处理微服务可以为其他的微服务。在本地服务平台中启动共用基线服务，该共用基线服务是包括所有的微服务的，如图2中的Docker容器中其包括所有的微服务，例如综合服务、客户服务、项目服务、协议服务、批注里服务、保单服务、考试服务（M）、考试服务（PC）、消息待办和统一认证中心，在其他的实施例中，还可以包括其他的微服务，在此不作具体的限定。

这样在本地服务平台中的路由，也即图2中的Zuul增强版网关中可以预先配置有初始路由信息，当终端向注册中心注册新的微服务时，路由根据注册的新的微服务实现动态路由信息的配置。

这样在终端研发调试的时候，可以根据所配置的动态路由信息和原来的初始路由信息来调用共用基线服务中的微服务，而不需要在研发的终端启动所需要的所有的微服务，可以减少终端的资源占用。

其中可选地，注册中心还可以监控本地的待处理微服务以及共用基线微服务的健康，以实时更新注册中心中的微服务的状态，从而在根据路由配置信息调用微服务之前，还可以判断对应的微服务是否正常，若正常，则根据路由配置信息进行微服务的调用，否则输出错误。

其中在实际应用中，以开发区最小粒度运行调试相关应用为例，本地开发专注启动与业务需求相关的微服务应用，其他依赖微服务为本地服务器环境微服务应用，即上述的共用基线服务（支持项目组所有开发人员同时使用，互不冲突），传统开发微服务都是需要启动注册中心，网关中心，相关业务服务等至少3个微服务，而通过上述方法将这两个微服务只需部署在一台所有开发人员都能访问到的机器上即可，即本地服务平台上，即可通过路由，也即下文中的网关请求处理器将请求转发到对应的开发人员对应的业务服务上。

例如开发人员实施开发调整“客户服务”微服务的相关需求，开发人员在本地启动“客户服务”微服务，其他微服务部署在本地服务器环境，所有服务采用Rest Api方式,传输格式为Json。

首先开发环境服务启动时，也即在终端进行开发的时候，请求本地共用“注册中心应用”完成服务注册，以将待处理微服务进行注册。

其次，在开发环境访问本地前端应用，登录验证时请求通过本地共用的“网关服务”路由转发至本地共用“统一认证中心”微服务完成登录认证。

最后，在本地调用访问“客户服务”时，请求通过“网关服务”路由至本地“客户服务”微服务，本地“客户服务”微服务有依赖其他业务微服务，通过本地共用“网关应用”路由至本地共用基线服务。

上述实施例中，开发区结合该组件最小粒度运行(开发什么应用则启动什么应用,无需启动其它依赖应用服务)，提升资源利用率，提高开发效率，开发者只关注自身需求对应的服务即可。

在其中一个实施例中，待处理微服务为测试微服务；根据路由配置信息在共用基线微服务中确定与微服务标识对应的待调用微服务，包括：根据路由配置信息调用对应的测试环境下的与微服务标识对应的测试微服务，其中测试环境包括多个，且至少一个测试环境中启动所有的共用基线微服务，剩余的测试环境仅启动对应的测试微服务。

在其中一个实施例中，剩余的测试环境所启动的对应的测试微服务相同或不相同。

具体地，参阅图3所示，图3为一个实施例中的应用测试方法的应用环境图，在该实施例中，共用基线微服务是通过一条完整微服务应用基线来表征的，如图3中的DEV01、SIT01、UAT01，其分别用于测试过程中的不同的阶段。该完整微服务应用基线构成一个测试环境，当需要对同一微服务进行不同的功能的测试时，可以构建新的测试环境，通过路由至该新的测试环境以实现对其他的功能的测试，这样可以实现同时对同一个微服务的不同的功能的并行测试，提高测试效率。

具体地，在测试的时候，可以根据待处理微服务确定所要调用的测试环境，例如当待处理微服务已经被其他的终端进行测试，则选取其他终端未采用的测试环境进行测试，这样在该测试环境中部署待处理微服务，并根据待处理微服务的部署的测试环境生成动态路由信息，以更新路由配置，例如替换待处理微服务对应的原始微服务所对应的路由配置信息中的地址，这样在终端进行测试的过程中，若是需要调用微服务，则根据路由配置信息来路由至对应的微服务，其中，针对测试环境中不存在的微服务，则路由至共用基线微服务中，以实现微服务的调用。

在实际应用中，测试区结合该组件最小粒度建立多条线并行测试环境为例进行说明。具体地，如图3所示，测试区保留一条完整微服务应用基线（DEV01、SIT01、UAT01），其他并行版本线（DEV 02、DEV 03等）根据开发的服务需求点最小粒度启动，在其他的实施例中，测试环境的数量可以根据需要设置，并不局限于图3中的3个测试环境，其中一个测试环境中启动共用基线微服务，即启动所有的微服务，在其他的测试环境中则根据测试的待处理微服务来启动对应的待处理微服务，未改动的微服务通过网关服务路由至测试区基线微服务应用（支持多需求并行测试使用，互不冲突）。

例如，不同版本排期上线的需求，需要同时使用测试环境，需求点一、需求点二都是开发同一个“客户服务”微服务，但是不同的功能，其他服务部署在测试环境，以SIT01/SIT02举例。通过SIT01来测试需求点一，通过SIT02来测试需求点二，两者是可以并行测试的。

首先SIT01测试环境中启动包含“客户服务”微服务在内的多个业务基线微服务，在启动时请求本地共用“注册中心应用”完成服务注册，提供SIT01测试能力，SIT02只启动“客户服务”微服务，其他SIT02服务路由至SIT01基线应用服务中。

其次，通过PC/APP应用开始测试，请求测试验证SIT01“客户服务”时为：/SIT01/customer/xxx，依赖“项目服务”为：/SIT01/project/xxx，请求调用时通过网关路由默认转发至基线环境。也就是说在测试需求点一时，所有的微服务都调用测试环境SIT01中的微服务以完成测试。

再者，通过PC/APP应用开始测试，请求测试验证SIT02“客户服务”时为：/SIT02/customer/xxx，依赖“项目服务”为：/SIT01/project/xxx，请求调用网关时路由映射可配置转发调用SIT01基线环境。也就是说在测试需求点二时，当调用的微服务为测试环境SIT02中的时候，则调用测试环境SIT02中的微服务，否则通过路由配置信息调用SIT01中的微服务，以完成测试。

上述实施例中，测试区结合该组件最小粒度可建立多条线（DEV01、SIT01、UAT01）与多节点（01、02、03），并支撑移动端单应用APP一键切换不同环境的能力，无需安装不同环境的手机端App，大大提高测试效率，支撑多需求并行开发测试。在其中一个实施例中，结合图4所示，图4为一个实施例中的动态路由配置方法的流程示意图，在该实施例中，该动态路由配置方法可以包括：

S402：监听是否存在预设应用事件。

具体地，结合图5，图5为一个实施例中的动态路由配置方法的流程框图，预设应用事件是指可以触发网关请求处理器进行路由信息的更新的事件。该事件可以分为至少三类：一类是应用启动时所发布的上下文刷新事件，该上下文刷新事件ContextRefreshedEvent是预设应用事件的子事件，一类是路由刷新事件RoutesRefreshedEvent，例如在网关请求处理器运行过程中，对路由进行实时刷新。第三类是刷新范围更新事件RefreshScopeRefreshedEvent等。其中需要说明的是，上文中的路由注册信息即为动态路由信息，本地服务平台将动态路由信息存储至数据库中，并触发动态路由信息的配置，从而可以生成预设应用事件，以对路由配置信息进行配置，为后续微服务处理奠定基础。

网关请求处理器是位于本地服务平台中的，其可以预设单独的网关刷新***以对该三种事件进行监听，一旦监听到该三种事件的任意一种时，则调用ZuulHandlerMapping.setDirty(true)函数，该ZuulHandlerMapping.setDirty(true)函数主要功能是用来通知当前线程将ZuulHandlerMapping（网关请求处理器）设置为脏数据，类似标志位以标识当前进行路由的刷新，从而进行网关路由的刷新。

S404：当存在预设应用事件时，则获取配置文件中的初始路由信息和数据库中的动态路由信息。

具体地，初始路由信息是配置文件中存储的路由信息，该部分信息可以是保证网关请求处理器可以使用的最基础的信息或者是至少包括保证网关请求处理器可以使用的最基础的信息。动态路由信息则是存储在数据库中的，其是用户设置的，可以随用户的设置而不同。其中网关请求处理器可以通过预设的方法从配置文件和数据库中读取最新的初始路由信息和动态路由信息。其中为了保证路由信息的唯一性，设置数据库中的动态路由信息的优先级高于配置文件中的初始路由信息。

S406：根据初始路由信息和动态路由信息进行路由配置。

具体地，网关请求处理器在获取到初始路由信息和动态路由信息后，则需要对初始路由信息和动态路由信息进行合并，例如网关请求处理器将初始路由信息和动态路由信息的属性进行比较，若是涉及到同一属性，则获取到动态路由信息，若是涉及到不同的属性，则获取到该不同的属性所对应的信息。例如初始理由信息中存在属性a、属性b和属性c，动态路由信息里涉及到属性c和属性d，则最后进行路由配置时所涉及的路由信息包括属性a、属性b、属性c和属性d，其中属性c是以动态路由信息里的属性c为准。

具体地，路由配置则是将最终获取的路由信息，即将初始路由信息和动态路由信息组合后的组合路由信息缓存在对应的属性中，例如缓存在简单路由***SimpleRouteLocator的属性AtomicReference<Map<String, ZuulRoute>> routes中。

上述动态路由配置方法，通过监听预设应用事件来判断是否存在路由信息的刷新，当存在时，则读取配置文件中的初始路由信息和数据库中的动态路由信息，这样保证了初始路由信息和动态路由信息的读取，从而可以实现路由的动态配置。

在其中一个实施例中，获取配置文件中的初始路由信息和数据库中的动态路由信息，包括：通过扩展路由***调用简单路由***中的预设方法；通过简单路由***中的预设方法调用扩展路由***的对应的规则；根据所调用的规则查找配置文件中的初始路由信息和数据库中的动态路由信息。

具体地，参见图6所示，图6为图4所示实施例中步骤S404的流程图，在该实施例中，其中存在扩展路由***和简单路由***，扩展路由***是用户自己编写的，其可以按照预设规则查找并刷新动态路由信息和初始路由信息的，简单路由***则仅有获取路由信息的功能，即获取到扩展路由***所获取到的刷新的动态路由信息和初始路由信息。

其中在使用的时候，网关请求处理器通过扩展路由***中的refresh（）方法调用简单路由***中的预设方法，例如doRefresh（）方法，这样网关请求处理器通过该doRefresh（）方法调用扩展路由***的对应的规则，例如调用扩展路由***RouteLocatorExt的locateRoutes()方法获取所有路由信息，包括初始路由信息和动态路由信息。

其中，通过扩展路由***调用简单路由***中的预设方法之前，还可以包括：从当前的***表中，查找所有的用于获取路由信息的目标***；通过扩展路由***调用简单路由***中的预设方法，包括：获取目标***中的扩展路由***和简单路由***；通过扩展路由***调用简单路由***中的预设方法。例如，网关请求处理器首先获取到组合路由***，该组合路由***可以根据***表查找到所有的用于获取路由信息的路由***，即会调用所有实现了RefreshableRouteLocator接口的refresh()方法进行路由刷新。其组合路由***CompositeRouteLocator中的refresh()方法会执行所有实现了RefreshableRouteLocator接口的类的refresh()方法，其中包括了扩展路由***RouteLocatorExt类，这样扩展路由***RouteLocatorExt中refresh()方法调用简单路由***SimpleRouteLocator中的doRefresh()处理动态路由刷新，简单路由***SimpleRouteLocator的doRefresh()方法调用扩展路由***RouteLocatorExt的locateRoutes()方法获取所有路由信息。

上述实施例中，通过设置多个***，包括扩展路由***和简单路由***，一方面保证了路由信息查找的完整性，另一方面保证了路由信息的刷新的准确性。此外还引入了组合路由***，从而可以获取到所有的实现了RefreshableRouteLocator接口的refresh()方法进行路由刷新。

在其中一个实施例中，获取配置文件中的初始路由信息和数据库中的动态路由信息之前，还包括：设置当前标志信息为路由配置。当前标志信息是用于表示网关请求处理器当前是进行路由配置还是业务处理的。

例如当监听到预设应用事件时，则网关请求处理器需要进行路由配置，则网关请求处理器通知当前线程将ZuulHandlerMapping（网关请求处理器）设置为脏数据，也即设置当前标志信息为路由配置，从而该网关请求处理器ZuulHandlerMapping中的脏数据设置方法setDirty()方法执行组合路由***中的刷新函数CompositeRouteLocator.refresh()以进行路由配置。当是接收到服务请求时，例如参照图7所示，网关请求处理器匹配对应的业务请求处理器，也就是对应的服务处理器以对服务请求进行处理。其中该些业务请求处理器均需要预先在网关请求处理器中进行注册，也就是设置对应的路由信息，以进行路由配置，从而实现业务的处理。

上述实施例中通过标志信息将路由配置和业务请求处理进行区分，保证了路由配置的有条不紊地进行，以避免与业务请求处理造成混乱。

在其中一个实施例中预设应用事件的生成可以是在网关请求处理器启动时生成的或者是用户需要对网关请求处理器中的路由信息进行更新并触发了路由刷新事件生成的。

其中预设应用事件的生成方式包括：接收动态路由信息，并将动态路由信息存储至数据库中；接收针对动态路由信息的配置触发请求；根据配置触发请求生成预设应用事件。

具体地，结合图8所示，首先需要将动态路由信息存储至数据库中，例如通过zuul在数据库中增加对应的动态路由规则，然后进行手动刷新，即向预设的接口发送刷新请求，也即接收针对动态路由信息的配置触发请求，这样网关处理器根据该配置触发请求从数据库读取动态路由信息，并进行配置。

具体地，用户可以行手动刷新，即向预设的接口发送刷新请求，该接口为暴露一个内网请求地址，如：http://xxx.yy/api/route/refresh,调用刷新服务器RefreshRouteService.refreshRoute发布一个路由刷新事件RoutesRefreshedEvent事件。

可选地，预设应用事件的生成方式包括：接收应用启动请求，根据应用启动请求生成预设应用事件。例如zuul网关应用启动时会发布一个ContextRefreshedEvent(上下文刷新事件)，该事件继承ApplicationContextEvent（应用上下文事件），主要功能是用来通知当前线程将ZuulHandlerMapping（网关请求处理器）设置为脏数据，从而使网关路由进行刷新。

上述实施例中给出了两种进行路由刷新的情况，其中，生产区结合该组件新服务应用部署下可以无影响不停机部署，将生产部署的影响范围减低，亦可实现蓝绿发布。

具体地，参照图9所示，图9为一个实施例中的动态路由配置方法的时序图，在该实施例中，zuul网关应用启动时会发布一个ContextRefreshedEvent(上下文刷新事件)，该事件继承ApplicationContextEvent（应用上下文事件），主要功能是用来通知当前线程将ZuulHandlerMapping（网关请求处理器）设置为脏数据，从而使网关路由进行刷新。

ZuulRefreshListener（网关刷新***）会监听三种事件上下文刷新事件ContextRefreshedEvent、刷新范围更新事件RefreshScopeRefreshedEvent以及路由刷新事件RoutesRefreshedEvent（都属于ApplicationContextEvent的子事件），一旦接收相关事件则调用ZuulHandlerMapping.setDirty(true)，从而进行网关路由的刷新。

网关请求处理器ZuulHandlerMapping中的setDirty()方法执行组合路由***CompositeRouteLocator.refresh()，该组合路由***会调用所有实现了RefreshableRouteLocator接口的refresh()方法进行路由刷新。且组合路由***CompositeRouteLocator中的refresh()方法会执行所有实现了RefreshableRouteLocator接口的类的refresh()方法，其中包括了扩展路由***RouteLocatorExt类。扩展路由***RouteLocatorExt中refresh()方法调用简单路由***SimpleRouteLocator中的doRefresh()处理动态路由刷新。简单路由***SimpleRouteLocator的doRefresh()方法调用子类扩展路由***RouteLocatorExt的locateRoutes()方法获取所有路由信息。

其中扩展路由***RouteLocatorExt.locateRoutes()实现了从配置文件中加载的初始路由信息，从数据库DB中加载的路由信息，最终路由会合并两个路由信息，其一为程序中默认配置的初始路由信息，其二为DB中配置的动态路由信息，数据库DB中的配置优先级高于默认配置。最后网关请求处理器将获取的最终路由数据缓存在SimpleRouteLocator的属性AtomicReference<Map<String, ZuulRoute>> routes中。

其中若zuul在数据库DB中增加了路由规则，只需手动刷新路由规则即可，方式是通过一个接口，该接口为暴露一个内网请求地址，如：http://xxx.yy/api/route/refresh,调用刷新路由服务RefreshRouteService.refreshRoute发布一个路由刷新事件RoutesRefreshedEvent事件，剩余步骤同上。经过如上步骤，从而实现不停机刷新路由规则，达到动态路由的目的。

应该理解的是，虽然图1和图4~图9的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1和图3~图6中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图10所示，提供了一种基于路由的微服务处理装置，包括：启动模块100、注册模块200、接收模块300、路由模块400和处理模块500，其中：

启动模块100，用于启动共用基线微服务；

注册模块200，用于接收待处理微服务注册请求，并根据注册请求注册对应的待处理微服务，注册完成的待处理微服务用于配置数据库中的路由配置信息；

接收模块300，用于接收终端发送的微服务处理请求，微服务处理请求携带有微服务标识；

路由模块400，用于获取路由配置信息，根据路由配置信息在共用基线微服务中确定与微服务标识对应的待调用微服务；

处理模块500，用于调用待调用微服务得到处理结果。

在其中一个实施例中，待处理微服务为正在开发的微服务；上述基于路由的微服务处理装置还包括：

判断模块，用于判断微服务标识对应的微服务是否为正在开发的微服务；

微服务获取模块，用于当微服务标识对应的微服务为正在开发的微服务，则根据路由配置信息获取正在开发的微服务的微服务标识对应的正在开发的微服务。

在其中一个实施例中，待处理微服务为测试微服务；路由模块400用于根据路由配置信息调用对应的测试环境下的与微服务标识对应的测试微服务，其中测试环境包括多个，且至少一个测试环境中启动所有的共用基线微服务，剩余的测试环境仅启动对应的测试微服务。

在其中一个实施例中，剩余的测试环境所启动的对应的测试微服务相同或不相同。

在其中一个实施例中，上述基于路由的微服务处理装置还包括：

监听模块，用于监听是否存在预设应用事件；

路由信息获取模块，用于当存在预设应用事件时，则获取配置文件中的初始路由信息和数据库中的动态路由信息；

配置模块，用于根据初始路由信息和动态路由信息进行路由配置。

在其中一个实施例中，上述路由信息获取模块包括：

第一调用单元，用于通过扩展路由***调用简单路由***中的预设方法；

第二调用单元，用于通过简单路由***中的预设方法调用扩展路由***的对应的规则；

查找单元，用于根据所调用的规则查找配置文件中的初始路由信息和数据库中的动态路由信息。

在其中一个实施例中，上述基于路由的微服务处理装置还包括：

存储模块，用于接收动态路由信息，并将动态路由信息存储至数据库中，动态路由信息是根据注册完成的待处理微服务生成的；

触发模块，用于接收针对动态路由信息的配置触发请求；

事件生成模块，用于根据配置触发请求生成预设应用事件。

关于基于路由的微服务处理装置的具体限定可以参见上文中对于基于路由的微服务处理方法的限定，在此不再赘述。上述基于路由的微服务处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图11所示。该计算机设备包括通过***总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作***和计算机程序。该内存储器为非易失性存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC（近场通信）或其他技术实现。该计算机程序被处理器执行时以实现一种基于路由的微服务处理方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图11中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：启动共用基线微服务；接收待处理微服务注册请求，并根据注册请求注册对应的待处理微服务，注册完成的待处理微服务用于配置数据库中的路由配置信息；接收终端发送的微服务处理请求，微服务处理请求携带有微服务标识；获取路由配置信息，根据路由配置信息在共用基线微服务中确定与微服务标识对应的待调用微服务；调用待调用微服务得到处理结果。

在一个实施例中，处理器执行计算机程序时所涉及的待处理微服务为正在开发的微服务；处理器执行计算机程序时所实现的根据路由配置信息在共用基线微服务中确定与微服务标识对应的待调用微服务之前，还包括：判断微服务标识对应的微服务是否为正在开发的微服务；当微服务标识对应的微服务为正在开发的微服务，则根据路由配置信息获取正在开发的微服务的微服务标识对应的正在开发的微服务。

在一个实施例中，处理器执行计算机程序时所涉及的待处理微服务为测试微服务；处理器执行计算机程序时所实现的根据路由配置信息在共用基线微服务中确定与微服务标识对应的待调用微服务，包括：根据路由配置信息调用对应的测试环境下的与微服务标识对应的测试微服务，其中测试环境包括多个，且至少一个测试环境中启动所有的共用基线微服务，剩余的测试环境仅启动对应的测试微服务。

在一个实施例中，处理器执行计算机程序时所涉及的剩余的测试环境所启动的对应的测试微服务相同或不相同。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：监听是否存在预设应用事件；当存在预设应用事件时，则获取配置文件中的初始路由信息和数据库中的动态路由信息；根据初始路由信息和动态路由信息进行路由配置。

在一个实施例中，处理器执行计算机程序时所涉及的获取配置文件中的初始路由信息和数据库中的动态路由信息，包括：通过扩展路由***调用简单路由***中的预设方法；通过简单路由***中的预设方法调用扩展路由***的对应的规则；根据所调用的规则查找配置文件中的初始路由信息和数据库中的动态路由信息。

在一个实施例中，处理器执行计算机程序时所涉及的预设应用事件的生成方式包括：接收动态路由信息，并将动态路由信息存储至数据库中；接收针对动态路由信息的配置触发请求；根据配置触发请求生成预设应用事件。

一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：启动共用基线微服务；接收待处理微服务注册请求，并根据注册请求注册对应的待处理微服务，注册完成的待处理微服务用于配置数据库中的路由配置信息；接收终端发送的微服务处理请求，微服务处理请求携带有微服务标识；获取路由配置信息，根据路由配置信息在共用基线微服务中确定与微服务标识对应的待调用微服务；调用待调用微服务得到处理结果。

在一个实施例中，计算机程序被处理器执行时所涉及的待处理微服务为正在开发的微服务；计算机程序被处理器执行时所实现的根据路由配置信息在共用基线微服务中确定与微服务标识对应的待调用微服务之前，还包括：判断微服务标识对应的微服务是否为正在开发的微服务；当微服务标识对应的微服务为正在开发的微服务，则根据路由配置信息获取正在开发的微服务的微服务标识对应的正在开发的微服务。

在一个实施例中，计算机程序被处理器执行时所涉及的待处理微服务为测试微服务；计算机程序被处理器执行时所实现的根据路由配置信息在共用基线微服务中确定与微服务标识对应的待调用微服务，包括：根据路由配置信息调用对应的测试环境下的与微服务标识对应的测试微服务，其中测试环境包括多个，且至少一个测试环境中启动所有的共用基线微服务，剩余的测试环境仅启动对应的测试微服务。

在一个实施例中，计算机程序被处理器执行时所涉及的剩余的测试环境所启动的对应的测试微服务相同或不相同。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：监听是否存在预设应用事件；当存在预设应用事件时，则获取配置文件中的初始路由信息和数据库中的动态路由信息；根据初始路由信息和动态路由信息进行路由配置。

在一个实施例中，计算机程序被处理器执行时所涉及的获取配置文件中的初始路由信息和数据库中的动态路由信息，包括：通过扩展路由***调用简单路由***中的预设方法；通过简单路由***中的预设方法调用扩展路由***的对应的规则；根据所调用的规则查找配置文件中的初始路由信息和数据库中的动态路由信息。

在一个实施例中，计算机程序被处理器执行时所涉及的预设应用事件的生成方式包括：接收动态路由信息，并将动态路由信息存储至数据库中；接收针对动态路由信息的配置触发请求；根据配置触发请求生成预设应用事件。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器（Read-Only Memory，ROM）、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器（Static Random Access Memory，SRAM）或动态随机存取存储器（Dynamic Random Access Memory，DRAM）等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于路由的微服务处理方法，其特征在于，所述方法包括：

启动共用基线微服务；

接收待处理微服务注册请求，并根据所述注册请求注册对应的待处理微服务，注册完成的待处理微服务用于配置数据库中的路由配置信息；

接收终端发送的微服务处理请求，所述微服务处理请求携带有微服务标识；

获取路由配置信息，根据所述路由配置信息在所述共用基线微服务中确定与所述微服务标识对应的待调用微服务；

调用所述待调用微服务得到处理结果。

2.根据权利要求1所述的方法，其特征在于，所述待处理微服务为正在开发的微服务；所述根据所述路由配置信息在所述共用基线微服务中确定与所述微服务标识对应的待调用微服务之前，还包括：

判断所述微服务标识对应的微服务是否为正在开发的微服务；

当所述微服务标识对应的微服务为正在开发的微服务，则根据所述路由配置信息获取正在开发的微服务的微服务标识对应的正在开发的微服务。

3.根据权利要求1所述的方法，其特征在于，所述待处理微服务为测试微服务；所述根据所述路由配置信息在所述共用基线微服务中确定与所述微服务标识对应的待调用微服务，包括：

根据所述路由配置信息调用对应的测试环境下的与所述微服务标识对应的测试微服务，其中所述测试环境包括多个，且至少一个测试环境中启动所有的共用基线微服务，剩余的测试环境仅启动对应的测试微服务。

4.根据权利要求3所述的方法，其特征在于，所述剩余的测试环境所启动的对应的测试微服务相同或不相同。

5.根据权利要求1至4任意一项所述的方法，其特征在于，所述方法还包括：

监听是否存在预设应用事件；

当存在预设应用事件时，则获取配置文件中的初始路由信息和数据库中的动态路由信息；

根据所述初始路由信息和所述动态路由信息进行路由配置。

6.根据权利要求5所述的方法，其特征在于，所述获取配置文件中的初始路由信息和数据库中的动态路由信息，包括：

通过扩展路由***调用简单路由***中的预设方法；

通过简单路由***中的预设方法调用所述扩展路由***的对应的规则；

根据所调用的规则查找配置文件中的初始路由信息和数据库中的动态路由信息。

7.根据权利要求5所述的方法，其特征在于，所述预设应用事件的生成方式包括：

接收动态路由信息，并将所述动态路由信息存储至数据库中，所述动态路由信息是根据注册完成的待处理微服务生成的；

接收针对所述动态路由信息的配置触发请求；

根据所述配置触发请求生成预设应用事件。

8.一种基于路由的微服务处理装置，其特征在于，所述装置包括：

启动模块，用于启动共用基线微服务；

注册模块，用于接收待处理微服务注册请求，并根据所述注册请求注册对应的待处理微服务，注册完成的待处理微服务用于配置数据库中的路由配置信息；

接收模块，用于接收终端发送的微服务处理请求，所述微服务处理请求携带有微服务标识；

路由模块，用于获取路由配置信息，根据所述路由配置信息在所述共用基线微服务中确定与所述微服务标识对应的待调用微服务；

处理模块，用于调用所述待调用微服务得到处理结果。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述的方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

Images