CN115086176B - 基于SpringCloud微服务技术实现服务治理策略动态下发的系统 - Google Patents

Abstract

本申请涉及一种基于SpringCloud微服务技术实现服务治理策略动态下发的系统，属于云计算技术领域，其包括：策略配置端通过web页面获取动态配置的服务治理策略；将服务治理策略转换为服务治理指令，并将服务治理指令存储至预设存储端；预设存储端用于接收并存储服务治理指令；安装在各个微服务中的监听程序用于实时监听预设存储端的服务治理指令，并在监听到服务治理指令的情况下按照服务治理指令更新对应的微服务的服务治理策略；微服务基于SpringCloud微服务技术搭建，并与监听程序通信相连；可以解决传统的SpringCloud微服务系统配置服务治理策略比较复杂、效率较低的问题；可以提高策略配置的效率。

Description

基于SpringCloud微服务技术实现服务治理策略动态下发的 系统

技术领域

本申请涉及一种基于SpringCloud微服务技术实现服务治理策略动态下发的系统，属于云计算技术领域。

背景技术

目前，在企业中JAVA体系一般会使用SpringCloud作为微服务框架。其中，SpringCloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud将已经开发出的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

目前，使用微服务可以应对突发的业务量激增。如果访问量大可以通过拓容应对，当业务激增时可以通过负载均衡、容错、访问权限来保证服务稳定运行。

但是，目前负载均衡、容错、访问权限的设置只能通过配置人员在系统中手动写入配置来完成，并且需要手动重启应用服务，这样，会导致策略配置的效率较低的问题，从而负载均衡、容错、访问权限等功能在实际的生产环境中使用成本和风险大大提高。

发明内容

本申请提供了一种基于SpringCloud微服务技术实现服务治理策略动态下发的系统，可以解决传统的SpringCloud微服务系统无法动态下发负载均衡策略，使得服务无法根据业务量来动态设置负载均衡策略的问题、以及传统的SpringCloud微服务系统不支持动态下发服务容错指令，在大量交易到来时候无法根据容错能力来保护业务的成果性和系统的稳定性的问题、以及传统的SpringCloud微服务系统不能对服务的调用方进行身份校验，对所有服务都开放访问权限，当服务数量增多、业务复杂时不能保证服务的安全性的问题。基于此，本申请提供如下技术方案：

提供一种基于SpringCloud微服务技术实现服务治理策略动态下发的系统，所述系统包括：

策略配置端，用于通过web页面获取动态配置的服务治理策略；将所述服务治理策略转换为服务治理指令，并将所述服务治理指令存储至预设存储端；

所述预设存储端，与所述策略配置端通信相连，用于接收并存储所述服务治理指令；

安装在各个微服务中的监听程序，与所述预设存储端通信相连，用于实时监听所述预设存储端的服务治理指令，并在监听到所述服务治理指令的情况下，按照所述服务治理指令更新对应的微服务的服务治理策略；

其中，所述微服务基于SpringCloud微服务技术搭建，并与所述监听程序通信相连。

可选地，所述服务治理策略包括更新后的负载均衡策略，相应地，所述服务治理指令包括负载均衡指令，所述微服务包括与服务治理组件通信相连的第一微服务；所述第一微服务用于按照负载均衡策略提供负载均衡服务；

所述监听程序，用于：

在监听到所述负载均衡指令的情况下，获取所述负载均衡指令指示的服务接口，所述服务接口用于关联所述第一微服务；

对所述负载均衡指令进行翻译，得到所述负载均衡策略；

通过所述服务接口将所述第一微服务之前存储的负载均衡策略更新为所述更新后的负载均衡策略。

可选地，所述第一微服务，还用于：

获取依赖服务列表，所述依赖服务列表包括所述第一微服务所依赖的第二微服务；

基于所述依赖服务列表和所述更新后的负载均衡策略循环更新所述第二微服务中之前存储的负载均衡策略。

可选地，所述第一微服务，还用于：

在获取所述依赖服务列表之前，确定所述负载均衡指令的指令类型；

在所述指令类型指示更新所有关联的微服务的情况下，触发执行所述获取依赖服务列表的步骤；并在获取所述依赖服务列表后触发执行所述基于所述依赖服务列表和所述更新后的负载均衡策略循环更新所述第二微服务中之前存储的负载均衡策略的步骤；

