CN111539019A - 应用模块的处理方法、装置、设备及存储介质 - Google Patents

Abstract

本公开提供一种应用模块的处理方法、装置、设备及存储介质。本实施例提供的应用模块的处理方法，应用在包含网关和数据库的SaaS系统中，所述数据库用于存储各个应用模块的开关状态；所述网关用于注册应用模块，并根据所述开关状态处理针对所述应用模块的访问请求；该方法包括：确定存在数据泄露的应用模块；在数据库中将所述应用模块的开关状态设置为关闭状态，以使得所述应用模块在SaaS系统中下线。通过本公开实施例提供的应用模块的处理方法，可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

Description

应用模块的处理方法、装置、设备及存储介质

技术领域

本公开涉及数据处理技术领域，尤其涉及一种应用模块的处理方法、装置、设备及存储介质。

背景技术

随着互联网技术的兴起，软件即服务(Software-as-a-service，SaaS)形态的业务系统逐渐占据主流。按照业务模块的划分，SaaS系统上会划为多个应用模块，并在portal页上面显示各个应用模块的图标。用户可以通过portal页上的图标进入相应的应用。

现有的SaaS系统中可以灵活地进行应用模块的扩展，这些应用模块可以是独立的业务，也可以是存在关联的业务。当系统中的应用模块存在数据泄露时，必须立刻中断服务，以避免应用数据的泄露。

但是，应用模块与SaaS系统中的微服务不是一对一的关系。因此，当中断服务时，会导致微服务提供支持的其他应用模块无法使用，使得SaaS系统的稳定性降低。

发明内容

本公开提供一种应用模块的处理方法、装置、设备及存储介质，可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

第一方面，本公开提供一种应用模块的处理方法，应用在包含网关和数据库的SaaS系统中，所述数据库用于存储各个应用模块的开关状态；所述网关用于注册应用模块，并根据所述开关状态处理针对所述应用模块的访问请求；所述方法包括：

确定存在数据泄露的应用模块；

在数据库中将所述应用模块的开关状态设置为关闭状态，以使得所述应用模块在SaaS系统中下线。

在一种可能的设计中，在确定存在数据泄露的应用模块之前，还包括：

在网关上注册各个应用模块的开关，并将各个应用模块的开关状态存储到数据库中。

在一种可能的设计中，还包括：

接收针对应用模块的访问请求；

查询所述应用模块在数据库中存储的开关状态；

若所述开关状态为关闭状态，则拦截所述访问请求；

若所述开关状态为启用状态，则向用户端反馈针对所述访问请求的业务处理结果。

在一种可能的设计中，还包括：

接收针对应用模块的访问请求；

查询所述应用模块在网关本地缓存中的开关状态；

若所述开关状态为关闭状态，则拦截所述访问请求。

在一种可能的设计中，还包括：

接收针对应用模块的访问请求；

确定网关本地缓存中的开关状态是否在有效时限内；

若不在有效时限内，则查询所述应用模块在数据库中存储的开关状态；

若在有效时限内，则查询所述应用模块在网关本地缓存中的开关状态；

若所述开关状态为关闭状态，则拦截所述访问请求。

在一种可能的设计中，在拦截所述访问请求之后，还包括：

向用户端发送无法访问提示信息，和/或在SaaS系统portal页面上将对应的所述应用模块置为无法访问状态。

在一种可能的设计中，还包括：

在数据泄露解除之后，将所述数据库中所述应用模块的开关状态设置为启用状态，以使得所述应用模块在SaaS系统中重新上线。

第二方面，本公开还提供一种应用模块的处理装置，应用在包含网关和数据库的SaaS系统中，所述数据库用于存储各个应用模块的开关状态；所述网关用于注册应用模块，并根据所述开关状态处理针对所述应用模块的访问请求；所述装置包括：

确定模块，用于确定存在数据泄露的应用模块；

设置模块，用于在数据库中将所述应用模块的开关状态设置为关闭状态，以使得所述应用模块在SaaS系统中下线。

在一种可能的设计中，还包括：预处理模块，用于：

在网关上注册各个应用模块的开关，并将各个应用模块的开关状态存储到数据库中。

在一种可能的设计中，还包括：

接收模块，用于接收针对应用模块的访问请求；

查询模块，用于查询所述应用模块在数据库中存储的开关状态；

