CN112506709A - 微服务治理方法及装置 - Google Patents

Abstract

本发明公开了一种微服务治理方法及装置，所述方法包括：通过预定义YAML模板将微服务注册请求发送到注册中心，当所述微服务注册成功时，对所述微服务根据其治理策略类型进行配置，当调用配置好的微服务时，在无需修改微服务代码的情况下，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器；本发明可以帮助用户专注于业务逻辑的开发，无须考虑微服务治理方面的如负载均衡、熔断治理、限流治理、容错治理和降级治理等代码逻辑，提升用户开发代码的效率，减少代码错误率，并降低复杂度。

Description

微服务治理方法及装置

技术领域

本发明涉及微服务架构技术领域，特别涉及一种微服务治理方法及装置。

背景技术

微服务是指在功能不变的情况下，把一个大型的单个应用程序和服务拆分为多个可管理的服务。每个服务根据自己的需要选择技术栈，互不影响，方便开发、维护，好处是有效的拆分应用，实现敏捷开发和部署。当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。当该类请求越来越多，占用的计算机资源越来越多的时候，会导致系统瓶颈出现，造成其他的请求同样不可用，最终导致业务系统崩溃。

为了防止此类问题的出现，微服务在其架构中加入了服务治理相关策略，如服务限流、降级、熔断、容错等。但是这些治理治理策略与微服务代码高度耦合，使得修改微服务治理策略必须修改微服务代码。如此也增加代码维护性难度、运维复杂度。

发明内容

有鉴于此，本发明实施例的目的是提供一种基于K8S和容器化技术的、可视化的，且能够降低开发复杂度的微服务治理方法及装置。

为了实现上述目的，本发明实施例提供了一种微服务治理方法，包括：

通过预定义YAML模板将微服务注册请求发送到注册中心；

当所述微服务注册成功时，对所述微服务根据其治理策略类型进行配置；

当调用配置好的微服务时，在无需修改微服务代码的情况下，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器。

优选地，通过预定义YAML模板将微服务注册请求发送到注册中心，包括：

向至少两个注册中心分别发送至少两个相同的Eureka容器化实例，以使所述微服务在所述至少两个注册中心进行注册。

优选地，当调用配置好的微服务时，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器，包括：

在无需修改微服务代码的情况下，修改所述微服务的启动命令参数；

其中，所述启动命令参数用于修改微服务应用配置文件中的配置项。

优选地，所述治理策略类型包括以下至少一种：负载均衡、熔断治理、限流治理、容错治理和降级治理。

优选地，所述负载均衡策略包括以下机制：响应时间权值机制、随机机制和轮论机制。

优选地，所述熔断治理策略包括以下参数：熔断时间窗、请求失败率和窗口请求数。

优选地，所述限流治理策略的规则包括：

接收微服务平台发送的触发限流的阈值；其中所述阈值是指每秒请求数量最大值；

计算单位时间内的访问次数；

判断所述单位时间内的访问次数是否超出所述触发限流的阈值，如果超出所述触发限流的阈值，则拒绝后续的请求，直到下一单位时间。

优选地，所述容错治理策略包括以下至少一种：failover策略、failfast策略、failback策略和custome策略。

优选地，所述降级治理策略的规则包括：

当客户端启动熔断治理策略时，所述微服务熔断后回调相应的本地降级处理方法。

本发明实施例还提供一种微服务治理装置，包括：

注册模块，用于通过预定义YAML模板将微服务注册请求发送到注册中心；

配置模块，用于当所述微服务注册成功时，对所述微服务根据其治理策略类型进行配置；

治理模块，用于当调用配置好的微服务时，在无需修改微服务代码的情况下，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器

与现有技术相比，本发明实施例具有以下有益效果：本发明实施例的技术方案通过预定义YAML模板将微服务注册请求发送到注册中心，当所述微服务注册成功时，对所述微服务根据其治理策略类型进行配置，当调用配置好的微服务时，在无需修改微服务代码的情况下，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器；本发明可以帮助用户专注于业务逻辑的开发，无须考虑微服务治理方面的如负载均衡、熔断治理、限流治理、容错治理和降级治理等代码逻辑，提升用户开发代码的效率，减少代码错误率，并降低复杂度。

附图说明

图1为本发明的微服务治理方法的实施例一的流程图；

图2为本发明的微服务治理方法的实施例一的通过注册中心对微服务进行注册的示意图；

图3为本发明的微服务治理方法的实施例一的通过配置中心对微服务进行配置的流程图；