在所述指令类型指示更新当前微服务的情况下，不执行所述获取依赖服务列表的步骤、且不执行所述基于所述依赖服务列表和所述更新后的负载均衡策略循环更新所述第二微服务中之前存储的负载均衡策略的步骤。

可选地，所述服务治理策略包括更新后的访问控制策略，相应地，所述服务治理指令包括访问控制指令，所述微服务包括支持相互调用的第三微服务和第四微服务；

所述第三微服务中的监听程序，用于在监听到所述访问控制指令的情况下，获取所述访问控制指令中的访问白名单；

所述第四微服务中的监听程序，用于拦截所述第四微服务对所述第三微服务的调用请求；将用户预先配置的服务标识携带在所述调用请求中，得到更新后的调用请求，并将所述更新后的调用请求发送至所述第三微服务；

所述第三微服务中的监听程序，还用于拦截所述第四微服务发送的所述更新后的调用请求；获取所述更新后的调用请求中的服务标识；将所述服务标识与所述访问白名单进行比较，以确定是否允许所述第四微服务调用；在不允许所述第四微服务调用的情况下，向所述第四微服务发送拒绝访问通知。

可选地，所述调用请求为基于HTTP协议发送的请求，所述将用户预先配置的服务标识携带在所述调用请求中，包括：

将所述服务标识携带在所述调用请求的http请求头中。

可选地，所述服务治理策略包括更新后的IP校验策略，相应地，所述服务治理指令包括IP校验指令，所述微服务包括支持相互访问的第五微服务和第六微服务；

所述第五微服务中的监听程序，用于在监听到所述IP校验指令的情况下，获取所述IP校验指令中的IP地址白名单；

所述第六微服务中的监听程序，用于拦截所述第六微服务对所述第五微服务的访问请求；将用户预先配置的IP地址携带在所述访问请求中，得到更新后的访问请求，并将所述更新后的访问请求发送至所述第五微服务；

所述第五微服务中的监听程序，还用于拦截所述第六微服务发送的所述更新后的访问请求；获取所述更新后的访问请求中的IP地址；将所述IP地址与所述IP地址白名单进行比较，以进行IP地址的校验；在所述IP地址校验不通过的情况下，向所述第六微服务发送IP地址校验不通过的通知。

可选地，所述监听程序，还用于：

在监听到所述服务治理指令的情况下，进行所述服务治理指令的同步；

对同步完成的服务治理指令进行解析，得到对应的微服务能够识别的待发布的服务治理策略。

可选地，所述策略配置端，用于：

响应于配置策略请求，显示所述web页面，所述web页面显示有用户可读的策略输入选项；

接收用户通过所述策略输入选项输入的服务治理策略。

本申请的有益效果至少包括：策略配置端通过web页面获取动态配置的服务治理策略；将服务治理策略转换为服务治理指令，并将服务治理指令存储至预设存储端；预设存储端与策略配置端通信相连，用于接收并存储服务治理指令；安装在各个微服务中的监听程序与预设存储端通信相连，用于实时监听预设存储端的服务治理指令，并在监听到服务治理指令的情况下，按照服务治理指令更新对应的微服务的服务治理策略；其中，微服务基于SpringCloud微服务技术搭建，并与监听程序通信相连；可以解决传统的SpringCloud微服务系统配置服务治理策略比较复杂、效率较低的问题；由于策略配置端使用在线页面化管理，无需对原始的SpringCloud微服务系统中的业务进行改造，即可实现服务治理策略的动态配置，可以提高策略配置的效率。同时，在使用微服务治理能力时可以更加的直观和通用，普通运维人员在不懂微服务治理的前提下，也能对其进行设置和应用，可以降低学习成本。

另外，通过使用在线治理策略下发方案，使用户在线上使用起来更加便捷安全，减少了策略配置的出错频率，提高了策略配置的效率。

另外，由于采用了实时监听指令下发的方式，每个微服务从用户发起指令到实际应用生效，可以控制在毫秒以内，在实际的场景中可以减少服务的压力并保证服务的正常运行。

另外，本实施例提供的策略动态下发系统对于存储方面没有硬性要求，微服务几乎无需改造，可以提高方案的可行性。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，并可依照说明书的内容予以实施，以下以本申请的较佳实施例并配合附图详细说明如后。

附图说明