拦截模块，用于在所述开关状态为关闭状态时，拦截所述访问请求；

反馈模块，用于在所述开关状态为启用状态时，向用户端反馈针对所述访问请求的业务处理结果。

在一种可能的设计中，还包括：

接收模块，用于接收针对应用模块的访问请求；

查询模块，用于查询所述应用模块在网关本地缓存中的开关状态；

拦截模块，用于所述开关状态为关闭状态，拦截所述访问请求。

在一种可能的设计中，还包括：

接收模块，用于接收针对应用模块的访问请求；

确定模块，还用于确定网关本地缓存中的开关状态是否在有效时限内；

查询模块，用于在网关本地缓存中的开关状态不在有效时限内时，查询所述应用模块在数据库中存储的开关状态；以及在网关本地缓存中的开关状态有效时限内时，查询所述应用模块在网关本地缓存中的开关状态；

拦截模块，用于所述开关状态为关闭状态时，拦截所述访问请求。

在一种可能的设计中，在拦截所述访问请求之后，还包括：

显示模块，用于向用户端发送无法访问提示信息，和/或在SaaS系统portal页面上将对应的所述应用模块置为无法访问状态。

在一种可能的设计中，所述设置模块，还用于：

在数据泄露解除之后，将所述数据库中所述应用模块的开关状态设置为启用状态，以使得所述应用模块在SaaS系统中重新上线。

第三方面，本公开还提供一种电子设备，包括：

处理器；以及，

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行第一方面中任意一种应用模块的处理方法。

第四方面，本公开实施例还提供一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现第一方面中任意一种应用模块的处理方法。

本公开提供一种应用模块的处理方法、装置、设备及存储介质，应用在包含网关和数据库的SaaS系统中，所述数据库用于存储应用模块的开关状态；所述网关用于注册应用模块，并根据所述开关状态处理针对所述应用模块的访问请求；通过确定存在数据泄露的应用模块；在数据库中将所述应用模块的开关状态设置为关闭状态，以使得所述应用模块在SaaS系统中下线。从而可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

附图说明

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

图1为本公开根据一示例实施例示出的应用模块的处理方法的应用场景图；

图2为本公开根据一示例实施例示出的应用模块的处理方法的流程示意图；

图3为本公开根据另一示例实施例示出的应用模块的处理方法的流程示意图；

图4为本公开根据又一示例实施例示出的应用模块的处理方法的流程示意图；

图5为本公开根据还一示例实施例示出的应用模块的处理方法的流程示意图；

图6为本公开根据一示例实施例示出的应用模块的处理装置的结构示意图；

图7为本公开根据另一示例实施例示出的应用模块的处理装置的结构示意图；

图8为本公开根据一示例实施例示出的电子设备的结构示意图。

具体实施方式

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

本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

随着互联网技术的兴起，软件即服务(Software-as-a-service，SaaS)形态的业务系统逐渐占据主流。按照业务模块的划分，SaaS系统上会划为多个应用模块，并在portal页上面显示各个应用模块的图标。用户可以通过portal页上的图标进入相应的应用。现有的SaaS系统中可以灵活地进行应用模块的扩展，这些应用模块可以是独立的业务，也可以是存在关联的业务。当系统中的应用模块存在数据泄露时，必须立刻中断服务，以避免应用数据的泄露。

这套SaaS系统的方案设计在扩展性方面非常优秀了，但存在系统安全性的问题，当系统中发现了重大风险，个别App模块发生数据泄密的情况下，必须立即中断服务，及时止损。虽然App之间可能没有关联，但App模块与系统中的微服务不一定是一对一的关系，很有可能多个App模块后面的微服务是同一个，只不过这些App提供的功能不同，访问的数据不同。所以，当系统上的某个App模块发生数据泄密风险了，如果是将为这个App模块提供支持的微服务下掉，那么同样由这个微服务提供支持的其他App模块也会无法使用，并且，更严重的是，由于微服务彼此间未必是独立的，很可能有其他的微服务依赖这个微服务提供的接口，如果这个微服务下掉了，那么依赖这个微服务接口的其他微服务也会无法使用，这样看来，会形成连锁反应，造成整个SaaS系统大部分App都无法使用，连带效应过大，使得SaaS系统的稳定性降低。