图4为本发明的微服务治理方法的实施例一的微服务通过API网关访问、路由、授权和过滤芯功能的示意图；

图5为本发明的微服务治理方法的实施例二的根据负载均衡策略对微服务进行治理的示意图；

图6为本发明的微服务治理方法的实施例二的根据熔断治理策略对微服务进行治理的示意图；

图7为本发明的微服务治理方法的实施例二的根据限流治理策略对微服务进行治理的示意图；

图8为本发明的微服务治理方法的实施例二的根据容错治理策略对微服务进行治理的示意图；

图9为本发明的微服务治理方法的实施例二的根据降级治理策略对微服务进行治理的示意图；

图10为本发明的微服务治理装置的实施例一的示意图。

具体实施方式

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

在微服务架构中，服务调用由本地调用变成远程调用，服务消费者A需要通过注册中心去查询服务提供者B的地址，然后发起调用。这个看似简单的过程可能会遇到注册中心宕机、服务提供者B有服务宕机、服务消费者A和注册中心网络不通、服务消费者A和服务提供者B网络不通等等多种意外情况，导致服务消费者A不能成功调用服务提供者B，进而由于雪崩效应，引起微服务系统崩溃。

目前，不同厂商的微服务管理平台都围绕以上微服务的核心功能，进行了实现和融合。各个厂商的微服务平台都有不同的复杂度和局限性，并和自身厂商的其他产品联系密切，不具备通用性、操作简易性等特点，微服务治理操作复杂，增加人工运维成本。这里微服务平台必须具备以下两大属性：（1）开发者独立（Developer Independence），平台的开发者是互相独立不依赖的，可以完全独立开发出自己的服务；（2）运行环境独立（RuntimeIndependence），不同微服务的运行时状态是互相独立的，可以理解成运行在不同的容器里。也就是说，一个平台要是具备以上2个属性，那么它就可以定义为微服务平台。本文涉及的微服务平台即具有这种含义。

本发明发明实施例基于容器编排K8S和容器化技术提供微服务平台，面向企业级微服务需求，结合微服务可视化编排治理的需要和自身的DevOps平台、容器云平台及数据平台进行协同和能力聚合，可以实现微服务全生命周期管理服务和可视化治理编排。

本发明实施例基于spring系列框架实现，包括注册中心、配置中心、配置仓库、路由网关、服务提供者、服务消费者、消息总线和客户端；

其中配置仓库用于存放服务配置文件；

配置中心从配置仓库中读取配置，向注册中心发送注册请求，同时向消息总线发送消息；

服务提供者从消息总线接收消息，从配置中心获取配置，向注册中心发送注册请求；

服务消费者从服务提供者调用内部服务，向注册中心发送注册请求；

路由网关从服务消费者调用服务，从消息总线调用服务，向注册中心发送注册请求；

客户端从路由网关调用服务。

在本实施例中，注册中心在服务治理框架中，注册中心采用EurekaServer组件。在分布式系统中，每个服务单元向注册中心登记自己提供的服务，包括服务的主机与端口点的服务注册中心，这样一旦发生了故障，那么整个服务就会瘫痪，所以需要一个高可用的服务注册中心，在Eureka中，可以通过集群来解决这个问题。Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这样就会形成一组互相注册的服务注册中心，进而实现服务清单的互相同步，达到高可用的效果；注册中心包含服务发现模块：在服务治理框架中，服务间的调用不再通过指定具体的实例地址来实现，而是通过服务名发起请求调用实现。服务调用方通过服务名从服务注册中心的服务清单中获取服务实例的列表清单，通过指定的负载均衡策略取出一个服务实例位置来进行服务调用。

图1为本发明的微服务治理方法的实施例一的流程图，如图1所示，本实施例的微服务治理方法，具体可以包括如下步骤：

S101，通过预定义YAML模板将微服务注册请求发送到注册中心。

本发明实施例使用Spring Cloud Eureka实现微服务的注册与发现，微服务平台通过预定义yaml文件模板的方式提供高可用的注册中心服务。

其中，步骤S101包括：A，向至少两个注册中心分别发送至少两个相同的Eureka容器化实例，以使所述微服务在所述至少两个注册中心进行注册。

如图2所示，两个注册中心分别为Eureka Server1和Eureka Server2，客户端Eureka Client分别向两个注册中心进行注册，且随后过程中两个注册中心的注册信息进行互相复制，即Eureka Server1复制Eureka Server2 的Eureka Client信息，EurekaServer2复制Eureka Server1 的Eureka Client信息。这样两个Eureka容器化实例互相注册，以避免单个注册中心宕机的情况。