图1是本申请一个实施例提供的基于SpringCloud微服务技术实现服务治理策略动态下发的系统的结构示意图；

图2是本申请一个实施例提供的web页面的示意图；

图3是本申请一个实施例提供的负载均衡策略动态下发的示意图；

图4是本申请一个实施例提供的访问控制策略下发的示意图。

具体实施方式

下面结合附图和实施例，对本申请的具体实施方式做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。

首先，对于本申请涉及的若干名词进行介绍。

超文本传输协议（Hypertext Transfer Protocol，HTTP）：旨在启用客户端和服务器之间的通信，HTTP充当客户端和服务器之间的请求-响应协议。

代表状态转移（Representational State Transfer，REST）：描述了一个架构样式的网络系统，比如web应用程序。在目前主流的三种Web服务交互方案中，REST相比于简单对象访问协议（Simple Object Access protocol，SOAP）以及远程过程调用XML-RPC（远程过程调用，remote procedure call）更加简单明了，无论是对统一资源定位系统（uniformresource locator，URL）的处理还是对载荷（Payload）的编码，REST都倾向于用更加简单轻量的方法设计和实现。REST并没有一个明确的标准，而更像是一种设计的风格。

微服务(Micro Service)：一种软件开发技术，是面向服务的体系结构（SOA）架构样式的一种变体。主要思想是将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful接口）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。

负载均衡（Load Balance）：就是将任务分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

访问控制（Access Control）：是按用户身份及其所归属的某项定义组来限制用户对某些信息项的访问，或限制对某些控制功能的使用的一种技术。

传统的Spring Cloud是一个基于Spring Boot实现的微服务架构开发工具。它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。Spring Cloud包含了多个子项目，如：

服务治理组件Eureka：包含服务注册中心、服务注册与发现机制的实现。服务治理组件包括注册中心Eureka server、生产者Eureka Client和消费者Eureka Client。其中，生产者负责提供保存的服务；Eureka Client负责将服务发送到注册中心，由注册中心负责保存；消费者就是用户，用户在客户端输入访问地址（地址服务），如果在注册中心有服务，就去访问；如果在注册中心没有该服务，就报错。

容错管理组件Hystrix：实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力。Hystrix会在某个服务连续调用N次不响应的情况下，立即通知调用端调用失败，避免调用端持续等待而影响了整体服务，执行本地业务。Hystrix间隔时间会再次检查此服务，如果服务恢复将继续提供服务。Hystrix间隔几秒会让其中一个请求去调用远程微服务，如果调用成功，就表示服务正常，后面就重新链接。

客户端负载均衡的服务调用组件Ribbon：负责调用负载均衡服务。传统的负载均衡策略为轮询。服务器启动时，先从Eureka server获取服务列表，然后在请求微服务时，通过RestTemplate进行HTTP调用。对于自定义访问策略，配置人员需要自定义一个类, 实现Rule接口，此时，自定义的类就是一个策略类。由此可知，对于自定义访问策略的场景，需要配置人员在微服务系统中重新进行配置。

网关组件GateWay：主要功能是路由转发和过滤器。路由功能是微服务的一部分，GateWay默认和Ribbon结合实现了负载均衡的功能。GateWay的作用包括但不限于：限流处理、认证和授权、单点登录和日志管理等。

基于上述内容可知，传统的基于SpringCloud微服务技术实现的微服务系统中通常已经配置有服务治理策略，若需要对这些服务治理策略进行更新，则配置人员需要在微服务系统中进行代码配置，才能实现对访问控制、负载均衡、容错等策略进行修改，一般地，代码配置完成后，系统中的各个微服务需要重启才能生效。

基于上述技术问题，本申请提供一种业务无感知、代码无需变动，只是基于原生的内容做增强的基于SpringCloud微服务技术实现服务治理策略动态下发的系统，该系统通过web页面进行参数化梳理，下发指令到对应的业务中去，通过对指令更新达到负载策略、容错策略、访问控制的效果，微服务内部会做指令解析识别，指令更新操作。

下面，对本申请提供的基于SpringCloud微服务技术实现服务治理策略动态下发的系统进行详细介绍。

图1是本申请一个实施例提供的基于SpringCloud微服务技术实现服务治理策略动态下发的系统的结构示意图。该系统至少包括：策略配置端110、预设存储端120和监听程序130。

