上游服务不可用了，下游服务如何应对？

上游服务不可用了，下游服务如何应对？

引言

• 在系统中，上游服务和下游服务是两个关键概念。上游服务通常指的是提供某种功能或数据的服务端，它接收来自下游服务的请求，并根据请求进行处理和响应。下游服务通常指的是发起请求并依赖上游服务的客户端，它们通过发送请求向上游服务请求数据或执行某些操作。
• 上游服务和下游服务之间的协作是系统中实现整体功能的关键。上游服务提供了核心的业务逻辑和数据，下游服务则依赖于上游服务来完成其特定任务。
• 下游服务的稳定性和可用性直接依赖于上游服务的可靠性和性能。如果上游服务不可用或出现故障，同时下游服务没有采取任何应对措施，此时将可能出现以下问题：
• 无法正常执行任务：下游服务可能无法执行其功能，因为它依赖于上游服务的数据或资源。这将导致下游服务无法正常工作。
• 延迟和性能下降：如果下游服务不对上游服务的不可用进行适当处理，而是无限期等待或不断尝试请求，系统的响应时间会增加，导致性能下降。
• 级联故障：如果下游服务继续发起大量的请求到不可用的上游服务，它可能会导致下游服务资源被全部占用，无法为其他请求提供服务。这可能导致级联故障，使整个系统不可用。
• 因此，下游服务应该采取适当的应对措施来处理上游服务不可用的情况，以确保系统的稳定性和可用性。

情况分类

• 对于上游服务的不可用，此时可以区分为短暂不可用和长时间不可用两种情况，从而采用不同的方式来进行处理。
• 短暂不可用，是指上游服务在一段时间内暂时无法提供正常的服务，通常是由于网络波动或负载过高等原因导致的。这种情况下，上游服务可能会在很短的时间内自行恢复，并重新可用。短暂不可用通常持续时间较短，可以通过重试机制来处理。下游服务可以在请求失败后进行重试，直到上游服务恢复正常。
• 长时间不可用，是指上游服务在较长的时间内无法提供正常的服务，无法自行恢复或恢复时间较长。这种情况可能是由于严重的故障、系统崩溃，或其他长期性问题导致的。在这种情况下，简单地进行无限制的重试可能会导致系统被该请求全部占用，甚至引发级联故障。
• 短暂不可用和长时间不可用是上游服务不可用的两种常见情况，它们需要不同的应对策略。了解并区分这两种情况对于确保系统的稳定性和可用性至关重要。

短暂不可用

处理方式

• 短暂的不可用可能只是临时性的，可能是网络拥塞或其他暂时性问题导致的。此时可以通过重试机制，下游服务可以尝试重新发送请求，增加请求成功的机会，避免由于系统的短暂不可用导致请求的失败。

代码示例

• 重试机制在许多客户端库中已经成为标准功能。这些客户端库提供了一些配置选项，以控制重试行为。下面是一个使用gRPC的示例代码，展示了如何配置和使用重试机制，然后基于此避免由于系统的短暂不可用导致请求的失败。

• 首先展示服务端代码，用于向外提供服务:

• package main
  
  import (
          "context"
          "log"
          "net"
  
          pb "path/to/your/protobuf"
          "google.golang.org/grpc"
  )
  
  type server struct {
          pb.UnimplementedYourServiceServer
  }
  
  func (s *server) YourRPCMethod(ctx context.Context, req *pb.Request) (*pb.Response, error) {
          // 处理请求逻辑
          return &pb.Response{Message: "Hello, world!"}, nil
  }
  
  func main() {
          listener, err := net.Listen("tcp", ":50051")
          if err != nil {
                  log.Fatalf("Failed to listen: %v", err)
          }
  
          srv := grpc.NewServer()
          pb.RegisterYourServiceServer(srv, &server{})
  
          log.Println("Server started")
          if err := srv.Serve(listener); err != nil {
                  log.Fatalf("Failed to serve: %v", err)
          }
  }
  

• 接下来展示客户端代码，其在服务端出现错误时，会进行重试，避免由于服务的短暂不可用，导致请求的失败，保证系统的可用性:

• package main
  
  import (
          "context"
          "log"
          "time"
          pb "path/to/your/protobuf" 
          "google.golang.org/grpc"
  )
  
  func main() {
          conn, err := grpc.Dial("localhost:50051", grpc.WithInsecure())
          if err != nil {
                  log.Fatalf("Failed to connect: %v", err)
          }
          defer conn.Close()
  
          client := pb.NewYourServiceClient(conn)
  
          // 设置重试次数和超时时间
          retryOptions := []grpc.CallOption{
                  grpc.WithRetryMax(3),           // 最大重试次数
                  grpc.WithTimeout(5 * time.Second), // 超时时间
          }
          // 发起 gRPC 请求（带重试和超时时间）
          ctx := context.Background()
          response, err := client.YourRPCMethod(ctx, &pb.Request{}, retryOptions...)
          if err != nil {
                  log.Fatalf("Failed to make request: %v", err)
          }
  
          log.Println("Response:", response.Message)
  }
  