S102，当所述微服务注册成功时，对所述微服务根据其治理策略类型进行配置。

本发明实施例使用Spring Cloud Config Server与RabbitMQ实现微服务的配置中心和消息总线。微服务平台通过预定义YAML文件模板的方式提供高可用的配置中心和消息总线。配置中心提供Git和本地存储两种类型，配置中心和消息总线分别以2个实例和3个实例的容器化部署方式，避免单一实例宕机导致的配置文件无法及时更新的问题。

如图3所示，为对所述微服务根据其治理策略类型进行配置的流程图。请参考步骤S201至S210，该实施例的执行主体为客户端，首先客户端启动微服务容器，然后向注册中心注册微服务，当微服务注册成功时，向配置中心读取配置信息，并判断是否需要变更配置信息，如果需要变更配置信息，则直接变更配置信息，并向客户端发送已变更配置信息的通知，然后重新启动微服务容器，如果不需要变更配置信息，则直接结束配置流程，当然如果微服务没有注册成功也直接结束本流程。

S103，当调用配置好的微服务时，在无需修改微服务代码的情况下，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器。

其中，步骤S103包括：B，在无需修改微服务代码的情况下，修改所述微服务的启动命令参数；

其中，所述启动命令参数用于修改微服务应用配置文件中的配置项。

另外，本发明实施例通过API网关实现微服的访部等功能，具体是使用SpringCloud Zuul组件实现微服务的统一访问、路由、授权、过滤功能。请参考图4，关于API网关的黑白名单实现原理如下，在k8s的ingress组件中，将客户端的IP存放到请求头X-Forwarded-For中，然后将请求转发给API网关，API网关获取客户端的IP后比对黑白名单规则后确认允许路由请求还是拒绝访问。授权实现原理，API网关对某个服务开启授权机制，访问此服务时API网关会检查客户端请求头中的paas_token，API网关比对token后确认路由请求还是拒绝访问。

本发明实施例的技术方案通过预定义YAML模板将微服务注册请求发送到注册中心，当所述微服务注册成功时，对所述微服务根据其治理策略类型进行配置，当调用配置好的微服务时，在无需修改微服务代码的情况下，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器；本发明可以帮助用户专注于业务逻辑的开发，无须考虑微服务治理方面的如负载均衡、熔断治理、限流治理、容错治理和降级治理等代码逻辑，提升用户开发代码的效率，减少代码错误率，并降低复杂度。

本发明实施例二的微服务治理方法在上述实施例一的基础上，进一步更加详细地介绍本发明的技术方案。

其中，所述治理策略类型包括以下至少一种：负载均衡、熔断治理、限流治理、容错治理和降级治理。

其中，负载均衡策略提供了容器化的同一个服务不同实例之间的访问策略。请参考图5，以治理策略规则重启微服务容器过程如下：用户在微服务治理平台勾选微服务的负载均衡策略，即配置负载均衡策略，然后用户在软件开发过程中无需修改微服务代码，对应的微服务容器会重新启动，平台会自动修改微服务的启动命令参数ribbon.NFLoadBanlancerRuleClassName，参数值为WeightedResponseTimeRule、RandomRule和RoundRobinRule。启动命令参数用于修改微服务应用配置文件中的配置项。

其中，负载均衡提供三种策略，响应时间权值WeightedResponseTimeRule、随机RandomRule和轮询RoundRobinRule。所述负载均衡策略包括以下机制：响应时间权值机制、随机机制和轮询机制。

响应时间权值，是指提供最小活跃数（时延）的权重路由，支持业务处理慢的服务实例接收较少的请求，防止系统停止响应。这种负载均衡策略适合请求量少且稳定的应用。

随机机制，是指提供服务实例随机路由。

轮询机制，是指支持按照服务实例的位置信息顺序路由。