策略配置端110是指配置服务治理策略的配置人员使用的电子设备，该电子设备具有通信能力、且支持HTTP协议，该电子设备包括但不限于：手机、计算机、平板电脑等，本实施例不对策略配置端110的实现方式作限定。

本实施例中，策略配置端110是独立于基于SpringCloud微服务技术建立的微服务系统之外的电子设备，配置人员通过该策略配置端110实现对该微服务系统中的策略进行动态配置。策略配置端110的功能主要包括：优化参数语义，将负载均衡、容错、访问控制等策略翻译成通俗易懂的行业术语和参数。策略配置端110还用于接收用户请求，将请求指令发送到预设存储端120中。

具体地，策略配置端110用于：通过web页面获取动态配置的服务治理策略；将服务治理策略转换为服务治理指令，并将服务治理指令存储至预设存储端120。

策略配置端110在通过web页面获取服务治理策略之前，需要基于用户请求显示web页面。此时，策略配置端110，还用于：响应于配置策略请求，显示web页面，该web页面显示有用户可读的策略输入选项；接收用户通过策略输入选项输入的服务治理策略。

以图2所示的web页面为例进行说明，图2中以服务治理策略包括负载均衡策略为例进行说明，负载均衡策略包括以下策略参数：最大连接数、主机的最大连接数、和同步应用列表间隔，相应地，在web页面中包括最大连接数的策略输入选项、主机的最大连接数的策略输入选项和同步应用列表间隔的策略输入选项。其中，各个策略输入选项显示的信息能够使用户直接确定出该选项的含义，而不仅仅是对专门的代码开发人员可读。

在web页面中还可以包括其它内容，比如：微服务系统的名称选择控件、微服务系统中微服务的名称选择控件、负载均衡器的选择控件、负载均衡策略的策略选择控件等，本实施例不对web页面包括的内容作限定。

策略配置端基于预设的指令转换关系将服务治理策略转换为服务治理指令，以将服务治理策略转换成程序可识别的代码策略。换言之，策略配置端中预存有服务治理策略和服务治理指令之间的指令转换关系，基于该指令转换关系，可以将用户输入的服务治理策略转换为服务治理指令。

比如：用户从web端发送一个负载均衡策略，最终web页面将这个治理策略转成：

test-provider.ribbon.NFLoadBalancerClassName= com.netflix.loadbalancer.DynamicServerListLoadBalancer；

test-provider.ribbon.NFLoadBalancerRuleClassName= com.netflix.loadbalancer.RoundRobinRule；

test-provider.ribbon.NFLoadBalancerPingClassName= com.netflix.niws.loadbalancer.NIWSDiscoveryPing；

test-provider.ribbon.NIWSServerListClassName= com.netflix.loadbalancer.ConfigurationBasedServerList；

test-provider.ribbon.NIWSServerListFilterClassName= com.netflix.loadbalancer.ZoneAffinityServerListFilter。

将以上这个代码放到web页面中placeholder属性中，指令转换关系会生效。

可选地，在服务治理策略包括至少两种的情况下，不同服务治理策略对应的服务治理指令的指令内容不同。具体地，不同服务治理策略对应的服务治理指令中包括用于指示指令类型的指令内容，不同服务治理策略对应的指令类型不同。

比如：负载均衡策略对应的服务治理指令为：ribbon.NFLoadBalancerClassName；熔断策略对应的服务治理指令为：command.default.serviceFallback；这两条指令中“ribbon”用于指示指令类型，该指令类型为负载均衡策略的服务治理指令；“default”用于指示指令类型，该指令类型为熔断策略的服务治理指令。

预设存储端120与策略配置端110通信相连，用于接收并存储服务治理指令。预设存储端120也可以称为存储介质，该预设存储端120可以是数据库（data base，DB）、或者也可以是其它具有存储功能的设备，本实施例不对预设存储端120的实现方式作限定。

本实施例中，预设存储端120的主要作用是用于存储策略配置端110发送的服务治理指令。当有数据存进来时，预设存储端120可以主动推送数据到响应的应用中去。

监听程序130安装在各个微服务中，并与预设存储端120通信相连。其中，微服务基于SpringCloud微服务技术搭建，并与监听程序130通信相连。

监听程序130集成在软件开发工具包（Software Development Kit，sdk）中，集成以后，在各个微服务的程序启动以后，该监听程序130会和预设存储端120建立一个http长连接，如果预设存储端120中的配置变动会通过该长连接通知到监听程序130，监听程序130会进行配置拉取。