针对上述技术问题，本公开提供一种应用模块的处理方法、装置、设备及存储介质，解决只能从系统层面停止服务的问题，可以通过修改应用模块在数据库(例如Redis)中的开关状态，让SaaS系统能够关闭Portal上App模块的入口，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。其中，Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。图1为本公开根据一示例实施例示出的应用模块的处理方法的应用场景图，如图1所示，由多个微服务组成各种App的SaaS系统中，会有一层网关服务，接收外部的请求，将请求中的数据做处理和转换后，路由到对应的微服务上处理业务逻辑。所以，整个SaaS系统虽然由多个微服务构成，但存在统一的对外提供服务的处理层，这里就是网关(gateway)。由于gateway本身也是一个微服务，可以横向扩展有多套gateway实例服务部署，App开关的状态不能存在gateway内部，会引起多个gateway间状态同步的问题，所以将应用模块的开关状态在数据库中维护，各个gateway都从数据库中读取App开关状态。当发现系统出现安全性风险时，则判断为哪个App模块中的功能出现了问题，确定需要下线处理的模块。引入数据库作为系统全局缓存服务，在SaaS系统启动的时候，将系统上所有的App模块的开关状态，注册到数据库中，存储所有App模块开关状态的初始值。本实施例可以设置每个App模块的可用性，以key-value的结构，保存在数据库中，系统中新增的App要在数据库中设置状态的初始值，已经废弃的App在数据库中直接将对应的key删除。将系统的可用性，拆分成若干个App模块的可用性，当局部的App出现风险问题时，就可以通过单独设置App的可用状态，达到将风险问题剔除，解决后再上线，过程中对其他运行正常的App模块没有影响。当用户访问SaaS系统中的某个模块时，SaaS系统接收针对应用模块的访问请求。该访问请求会先经由gateway再转发到具体的微服务上，gateway接收到请求时，根据请求的接口属性特征找到这个请求是要访问哪个App模块。然后，根据App特征值去数据库或者网关本地缓存中查询这个App模块的开关状态，例如查询App02，得到状态值为1。Gateway根据应用模块在数据库中存储的开关状态，判断是否放行用户的这次访问请求。例如若开关状态为启用状态，即开关状态值为1，那么这个App是正常开放的，用户的这次请求被放行，向用户端反馈针对访问请求的业务处理结果。若开关状态为关闭状态，即开关状态值为0，那么这个App是不开放的，用户的这次访问请求将被拦截，同时也可以给前端返回错误提示信息。为了避免用户再次发出对这个App模块的请求，除了给前端返回错误信息告知用户请求的App已经下线，还要通知前端刷新App模块的图标，置为灰色不能点击，这样用户就不会再次访问这个App模块了。当某个应用模块需要下线处理时，那么可以从系统后端管理端发送一个命令，将数据库中这个App的开关状态值设为关闭，就完成了这个App模块的下线工作，例如发送"set App02 0"就表示将App02的状态设置为关闭。也可以在后台管理端的管理页面上，找到要下线的App模块，点击「下线」按钮，做到「一键下线」App模块。

本公开解决了SaaS系统中出现数据泄露时，只能按微服务做服务级的下线，如果下线的微服务中有被其他微服务依赖的接口，那么会连带着影响那些微服务的可用性，这样的问题，做到了按App模块做细粒度App级的下线，既解决了下线存在风险的App模块问题又保护了其他App的正常使用，很大程度上提高了SaaS系统的可用性。同时，做到了快速的「一键下线」App模块，没有复杂的操作，当发现系统风险时，能够做到立即止损，只需要发送一个命令，改变数据库中的状态值，就达到下线App的目的，提高了SaaS系统的安全性。而且，本公开的技术方案逻辑简单清晰，实现成本低，代码只涉及到读取数据库进行App模块的可用性判断，这个判断在gateway网关层校验，对业务逻辑代码无侵入，与业务代码解耦，方便修改，逻辑清晰，bug少，提高Saas系统稳定性。

图2为本公开根据一示例实施例示出的应用模块的处理方法的流程示意图，如图2所示，本实施例提供的应用模块的处理方法，可以应用在包含网关和数据库的SaaS系统中，数据库用于存储各个应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；，该方法包括：

步骤101、确定存在数据泄露的应用模块。