另外，为防止服务提供者持续的响应时间超时，微服务平台提供接口级别的微服务熔断策略设置，熔断设置包括自动熔断和手动熔断。自动熔断指达到设置的超时程度后，服务提供者休息一段时间，待检测正常后，再重新调用；手动熔断指用户手动停止微服务的服务，待选择取消熔断后，再恢复微服务。在本实施例中，在判断微服务是否满足恢复条件时，可以由单位时间内的所有心跳检测结果来决定。举例来说，单位时间是1秒，每隔100毫秒发送一次心跳请求，如果1秒内的10次请求均正常(即心跳检测结果均正常)，则认为单位时间内微服务的服务调用都正常，所以可判定微服务满足恢复条件；如果1秒内有一次请求或多次请求异常(即任意一次心跳检测结果为异常)，则判定微服务不满足恢复条件；通过心跳检测结果判定微服务满足恢复条件后，则自动停止熔断微服务，即自动恢复微服务的服务调用。以上具体的单位时间和心跳检测请求检测的频率仅作为举例说明，具体可以通过微服务的配置来进行设定。

其中，自动熔断会检测微服务的如下参数：

熔断时间窗（sleepWindowInMillisecond），指熔断的持续时间；

请求失败率（errorThresholdPercentage），指微服务被请求的失败率；

窗口请求数（requestVolumeThreshold），指发起的请求数。

请参考图6，以熔断治理规则重启微服务容器过程如下：用户在微服务治理平台勾选微服务的熔断策略，即配置熔断治理策略，用户在进行软件开发时，无需修改微服务代码，对应的微服务容器会重新启动，平台会自动修改微服务的启动命令参数hystrix.command.default.execution.circuitBreaker,参数值包括enabled、sleepWindowInMillisecond、errorThresholdPercentage和requestVolumeThreshold。启动命令参数用于修改微服务应用配置文件中的配置项。

另外，所述限流治理策略的规则包括：

C，接收微服务平台发送的触发限流的阈值；其中所述阈值是指每秒请求数量最大值；

D，计算单位时间内的访问次数；

E，判断所述单位时间内的访问次数是否超出所述触发限流的阈值，如果超出所述触发限流的阈值，则拒绝后续的请求，直到下一单位时间。

为防止某个服务消费者访问服务提供者的服务量突然飙升，影响其他服务消费者不能被正常服务，微服务平台提供每秒请求数量作为是否触发限流的阈值，计算单位时间内的访问次数，如果超出某个阈值，则拒绝后续的请求，等到下一个单位时间再重新计数。用户在微服务平台设置访问的QPS，即每秒请求数量作为是否触发限流的阈值。

请参考图7，以限流治理策略规则重启微服务容器过程如下：用户在微服务治理平台设置QPS的熔断策略，即配置限流治理策略，用户无需修改微服务代码，对应的微服务容器会重新启动，平台会自动修改微服务的启动命令参数hystrix.command.default.executions.isolation.semaphore，参数值为maxConcurrentRequests，即对应页面设置的QPS。启动命令参数用于修改微服务应用配置文件中的配置项。

另外，当服务提供者某个实例出现异常时，微服务平台支持服务消费者对服务提供者的多个实例的访问方式进行配置，即对原实例的请求次数以及新实例的请求次数的定义。微服务平台支持的所述容错治理策略包括以下至少一种：failover策略、failfast策略、failback策略和custome策略。

failover策略，指当前实例异常时，当前实例不重试，其他实例最多重试2次。参数值MaxAutoRetries=0，MaxAutoRetriesNextServer=2。

failfast策略，指当前实例异常时，当前实例不重试，其他实例不重试，立即返回错误。参数值MaxAutoRetries=0，MaxAutoRetriesNextServer=0。

failback策略，指当前实例异常时，当前实例最多重试2次，其他实例不重试。参数值MaxAutoRetries=2，MaxAutoRetriesNextServer=0。

Custome策略，指当前实例异常时，自定义当前实例和其他实例的重试次数。

请参考图8，以容错治理策略规则重启微服务容器过程如下：用户在微服务治理平台勾选微服务的容错策略，无需修改微服务代码，对应的微服务容器会重新启动，平台会自动修改微服务的启动命令参数ribbon.MaxAutoRetriesNextServer和ribbon.MaxAutoRetries。启动命令参数用于修改微服务应用配置文件中的配置项。

另外，降级治理策略是指当服务消费者调用服务提供者的服务时，因延时等原因服务提供者启用了熔断策略，服务消费者Hystrix熔断后回调一个相应的本地降级处理方法，从而实现服务降级。微服务平台支持接口级别的降级策略，针对微服务提供者，可用设置开启或关闭降级策略。其中，所述降级治理策略的规则包括：

F，当客户端启动熔断治理策略时，所述微服务熔断后回调相应的本地降级处理方法。