具体地，监听程序130用于实时监听预设存储端120的服务治理指令，并在监听到服务治理指令的情况下，按照服务治理指令更新对应的微服务的服务治理策略。

监听程序130，还用于在监听到服务治理指令的情况下，进行服务治理指令的同步；对同步完成的服务治理指令进行解析，得到对应的微服务能够识别的待发布的服务治理策略。之后，触发执行按照服务治理指令更新对应的微服务的服务治理策略的步骤。

对服务治理指令进行同步用于防止数据冲突问题。指令同步方式可以通过等待进程的列表实现。

对服务治理指令进行解析包括但不限于：解析服务治理指令的指令内容、解析服务治理指令关联的微服务等，本实施例不对解析的内容作限定。

可选地，服务治理策略包括但不限于：更新后的负载均衡策略、更新后的访问控制策略和更新后的IP校验策略。下面对各个服务治理策略的更新方式作限定。

第一、服务治理策略包括更新后的负载均衡策略，相应地，服务治理指令包括负载均衡指令。此时，微服务包括与服务治理组件通信相连的第一微服务；第一微服务用于按照负载均衡策略提供负载均衡服务。一般地，第一微服务安装有Ribbon，且为负载均衡服务的提供者。

相应地，监听程序130，用于：在监听到负载均衡指令的情况下，获取负载均衡指令指示的服务接口，该服务接口用于关联第一微服务；对负载均衡指令进行翻译，得到负载均衡策略；通过服务接口将第一微服务之前存储的负载均衡策略更新为更新后的负载均衡策略。

第一微服务基于预设的负载均衡指令和负载均衡策略之间的转换关系，对负载均衡指令进行翻译，得到负载均衡策略。

比如：图2中，负载均衡策略中最大连接数对应的负载均衡指令为：ribbon.MaxConnectionsPerHost；主机最大连接数对应的负载均衡指令为：ribbon.MaxTotalConnections；同步应用列表间隔对应的负载均衡指令为：ribbon.ServerListRefreshInterval。

可选地，第一微服务还可以对所依赖的各个第二微服务的负载均衡策略进行更新。具体地，第一微服务，还用于：获取依赖服务列表；基于依赖服务列表和更新后的负载均衡策略循环更新第二微服务中之前存储的负载均衡策略。

其中，依赖服务列表包括第一微服务所依赖的第二微服务。具体地，依赖服务列表包括第二微服务预先注册在注册中心的名称。

由于第一微服务可能仅需要对自身的负载均衡策略进行更新，基于此，第一微服务，还用于：在获取依赖服务列表之前，确定负载均衡指令的指令类型；在指令类型指示更新所有关联的微服务的情况下，触发执行获取依赖服务列表的步骤；并在获取依赖服务列表后触发执行基于依赖服务列表和更新后的负载均衡策略循环更新第二微服务中之前存储的负载均衡策略的步骤；在指令类型指示更新当前微服务的情况下，不执行获取依赖服务列表的步骤、且不执行基于依赖服务列表和更新后的负载均衡策略循环更新第二微服务中之前存储的负载均衡策略的步骤。

具体地，参考图3，第一微服务的监听程序130监听到负载均衡指令后，基于该负载均衡指令中的服务接口关联当前的第一微服务；之后，第一微服务确定该负载均衡指令的指令类型，在指令类型指示更新所有关联的微服务的情况下，从服务治理组件的注册中心获取依赖服务列表，根据该依赖服务列表循环更新各个第二微服务的负载均衡策略，并更新第一微服务的负载均衡策略。具体地，可以是修改第二微服务和第一微服务中loadbalance属性中的rule值。在指令类型指示更新当前的微服务的情况下，更新第一微服务的负载均衡策略。

第二、服务治理策略包括更新后的访问控制策略，相应地，服务治理指令包括访问控制指令，微服务包括支持相互调用的第三微服务和第四微服务。

相应地，参考图4，第三微服务41中的监听程序130，用于在监听到访问控制指令的情况下，获取访问控制指令中的访问白名单。

访问白名单中设置有允许调用第三微服务的各个微服务的名称。

第四微服务42中的监听程序130，用于拦截第四微服务对第三微服务的调用请求；将用户预先配置的服务标识携带在调用请求中，得到更新后的调用请求，并将更新后的调用请求发送至第三微服务。

