Go微服务实战——服务治理（负载均衡，请求重试，服务熔断，服务降级）

负载均衡

在微服务架构中各个服务都是独立部署、可独立扩展和管理的。在上一节Go微服务实战——服务的注册与获取（nacos做服务注册中心）将所有的服务注册到注册中心，供其他服务使用。

这是对于整个系统的层面，对于单个服务来说，又有不同的实例，例如一个服务存在多个集群，同一服务被部署在不同集群的不同主机上，那么这个服务就是不同的实例，在服务调用阶段，一般获取一个健康的实例地址，发送请求，但是这个健康的请求并不确定其是否繁忙。

也就是同一服务的所有实例都是健康的，各个实例的访问量无法控制，可能A服务下,a,b,c三个实例都是健康的，但是服务中心都将请求转发给了a实例，导致a实例所在的主机CPU使用量暴涨从而卡顿缓慢，但是此时b,c却没有请求。

因此负载均衡就是为了解决资源分配不均的问题。

微服务的负载均衡通常不是直接在注册中心实现的，而是通过注册中心提供的服务发现功能来支持。注册中心主要用于服务发现，负载均衡是在服务消费者端实现的。

服务消费者从注册中心获取可用的服务实例列表，并根据一定的负载均衡策略选择合适的实例来发送请求。因此，负载均衡的实现主要是服务消费者的责任，服务消费者需要根据自身的需求选择合适的负载均衡算法，并在本地实现请求的分发。

在CloudWego框架中实现负载均衡的方式衣蛾十分简单cloudwego负载均衡在创建客户端通过传入配置项类启动。

// 使用的是基于权重的轮询策略，也是 Kitex 的默认策略
cli, err := echo.NewClient("echo", client.WithLoadBalancer(loadbalance.NewWeightedRoundRobinBalancer()))

cli, err := echo.NewClient("echo", client.WithLoadBalancer(loadbalance.NewInterleavedWeightedRoundRobinBalancer()))

cli, err := echo.NewClient("echo", client.WithLoadBalancer(loadbalance.NewWeightedRandomBalancer()))

官网服务负载均衡策略

服务的负载均衡策略小编也不懂啊，有大佬麻烦再评论区讲讲。

请求重试

微服务请求重试是指在发起对某个微服务的请求时，如果请求失败或者未收到预期的响应，系统会自动尝试再次发送该请求，以期望在一定的重试次数内获得成功的响应。这个过程是自动化的，由系统自身负责执行。

请求重试的目的是增加系统的健壮性和可靠性。在分布式系统中，由于网络不稳定、服务不可用或者服务响应超时等原因，请求可能会失败。通过重试机制，系统可以容忍一定程度的失败，以减少因为瞬时故障导致的系统不可用或者请求失败的情况。

在重试阶段也会有一定的重试策略，通过配置，系统自动选择重试策略并执行重试任务。

在CloudWeGo中主要有服务异常导致的服务重试和网络波动导致的服务重试。相应的策略都在github.com/cloudwego/kitex/pkg/retry包下。

• 异常重试retry.NewFailurePolicy()

fp.WithMaxRetryTimes(3) // 配置最多重试3次
xxxCli := xxxservice.NewClient("destServiceName", client.WithFailureRetry(fp))

• retry.NewBackupPolicy()

bp := retry.NewBackupPolicy(xxx)
xxxCli := xxxservice.NewClient(targetService, client.WithBackupRequest(bp))

cloudwego服务请求重试

服务熔断

微服务的服务熔断是一种用于提高系统稳定性和防止服务雪崩效应的机制。服务熔断是指在发现服务故障或异常情况时，临时停止向故障服务发送请求，并在一段时间内拒绝新的请求，以减轻服务间的压力，同时允许故障服务有时间恢复正常状态。

服务熔断的目的是避免由于服务间的故障或不可用状态导致整个系统不可用的情况。当一个微服务的调用失败次数超过一定阈值时，系统会触发服务熔断，将该服务切换为熔断状态。在熔断状态下，系统会拒绝对该服务的请求，并在一段时间内不再发送请求到该服务上。

• 熔断器状态（Circuit Breaker State）： 熔断器可以处于关闭状态、打开状态或者半开状态。初始情况下，熔断器处于关闭状态，允许请求通过；当达到一定的失败阈值后，熔断器会切换到打开状态，拒绝请求；在一段时间后，熔断器可能会尝试进入半开状态，允许部分请求通过，以检测服务是否已经恢复正常。

• 熔断阈值（Circuit Breaker Threshold）： 系统需要定义触发服务熔断的阈值，通常是一定的失败次数或错误率。当请求失败次数达到或超过熔断阈值时，熔断器会切换到打开状态。

• 熔断时间窗口（Circuit Breaker Time Window）： 在熔断状态下，熔断器会保持一段时间，称为熔断时间窗口。在这段时间内，系统会拒绝对故障服务的请求，以减轻服务的负载。熔断时间窗口结束后，系统可能会尝试将熔断器切换到半开状态，以检测服务是否已经恢复。

通过服务熔断机制，系统可以在故障发生时快速响应，避免因为故障服务的连锁效应导致整个系统不可用。服务熔断通常与请求重试、限流、监控和报警等机制配合使用，以实现系统的高可用性和稳定性。

小编从GPT学来的哈

熔断处理也是在服务消费者端哈

在CloudWeGo中有一整套的视线方式：

• 熔断策略

• 触发策略
  
• 冷却策略

• 半打开时策略

大多数服务熔断都是基于配置实现，熔断出发，恢复都是有系统完成，一般亲情况下需要配置的有：

1. 熔断策略
2. 触发熔断阈值
3. 熔断保护时间

参考大佬的文章，感谢大佬 😮[ Kitex 源码解读 ] 熔断机制是如何实现的

服务降级

一般情况下服务降级策略不是关闭系统或者主机的某些功能而是直接返回缓存数据或者MOCK数据。

如果服务在请求重试和熔断后均没有恢复，那么就服务降级，返回一些缓存或静态数据。

服务降级也是服务一般也是消费者端完成的哈

var opts []client.Option
opts = append(opts, client.WithFallback(yourFallbackPolicy))

xxxCli := xxxservice.NewClient("target_service", opts...)

服务熔断