本实施例中，由多个微服务组成的SaaS系统中，会有一层服务网关，接收外部的请求，将请求中的数据做处理和转换后，路由到对应的微服务上处理业务逻辑。所以，整个SaaS系统虽然由多个微服务构成，但存在统一的对外提供服务的处理层，这里就是网关(gateway)。由于gateway本身也是一个微服务，可以横向扩展有多套gateway实例服务部署，App开关的状态不能存在gateway内部，会引起多个gateway间状态同步的问题，所以将应用模块的开关状态在数据库中维护，各个gateway都从数据库中读取App开关状态。当发现系统出现安全性风险时，则判断为哪个App模块中的功能出现了问题，确定需要下线处理的模块。

可选地，在网关上注册各个应用模块的开关，并将各个应用模块的开关状态存储到数据库中。

具体地，引入数据库作为系统全局缓存服务，在SaaS系统启动的时候，将系统上所有的App模块的开关状态，注册到数据库中，存储所有App模块开关状态的初始值。使用枚举值表示开关状态，0代表关闭，1代表开放。存储的数据结构为key-value的格式，例如设置了，App01:1，App02:1，App03:0，App04:1，表示App01、App02和App04是正常开放的，App03被关闭了。本实施例可以设置每个App模块的可用性，以key-value的结构，保存在数据库中，系统中新增的App要在数据库中设置状态的初始值，已经废弃的App在数据库中直接将对应的key删除。将系统的可用性，拆分成若干个App模块的可用性，当局部的App出现风险问题时，就可以通过单独设置App的可用状态，达到将风险问题剔除，解决后再上线，过程中对其他运行正常的App模块没有影响。

用户在进入SaaS系统时，portal页上显示出所有App图标，前端在渲染portal页上的App图标时，按照从后端查询到的App的开关状态，决定是否正常显示App图标或者将图标置灰，已经下线的App其图标会置为灰色，只有后端再次将这个App上线后，数据库中的App状态变为正常可用，前端查询时得到App的状态为可用时，在渲染时会将图标设置为正常显示。

步骤102、在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。

本实施例中，当某个应用模块需要下线处理时，那么可以从后端管理端发送一个命令，将数据库中这个App的开关状态值设为关闭，就完成了这个App模块的下线工作，例如发送"set App02 0"就表示将App02的状态设置为关闭。也可以在后台管理端的管理页面上，找到要下线的App模块，点击「下线」按钮，做到「一键下线」App模块。

可选地，在数据泄露解除之后，将数据库中应用模块的开关状态设置为启用状态，以使得应用模块在SaaS系统中重新上线。

具体地，在数据泄露解除之后，那么可以从后端管理端发送一个命令，将数据库中这个App的开关状态值设为启用状态，就完成了这个App模块的重新上线工作，例如发送"set App02 1"就表示将App02的状态设置为启用状态。也可以在后台管理端的管理页面上，找到要重新线的App模块，点击「上线」按钮，做到「一键上线」App模块。

本实施例，应用在包含网关和数据库的SaaS系统中，数据库用于存储应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；通过确定存在数据泄露的应用模块；在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。从而可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

图3为本公开根据另一示例实施例示出的应用模块的处理方法的流程示意图，如图3所示，本实施例提供的应用模块的处理方法，可以应用在包含网关和数据库的SaaS系统中，数据库用于存储各个应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；，该方法包括：

步骤201、确定存在数据泄露的应用模块。

步骤202、在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。

本实施例中，步骤201～步骤202的具体实现过程和技术原理请参见图2所示的方法中步骤101～步骤102中的相关描述，此处不再赘述。

步骤203、接收针对应用模块的访问请求。

步骤204、查询应用模块在数据库中存储的开关状态。

步骤205、若开关状态为关闭状态，则拦截访问请求。

步骤206、若开关状态为启用状态，则向用户端反馈针对访问请求的业务处理结果。

本实施例中，当用户访问SaaS系统中的某个模块时，SaaS系统接收针对应用模块的访问请求。该访问请求会先经由gateway再转发到具体的微服务上，gateway接收到请求时，根据请求的接口属性特征找到这个请求是要访问哪个App模块。然后，根据App特征值去数据库中查询这个App模块的开关状态，例如查询App02，得到状态值为1。Gateway根据应用模块在数据库中存储的开关状态，判断是否放行用户的这次访问请求。例如若开关状态为启用状态，即开关状态值为1，那么这个App是正常开放的，用户的这次请求被放行，向用户端反馈针对访问请求的业务处理结果。若开关状态为关闭状态，即开关状态值为0，那么这个App是不开放的，用户的这次访问请求将被拦截。