第三微服务41中的监听程序130，还用于拦截第四微服务发送的更新后的调用请求；获取更新后的调用请求中的服务标识；将服务标识与访问白名单进行比较，以确定是否允许第四微服务调用；在不允许第四微服务调用的情况下，向第四微服务发送拒绝访问通知。

在允许第四微服务调用的情况下，第四微服务向第三微服务发送调用请求指示的调用内容。

在一个示例中，调用请求为基于HTTP协议发送的请求，将用户预先配置的服务标识携带在调用请求中，包括：将服务标识携带在调用请求的http请求头中。

其中，将服务标识与访问白名单进行比较，以确定是否允许第四微服务调用，包括：在访问白名单包括第四微服务的服务标识的情况下，允许第四微服务调用；在访问白名单不包括第四微服务的服务标识的情况下，不允许第四微服务调用。

同理，在其它实施例中，访问控制指令也可以携带访问黑名单，以记录不允许调用第三微服务的微服务的服务标识。

第三、服务治理策略包括更新后的IP校验策略，相应地，服务治理指令包括IP校验指令，微服务包括支持相互访问的第五微服务和第六微服务。

第五微服务中的监听程序，用于在监听到IP校验指令的情况下，获取IP校验指令中的IP地址白名单；

第六微服务中的监听程序，用于拦截第六微服务对第五微服务的访问请求；将用户预先配置的IP地址携带在访问请求中，得到更新后的访问请求，并将更新后的访问请求发送至第五微服务；

第五微服务中的监听程序，还用于拦截第六微服务发送的更新后的访问请求；获取更新后的访问请求中的IP地址；将IP地址与IP地址白名单进行比较，以进行IP地址的校验；在IP地址校验不通过的情况下，向第六微服务发送IP地址校验不通过的通知。

根据上述过程可知，IP校验策略的实现原理与访问控制策略的实现原理相同，本实施例在此不再赘述。

综上所述，本实施例提供的基于SpringCloud微服务技术实现服务治理策略动态下发的系统，策略配置端通过web页面获取动态配置的服务治理策略；将服务治理策略转换为服务治理指令，并将服务治理指令存储至预设存储端；预设存储端与策略配置端通信相连，用于接收并存储服务治理指令；安装在各个微服务中的监听程序与预设存储端通信相连，用于实时监听预设存储端的服务治理指令，并在监听到服务治理指令的情况下，按照服务治理指令更新对应的微服务的服务治理策略；其中，微服务基于SpringCloud微服务技术搭建，并与监听程序通信相连；可以解决传统的SpringCloud微服务系统配置服务治理策略比较复杂、效率较低的问题；由于策略配置端使用在线页面化管理，无需对原始的SpringCloud微服务系统中的业务进行改造，即可实现服务治理策略的动态配置，可以提高策略配置的效率。同时，在使用微服务治理能力时可以更加的直观和通用，普通运维人员在不懂微服务治理的前提下，也能对其进行设置和应用，可以降低学习成本。

另外，通过使用在线治理策略下发方案，使用户在线上使用起来更加便捷安全，减少了策略配置的出错频率，提高了策略配置的效率。

另外，由于采用了实时监听指令下发的方式，每个微服务从用户发起指令到实际应用生效，可以控制在毫秒以内，在实际的场景中可以减少服务的压力并保证服务的正常运行。

另外，本实施例提供的策略动态下发系统对于存储方面没有硬性要求，微服务几乎无需改造，可以提高方案的可行性。

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

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

Claims (9)

1.一种基于SpringCloud微服务技术实现服务治理策略动态下发的系统，其特征在于，所述系统包括：

策略配置端，用于通过web页面获取动态配置的服务治理策略；将所述服务治理策略转换为服务治理指令，并将所述服务治理指令存储至预设存储端；

所述预设存储端，与所述策略配置端通信相连，用于接收并存储所述服务治理指令；

安装在各个微服务中的监听程序，与所述预设存储端通信相连，用于实时监听所述预设存储端的服务治理指令，并在监听到所述服务治理指令的情况下，按照所述服务治理指令更新对应的微服务的服务治理策略；

其中，所述微服务基于SpringCloud微服务技术搭建，并与所述监听程序通信相连。