• 在客户端代码中，我们通过 grpc.WithRetryMax 设置最大重试次数，通过 grpc.WithTimeout 设置超时时间。

• 这样，当遇到服务端短暂不可用时，客户端将进行最多 3 次的重试，并在每次重试时设置 5 秒的超时时间。能够让上游服务在短暂不可用情况下，仍然能够最大限度得保证下游服务请求的成功。

最佳实践

• 但是并非当请求失败时，便不断进行重试，直到请求成功，需要设置适当的重试策略和超时机制。避免由于大量的重试导致下游服务压力变大，从而导致服务从短暂不可用转变成了长时间不可用。
• 首先确定最大重试次数，根据系统需求和上游服务的特性，确定最大重试次数。避免无限制地进行重试，因为过多的重试可能会给上游服务造成过大的负担。通常，3-5次重试是一个常见的值，但具体数字应根据实际情况进行调整。
• 其次设置合理的超时时间，为了避免下游服务长时间等待不可用的上游服务，设置合理的请求超时时间是很重要的。超时时间应根据上游服务的预期响应时间和网络延迟进行调整。一般来说，超时时间应该在几秒钟的范围内，以确保及时地放弃不可用的请求并进行后续处理。

长时间不可用

会导致的问题

• 长时间不可用的情况可能导致严重的问题，其中包括系统资源被全部占用和级联故障的风险。
• 首先是上游服务可能直接崩溃。当上游服务面临大量请求失败时，如果下游服务仍然持续地发起请求并无脑重试，此时随着请求数的增加，系统的资源（例如线程、内存、连接等）将被耗尽，导致系统无法处理其他的请求。结果是整个系统变得不可响应，甚至崩溃。
• 其次是级联故障的风险。长时间不可用的上游服务可能引发级联故障。在分布式系统中，不同的服务通常相互依赖和交互，上游服务的不可用性可能会影响到下游服务。如果下游服务在遇到上游服务不可用时不具备合适的应对机制，它们可能会继续尝试发送请求，造成资源浪费和堆积。这样的情况可能导致下游服务也不可用，甚至影响到更多的依赖系统，最终导致整个系统的级联故障。
• 所以，我们在设计系统时，下游服务在一些关键节点应该采取适当的应对措施来处理上游服务不可用的情况，以确保系统的稳定性和可用性。

处理方式

• 当上游服务长时间不可用时，下游服务需要采取一些措施来处理这个问题，以避免系统资源被全部占用和防止级联故障的发生。有两种常见的处理方式：引入熔断器和数据降级。
• 首先可以引入熔断器：熔断器是一种用于监控上游服务可用性并在需要时进行熔断的机制。当上游服务长时间不可用时，熔断器会直接熔断下游服务对上游服务的请求，而不是无脑地继续发送请求。这样可以避免下游服务持续占用系统资源，并且防止级联故障的发生。
• 熔断器通常有三个状态：关闭状态、打开状态和半开状态。在关闭状态下，请求会正常通过；当错误率达到一定阈值时，熔断器会打开，所有请求都会被熔断；在一段时间后，熔断器会进入半开状态，允许部分请求通过，以检查上游服务是否已经恢复正常。通过熔断器的状态转换，下游服务可以更好地适应上游服务的不可用情况。
• 其次是进行数据缓存与降级，如果上游服务提供的数据不是实时性要求很高，下游服务可以考虑在上游服务可用时缓存一部分数据。当上游服务不可用时，下游服务可以使用已经缓存的数据作为降级策略，确保系统的正常运行。这样可以减少对上游服务的依赖，避免系统资源被全部占用。
• 两种常见的方式，可以帮助下游服务在上游服务长时间不可用的情况下保持稳定性，并避免系统资源被全部占用和级联故障的发生。

代码示例

• 下面展示一个示例代码，展示下游服务向上游服务发送请求，并实现熔断机制和缓存降级操作，从而在上游服务不可用时，保证下游服务的稳定性:

• package main
  
  import (
          "fmt"
          "sync"
          "time"
  
          "github.com/sony/gobreaker"
  )
  
  var (
          circuitBreaker *gobreaker.CircuitBreaker
          cache          map[string]string
          cacheMutex     sync.RWMutex
  )
  
  func main() {
          // 初始化熔断器
          circuitBreaker = gobreaker.NewCircuitBreaker(gobreaker.Settings{
                  Name:        "MyCircuitBreaker",
                  MaxRequests: 3,                  // 最大请求数
                  Interval:    5 * time.Second,    // 统计时间窗口
                  Timeout:     1 * time.Second,    // 超时时间
                  ReadyToTrip: customTripFunc,     // 自定义熔断判断函数
          })
  
          // 初始化缓存
          cache = make(map[string]string)
  
          // 模拟下游服务发送请求
          for i := 0; i < 10; i++ {
                  response, err := makeRequest("https://baidu.com")
                  if err != nil {
                          fmt.Println("Request failed:", err)
                  } else {
                          fmt.Println("Response:", response)
                  }
                  time.Sleep(1 * time.Second) // 间隔一段时间再次发送请求
          }
  }
  
  // 发送请求的函数
  func makeRequest(url string) (string, error) {
          // 使用熔断器包装请求函数
          response, err := circuitBreaker.Execute(func() (interface{}, error) {
                  // 假设向上游服务发送 HTTP 请求
                  // ...
                  // 返回响应数据或错误
                  return "Response from  service", nil
          })
  
          if err != nil {
                  // 请求失败，使用缓存降级
                  cacheMutex.RLock()
                  cachedResponse, ok := cache[url]
                  cacheMutex.RUnlock()
  
                  if ok {
                       return cachedResponse, nil
                  }
  
                  return "", err
          }
          // 请求成功，更新缓存
          cacheMutex.Lock()
          cache[url] = response.(string)
          cacheMutex.Unlock()
  
          return response.(string), nil
  }
  
  // 自定义熔断判断函数，根据实际情况进行判断
  func customTripFunc(counts gobreaker.Counts) bool {
          // 根据失败次数或其他指标来判断是否触发熔断
          return counts.ConsecutiveFailures > 3
  }
  

• 上述代码示例中，使用了gobreaker开源项目实现了熔断机制，并使用本地缓存实现了缓存降级操作。

• 在发送请求的函数makeRequest中，使用熔断器包装请求函数，在请求函数内部实际发送请求给上游服务。如果请求成功，则更新缓存，并返回响应。

• 如果请求失败，则再次尝试从缓存中获取数据，如果缓存中存在，则返回缓存的响应。如果缓存中也不存在数据，则返回错误。

• 这样，下游服务可以在上游服务不可用的情况下，通过缓存提供一定的降级功能，避免对上游服务进行频繁无效的请求。而熔断机制则可以在下游服务可用性不高时，直接熔断请求，减少对上游服务的负载，提高整体系统的稳定性。

总结

• 本文主要介绍了上游服务不可用时，下游服务的应对措施。主要分为短暂不可用和长时间不可用两种情况。
• 短暂不可用通常由网络波动或其他暂时性问题导致。在这种情况下，可以采用重试机制来成功请求上游服务，确保资源的可用性。重试机制是一种简单而有效的方法，通过多次重试请求，以应对短暂的不可用情况，避免下游服务受到影响。
• 长时间不可用可能导致严重的问题，如上游服务崩溃或级联故障。为了应对这种情况，可以引入熔断器保护机制来确保下游服务的稳定性。熔断器能够快速切断对不可用的上游服务的请求，避免系统资源被全部占用。此外，根据具体服务的特性，可以考虑使用缓存降级来处理长时间不可用的情况。通过缓存上游服务的响应数据，即使上游服务不可用，下游服务仍可以从缓存中获取数据，保持服务的可用性。
• 综上所述，重试机制和熔断器是应对上游服务不可用的关键措施。重试机制适用于短暂不可用情况，而熔断器则用于长时间不可用的情况下保护下游服务。此外，根据具体情况，采用缓存降级等策略可以进一步提升服务的稳定性和可用性。

-----------------------------------------------------------------------------------

offer突击训练营简介：

1：针对不知道怎么面试，面试没有信心的小伙伴，我们会给你一个offer保障。

2：我们会监督你15-20天内把面试体系技术点掌握至少7成，这样足够你去找到满意的工作了。

3：我们是面向面试学习指导，不会带你们去写代码，会把项目真实开发的迭代过程和技术细节如何实现业务功能都详细教清楚，你能在面试中流畅表达清楚就行了，项目经验你不用担心(技术老师提供的真实项目经验肯定拿的出手)，自己学和别人带着系统学，效率完全不一样。

详情请点击这里：offer突击训练营，给你一个offer的保障，求职跳槽的看过来！