可选地，在拦截访问请求之后，还包括：向用户端发送无法访问提示信息，和/或在SaaS系统portal页面上将对应的应用模块置为无法访问状态。

具体地，如果用户请求的App模块状态为关闭，在gateway服务中会拦截本次请求，给前端返回错误提示信息。为了避免用户再次发出对这个App模块的请求，除了给前端返回错误信息告知用户请求的App已经下线，还要通知前端刷新App模块的图标，置为灰色不能点击，这样用户就不会再次访问这个App模块了。

本实施例，应用在包含网关和数据库的SaaS系统中，数据库用于存储应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；通过确定存在数据泄露的应用模块；在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。从而可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

另外，本实施例还可以在gateway上校验用户的访问请求，根据应用模块在数据库中存储的开关状态，判断是拦截访问请求，还是向用户端反馈针对访问请求的业务处理结果。从而可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

图4为本公开根据又一示例实施例示出的应用模块的处理方法的流程示意图，如图4所示，本实施例提供的应用模块的处理方法，可以应用在包含网关和数据库的SaaS系统中，数据库用于存储各个应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；，该方法包括：

步骤301、确定存在数据泄露的应用模块。

步骤302、在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。

步骤303、接收针对应用模块的访问请求。

本实施例中，步骤301～步骤203的具体实现过程和技术原理请参见图3所示的方法中步骤201～步骤203中的相关描述，此处不再赘述。

步骤304、查询应用模块在网关本地缓存中的开关状态。

步骤305、若开关状态为关闭状态，则拦截访问请求。

本实施例中，用户能够正常发起请求的大多数App模块的状态都是正常开放的，因为少部分App处于关闭状态但会在系统portal页面上显示为灰色图标不能点击。所以绝大多数的用户请求都是合法的访问那些开放状态的App模块，这样每个请求都要去数据库中判断一下状态，有些浪费性能。因此，为了优化性能，可以在gateway上设计一个本地缓存，将App模块的开关状态缓存在gateway服务内部，这样就不用每次都去数据库中查询了。当SaaS系统接收针对应用模块的访问请求，查询应用模块在网关本地缓存中的开关状态，判断是拦截访问请求，还是向用户端反馈针对访问请求的业务处理结果。对访问请求的拦截与放行详见图3所示的实施例描述，此处不再赘述。

可选地，在拦截访问请求之后，还包括：向用户端发送无法访问提示信息，和/或在SaaS系统portal页面上将对应的应用模块置为无法访问状态。

具体地，如果用户请求的App模块状态为关闭，在gateway服务中会拦截本次请求，给前端返回错误提示信息。为了避免用户再次发出对这个App模块的请求，除了给前端返回错误信息告知用户请求的App已经下线，还要通知前端刷新App模块的图标，置为灰色不能点击，这样用户就不会再次访问这个App模块了。

本实施例，应用在包含网关和数据库的SaaS系统中，数据库用于存储应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；通过确定存在数据泄露的应用模块；在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。从而可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

另外，本实施例还可以在gateway上校验用户的访问请求，根据应用模块在网关本地缓存中的开关状态，判断是拦截访问请求，还是向用户端反馈针对访问请求的业务处理结果。从而可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

图5为本公开根据还一示例实施例示出的应用模块的处理方法的流程示意图，如图5所示，本实施例提供的应用模块的处理方法，可以应用在包含网关和数据库的SaaS系统中，数据库用于存储各个应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；，该方法包括：

步骤401、确定存在数据泄露的应用模块。

步骤402、在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。

步骤403、接收针对应用模块的访问请求。

本实施例中，步骤401～步骤403的具体实现过程和技术原理请参见图3所示的方法中步骤201～步骤203中的相关描述，此处不再赘述。

步骤404、确定网关本地缓存中的开关状态是否在有效时限内。

步骤405、若不在有效时限内，则查询应用模块在数据库中存储的开关状态。

步骤406、若在有效时限内，则查询应用模块在网关本地缓存中的开关状态。