2.根据权利要求1所述的系统，其特征在于，所述服务治理策略包括更新后的负载均衡策略，相应地，所述服务治理指令包括负载均衡指令，所述微服务包括与服务治理组件通信相连的第一微服务；所述第一微服务用于按照负载均衡策略提供负载均衡服务；

所述监听程序，用于：

在监听到所述负载均衡指令的情况下，获取所述负载均衡指令指示的服务接口，所述服务接口用于关联所述第一微服务；

对所述负载均衡指令进行翻译，得到所述负载均衡策略；

通过所述服务接口将所述第一微服务之前存储的负载均衡策略更新为所述更新后的负载均衡策略。

3.根据权利要求2所述的系统，其特征在于，所述第一微服务，还用于：

获取依赖服务列表，所述依赖服务列表包括所述第一微服务所依赖的第二微服务；

基于所述依赖服务列表和所述更新后的负载均衡策略循环更新所述第二微服务中之前存储的负载均衡策略。

4.根据权利要求3所述的系统，其特征在于，所述第一微服务，还用于：

在获取所述依赖服务列表之前，确定所述负载均衡指令的指令类型；

在所述指令类型指示更新所有关联的微服务的情况下，触发执行所述获取依赖服务列表的步骤；并在获取所述依赖服务列表后触发执行所述基于所述依赖服务列表和所述更新后的负载均衡策略循环更新所述第二微服务中之前存储的负载均衡策略的步骤；

在所述指令类型指示更新当前微服务的情况下，不执行所述获取依赖服务列表的步骤、且不执行所述基于所述依赖服务列表和所述更新后的负载均衡策略循环更新所述第二微服务中之前存储的负载均衡策略的步骤。

5.根据权利要求1所述的系统，其特征在于，所述服务治理策略包括更新后的访问控制策略，相应地，所述服务治理指令包括访问控制指令，所述微服务包括支持相互调用的第三微服务和第四微服务；

所述第三微服务中的监听程序，用于在监听到所述访问控制指令的情况下，获取所述访问控制指令中的访问白名单；

所述第四微服务中的监听程序，用于拦截所述第四微服务对所述第三微服务的调用请求；将用户预先配置的服务标识携带在所述调用请求中，得到更新后的调用请求，并将所述更新后的调用请求发送至所述第三微服务；

所述第三微服务中的监听程序，还用于拦截所述第四微服务发送的所述更新后的调用请求；获取所述更新后的调用请求中的服务标识；将所述服务标识与所述访问白名单进行比较，以确定是否允许所述第四微服务调用；在不允许所述第四微服务调用的情况下，向所述第四微服务发送拒绝访问通知。

6.根据权利要求5所述的系统，其特征在于，所述调用请求为基于HTTP协议发送的请求，所述将用户预先配置的服务标识携带在所述调用请求中，包括：

将所述服务标识携带在所述调用请求的http请求头中。

7.根据权利要求1所述的系统，其特征在于，所述服务治理策略包括更新后的IP校验策略，相应地，所述服务治理指令包括IP校验指令，所述微服务包括支持相互访问的第五微服务和第六微服务；

所述第五微服务中的监听程序，用于在监听到所述IP校验指令的情况下，获取所述IP校验指令中的IP地址白名单；

所述第六微服务中的监听程序，用于拦截所述第六微服务对所述第五微服务的访问请求；将用户预先配置的IP地址携带在所述访问请求中，得到更新后的访问请求，并将所述更新后的访问请求发送至所述第五微服务；

所述第五微服务中的监听程序，还用于拦截所述第六微服务发送的所述更新后的访问请求；获取所述更新后的访问请求中的IP地址；将所述IP地址与所述IP地址白名单进行比较，以进行IP地址的校验；在所述IP地址校验不通过的情况下，向所述第六微服务发送IP地址校验不通过的通知。

8.根据权利要求1至6任一所述的系统，其特征在于，所述监听程序，还用于：

在监听到所述服务治理指令的情况下，进行所述服务治理指令的同步；

对同步完成的服务治理指令进行解析，得到对应的微服务能够识别的待发布的服务治理策略。

9.根据权利要求1至6任一所述的系统，其特征在于，所述策略配置端，用于：

响应于配置策略请求，显示所述web页面，所述web页面显示有用户可读的策略输入选项；

接收用户通过所述策略输入选项输入的服务治理策略。

Images