请参考图9，以降级治理策略规则重启微服务容器过程如下：用户在微服务治理平台勾选微服务的降级策略是否开启，无需修改微服务代码，对应的微服务容器会重新启动，平台会自动修改微服务的启动命令参数hystrix.command.default.fallback.enabled。启动命令参数用于修改微服务应用配置文件中的配置项。

值得注意的是，在具体实施时，以上负载均衡、熔断治理、限流治理、容错治理和降级治理等可以仅选择其中一种或几种策略，并非必须实施。

本发明实施例针对微服务管理平台的复杂性和局限性，可以从以下两个方面解决微服务平台的问题：

（1）针对微服务管理平台人工运维的复杂度，提供基于K8S和容器化的微服务应用的全生命周期管理服务，比如微服务的可视化部署、微服务组件（如注册中心、配置中心、消息总线、微服务网关）以高可用的集群模式容器化部署、微服务可视化治理编排等功能，降低微服务人工运维的复杂度；

（2）针对微服务治理策略如负载均衡、容错限流、熔断降级，与微服务代码降低耦合程度，使得修改微服务治理策略无需修改微服务代码，简化代码开发和维护简易度。

图10为本发明的微服务治理装置的实施例一的示意图。如图10所示，本实施例的微服务治理装置，具体可以包括注册模块301、配置模块302和治理模块303。

注册模块301，用于通过预定义YAML模板将微服务注册请求发送到注册中心；

配置模块302，用于当所述微服务注册成功时，对所述微服务根据其治理策略类型进行配置；

治理模块303，用于当调用配置好的微服务时，在无需修改微服务代码的情况下，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器。

本实施例的微服务治理装置，是与实施例一所述的微服务治理方法对应的装置实施例，通过采用上述模块实现微服务治理的实现机制与上述图1所示实施例的微服务治理方法的实现机制相同，详细可以参考上述图1所示实施例的记载，在此不再赘述。

以上实施例仅为本发明的示例性实施例，不用于限制本发明，本发明的保护范围由权利要求书限定。本领域技术人员可以在本发明的实质和保护范围内，对本发明做出各种修改或等同替换，这种修改或等同替换也应视为落在本发明的保护范围内。

Claims (10)

1.一种微服务治理方法，其特征在于，包括：

通过预定义YAML模板将微服务注册请求发送到注册中心；

当所述微服务注册成功时，对所述微服务根据其治理策略类型进行配置；

当调用配置好的微服务时，在无需修改微服务代码的情况下，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器。

2.根据权利要求1所述的方法，其特征在于，通过预定义YAML模板将微服务注册请求发送到注册中心，包括：

向至少两个注册中心分别发送至少两个相同的Eureka容器化实例，以使所述微服务在所述至少两个注册中心进行注册。

3.根据权利要求1所述的方法，其特征在于，当调用配置好的微服务时，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器，包括：

在无需修改微服务代码的情况下，修改所述微服务的启动命令参数；

其中，所述启动命令参数用于修改微服务应用配置文件中的配置项。

4.根据权利要求1所述的方法，其特征在于，所述治理策略类型包括以下至少一种：负载均衡、熔断治理、限流治理、容错治理和降级治理。

5.根据权利要求4所述的方法，其特征在于，所述负载均衡策略包括以下机制：响应时间权值机制、随机机制和轮论机制。

6.根据权利要求4所述的方法，其特征在于，所述熔断治理策略包括以下参数：熔断时间窗、请求失败率和窗口请求数。

7.根据权利要求4所述的方法，其特征在于，所述限流治理策略的规则包括：

接收微服务平台发送的触发限流的阈值；其中所述阈值是指每秒请求数量最大值；

计算单位时间内的访问次数；

判断所述单位时间内的访问次数是否超出所述触发限流的阈值，如果超出所述触发限流的阈值，则拒绝后续的请求，直到下一单位时间。

8.根据权利要求4所述的方法，其特征在于，所述容错治理策略包括以下至少一种：failover策略、failfast策略、failback策略和custome策略。

9.根据权利要求4所述的方法，其特征在于，所述降级治理策略的规则包括：

当客户端启动熔断治理策略时，所述微服务熔断后回调相应的本地降级处理方法。

10.一种微服务治理装置，其特征在于，包括：

注册模块，用于通过预定义YAML模板将微服务注册请求发送到注册中心；

配置模块，用于当所述微服务注册成功时，对所述微服务根据其治理策略类型进行配置；

治理模块，用于当调用配置好的微服务时，在无需修改微服务代码的情况下，根据所述配置好的微服务对应的治理策略类型，重新启动所述配置好的微服务容器。

Images