步骤407、若开关状态为关闭状态，则拦截访问请求。

本实施例中，如上述实施例描述可以在gateway上设计一个本地缓存，将App模块的开关状态缓存在gateway服务内部，这样就不用每次都去数据库中查询了。但本地缓存的时间有效期需要考虑一下，时间不能太久，例如设置为1分钟，这样本地缓存中的数据在1分钟后会自动失效。当本地缓存失效后，gateway会再次从数据库中获取App的最新开关状态，保存在本地缓存中。通过在gateway上设置本地缓存，提高App模块的校验性能。当SaaS系统接收针对应用模块的访问请求，首先确定网关本地缓存中的开关状态是否在有效时限内。若不在有效时限内，则查询应用模块在数据库中存储的开关状态。若在有效时限内，则查询应用模块在网关本地缓存中的开关状态。然后，根据开关状态，判断是拦截访问请求，还是向用户端反馈针对访问请求的业务处理结果。对访问请求的拦截与放行详见图3所示的实施例描述，此处不再赘述。

可选地，在拦截访问请求之后，还包括：向用户端发送无法访问提示信息，和/或在SaaS系统portal页面上将对应的应用模块置为无法访问状态。

具体地，如果用户请求的App模块状态为关闭，在gateway服务中会拦截本次请求，给前端返回错误提示信息。为了避免用户再次发出对这个App模块的请求，除了给前端返回错误信息告知用户请求的App已经下线，还要通知前端刷新App模块的图标，置为灰色不能点击，这样用户就不会再次访问这个App模块了。

本实施例，应用在包含网关和数据库的SaaS系统中，数据库用于存储应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；通过确定存在数据泄露的应用模块；在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。从而可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

另外，本实施例还可以根据网关本地缓存中的开关状态是否在有效时限内，确定开关状态获取来源。并根据查询到的开关状态，判断是拦截访问请求，还是向用户端反馈针对访问请求的业务处理结果。从而可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

图6为本公开根据一示例实施例示出的应用模块的处理装置的结构示意图。如图6所示，应用在包含网关和数据库的SaaS系统中，数据库用于存储应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；应用模块的处理装置50包括：

确定模块51，用于确定存在数据泄露的应用模块；

设置模块52，用于在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。

本实施例提供的装置，可以用于执行图2所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

本实施例，应用在包含网关和数据库的SaaS系统中，数据库用于存储应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；通过确定存在数据泄露的应用模块；在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。从而可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

在图6所示实施例的基础上，图7为本公开根据另一示例实施例示出的应用模块的处理装置的结构示意图，如图7所示，本实施例提供的应用模块的处理装置50，还包括：

预处理模块53，用于：

在网关上注册各个应用模块的开关，并将各个应用模块的开关状态存储到数据库中。

在一种可能的设计中，还包括：

接收模块54，用于接收针对应用模块的访问请求；

查询模块55，用于查询应用模块在数据库中存储的开关状态；

拦截模块56，用于在开关状态为关闭状态时，拦截访问请求；

反馈模块57，用于在开关状态为启用状态时，向用户端反馈针对访问请求的业务处理结果。

在一种可能的设计中，还包括：

接收模块54，用于接收针对应用模块的访问请求；

查询模块55，用于查询应用模块在网关本地缓存中的开关状态；

拦截模块56，用于开关状态为关闭状态，拦截访问请求。

在一种可能的设计中，还包括：

接收模块54，用于接收针对应用模块的访问请求；

确定模块51，用于确定网关本地缓存中的开关状态是否在有效时限内；

查询模块55，用于在网关本地缓存中的开关状态不在有效时限内时，查询应用模块在数据库中存储的开关状态；以及在网关本地缓存中的开关状态有效时限内时，查询应用模块在网关本地缓存中的开关状态；

拦截模块56，用于开关状态为关闭状态时，拦截访问请求。

在一种可能的设计中，在拦截访问请求之后，还包括：

显示模块58，用于向用户端发送无法访问提示信息，和/或在SaaS系统portal页面上将对应的应用模块置为无法访问状态。

在一种可能的设计中，设置模块52，还用于：

在数据泄露解除之后，将数据库中应用模块的开关状态设置为启用状态，以使得应用模块在SaaS系统中重新上线。

本实施例提供的装置，可以用于执行图2、图3、图4、图5所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

本实施例，应用在包含网关和数据库的SaaS系统中，数据库用于存储应用模块的开关状态；网关用于注册应用模块，并根据开关状态处理针对应用模块的访问请求；通过确定存在数据泄露的应用模块；在数据库中将应用模块的开关状态设置为关闭状态，以使得应用模块在SaaS系统中下线。从而可以通过修改应用模块在数据库中的开关状态，实现对应用模块的下线功能，使得其他未下线的应用模块不受影响。

图8为本公开根据一示例实施例示出的电子设备的结构示意图。如图8所示，本实施例提供的一种电子设备60，包括：

处理器601；以及，

存储器602，用于存储处理器的可执行指令，该存储器还可以是flash(闪存)；

其中，处理器601配置为经由执行可执行指令来执行上述方法中的各个步骤。具体可以参见前面方法实施例中的相关描述。

可选地，存储器602既可以是独立的，也可以跟处理器601集成在一起。

当存储器602是独立于处理器601之外的器件时，电子设备60，还可以包括：

总线603，用于连接处理器601以及存储器602。

本实施例还提供一种可读存储介质，可读存储介质中存储有计算机程序，当电子设备的至少一个处理器执行该计算机程序时，电子设备执行上述的各种实施方式提供的方法。

本实施例还提供一种程序产品，该程序产品包括计算机程序，该计算机程序存储在可读存储介质中。电子设备的至少一个处理器可以从可读存储介质读取该计算机程序，至少一个处理器执行该计算机程序使得电子设备实施上述的各种实施方式提供的方法。

最后应说明的是：以上各实施例仅用以说明本公开的技术方案，而非对其限制；尽管参照前述各实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例技术方案的范围。

Claims (10)

1.一种应用模块的处理方法，其特征在于，应用在包含网关和数据库的SaaS系统中，所述数据库用于存储各个应用模块的开关状态；所述网关用于注册应用模块，并根据所述开关状态处理针对所述应用模块的访问请求；所述方法包括：

确定存在数据泄露的应用模块；

在数据库中将所述应用模块的开关状态设置为关闭状态，以使得所述应用模块在SaaS系统中下线。

2.根据权利要求1所述的方法，其特征在于，在确定存在数据泄露的应用模块之前，还包括：

在网关上注册各个应用模块的开关，并将各个应用模块的开关状态存储到数据库中。

3.根据权利要求1所述的方法，其特征在于，还包括：

接收针对应用模块的访问请求；

查询所述应用模块在数据库中存储的开关状态；

若所述开关状态为关闭状态，则拦截所述访问请求；

若所述开关状态为启用状态，则向用户端反馈针对所述访问请求的业务处理结果。

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

接收针对应用模块的访问请求；

查询所述应用模块在网关本地缓存中的开关状态；

若所述开关状态为关闭状态，则拦截所述访问请求。

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

接收针对应用模块的访问请求；

确定网关本地缓存中的开关状态是否在有效时限内；

若不在有效时限内，则查询所述应用模块在数据库中存储的开关状态；

若在有效时限内，则查询所述应用模块在网关本地缓存中的开关状态；

若所述开关状态为关闭状态，则拦截所述访问请求。

6.根据权利要求3-5中任一项所述的方法，其特征在于，在拦截所述访问请求之后，还包括：

向用户端发送无法访问提示信息，和/或在SaaS系统portal页面上将对应的所述应用模块置为无法访问状态。

7.根据权利要求1所述的方法，其特征在于，还包括：

在数据泄露解除之后，将所述数据库中所述应用模块的开关状态设置为启用状态，以使得所述应用模块在SaaS系统中重新上线。

8.一种应用模块的处理装置，其特征在于，应用在包含网关和数据库的SaaS系统中，所述数据库用于存储各个应用模块的开关状态；所述网关用于注册应用模块，并根据所述开关状态处理针对所述应用模块的访问请求；所述装置包括：

确定模块，用于确定存在数据泄露的应用模块；

设置模块，用于在数据库中将所述应用模块的开关状态设置为关闭状态，以使得所述应用模块在SaaS系统中下线。

9.一种电子设备，其特征在于，包括：

处理器；以及，

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至7中任一项所述应用模块的处理方法。

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

Images