MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

Spring Cloud 微服务架构的服务协作

2021-12-045.3k 阅读

Spring Cloud 微服务架构的服务协作

1. 微服务架构下服务协作的重要性

在传统的单体架构中，应用是一个完整的整体，各个功能模块紧密耦合在一起。而微服务架构则将应用拆分成多个小型、独立的服务，每个服务专注于单一功能，并通过轻量级通信机制进行交互。这种架构模式带来了诸多好处，如易于开发、维护和扩展等。然而，这也使得服务之间的协作变得至关重要。

微服务架构中的服务协作是实现复杂业务逻辑的关键。以电商系统为例，用户下单这一简单操作可能涉及到订单服务、库存服务、支付服务等多个微服务之间的协作。订单服务负责创建订单记录，库存服务需要检查并扣减商品库存，支付服务则处理支付流程。只有这些服务相互协作、有序交互，才能完成整个下单业务。如果服务之间的协作出现问题，比如库存服务扣减库存失败，而订单服务却已创建订单，就会导致业务逻辑的混乱，给用户和企业带来损失。

良好的服务协作还能提高系统的可伸缩性。在高并发场景下，不同的微服务可以根据自身的负载情况进行独立扩展。例如，在促销活动期间，订单服务可能会面临大量请求，此时可以单独对订单服务进行水平扩展，增加实例数量以应对高并发。而库存服务和支付服务如果负载正常，则无需扩展。这种基于服务的独立伸缩能力，依赖于服务之间良好的协作机制，确保在扩展过程中服务间的交互依然稳定可靠。

2. Spring Cloud 中的服务发现与注册

在微服务架构中，服务实例的动态变化是常态。新的服务实例可能随时启动，现有实例也可能因各种原因停止运行。为了让服务之间能够准确找到彼此并进行通信，服务发现与注册机制必不可少。Spring Cloud 提供了多种服务发现与注册组件，其中 Eureka 是较为常用的一种。

2.1 Eureka 服务注册中心

Eureka 是 Netflix 开源的一款服务发现组件，Spring Cloud 对其进行了整合和增强。Eureka 服务注册中心分为服务端和客户端两部分。

服务端作为 Eureka Server，负责维护服务实例的注册信息。它提供了一个 RESTful 接口，用于服务实例的注册、续约和下线等操作。同时，Eureka Server 之间可以相互注册，形成一个高可用的集群，确保服务发现功能的可靠性。例如，在一个分布式系统中，可以部署多个 Eureka Server 实例，它们之间通过相互同步数据来保证注册信息的一致性。

客户端则是各个微服务实例，需要向 Eureka Server 注册自身信息。在 Spring Boot 项目中，引入 Eureka Client 依赖后，通过简单的配置即可实现服务注册。以下是一个简单的配置示例：

在 pom.xml 中添加 Eureka Client 依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

在 application.yml 中进行配置：

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/
  instance:
    instance-id: ${spring.application.name}:${spring.application.instance_id:${random.value}}

上述配置中，defaultZone 指定了 Eureka Server 的地址，instance-id 定义了实例的唯一标识。当微服务启动时，会自动向 Eureka Server 注册，并定期发送心跳（续约）以表明自己仍然存活。如果某个实例在一定时间内没有续约，Eureka Server 会将其从注册列表中移除。

2.2 服务发现

一旦微服务成功注册到 Eureka Server，其他服务就可以通过 Eureka Client 进行服务发现。Spring Cloud Ribbon 是一个客户端负载均衡器，它与 Eureka 集成，为服务调用提供了方便。

例如，假设有一个订单服务 order-service 和一个库存服务 inventory-service。订单服务在调用库存服务时，通过 Ribbon 可以从 Eureka Server 获取库存服务的实例列表，并根据负载均衡策略选择一个实例进行调用。以下是一个简单的代码示例：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;

@RestController
public class OrderController {

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/order")
    public String placeOrder() {
        // 调用库存服务检查库存
        String inventoryResult = restTemplate.getForObject("http://inventory-service/checkInventory", String.class);
        // 处理订单逻辑
        return "Order placed. Inventory check result: " + inventoryResult;
    }
}

在上述代码中，http://inventory-service/checkInventory 中的 inventory-service 是库存服务在 Eureka Server 中注册的名称。Ribbon 会根据负载均衡算法（如轮询、随机等）从 Eureka Server 获取的库存服务实例列表中选择一个实例，并将请求发送到该实例的 /checkInventory 接口。

3. 基于 Feign 的声明式服务调用

虽然使用 RestTemplate 结合 Ribbon 可以实现服务间的调用，但这种方式在代码中会存在大量的 URL 硬编码，并且调用逻辑较为繁琐。Spring Cloud Feign 提供了一种声明式的服务调用方式，使得服务调用变得更加简洁和易于维护。

3.1 Feign 的基本使用

Feign 是一个声明式的 Web 服务客户端，它通过接口和注解来定义服务调用。首先，在项目的 pom.xml 中添加 Feign 依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

然后，在 Spring Boot 应用的主类上添加 @EnableFeignClients 注解，开启 Feign 功能：

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.openfeign.EnableFeignClients;

@SpringBootApplication
@EnableFeignClients
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
}

接下来，定义一个 Feign 接口来调用其他服务。例如，订单服务调用库存服务的接口可以这样定义：

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;

@FeignClient(name = "inventory-service")
public interface InventoryFeignClient {

    @GetMapping("/checkInventory")
    String checkInventory();
}

在上述代码中，@FeignClient(name = "inventory-service") 注解指定了要调用的服务名称为 inventory-service。接口中的方法 checkInventory 对应库存服务的 /checkInventory 接口。

最后，在订单服务的控制器中使用这个 Feign 接口进行服务调用：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class OrderController {

    @Autowired
    private InventoryFeignClient inventoryFeignClient;

    @GetMapping("/order")
    public String placeOrder() {
        // 调用库存服务检查库存
        String inventoryResult = inventoryFeignClient.checkInventory();
        // 处理订单逻辑
        return "Order placed. Inventory check result: " + inventoryResult;
    }
}

通过这种方式，代码更加简洁清晰，并且易于维护。如果库存服务的 URL 发生变化，只需要在 Eureka Server 中更新注册信息，而不需要修改订单服务中调用库存服务的代码。

3.2 Feign 的高级特性

Feign 还支持很多高级特性，如请求参数处理、请求头设置、错误处理等。

对于请求参数处理，Feign 接口方法可以接受多种类型的参数。例如，如果库存服务的 checkInventory 接口需要传递商品 ID 作为参数，可以这样定义 Feign 接口：

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;

@FeignClient(name = "inventory-service")
public interface InventoryFeignClient {

    @GetMapping("/checkInventory")
    String checkInventory(@RequestParam("productId") String productId);
}

在订单服务调用时，传递相应的参数：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class OrderController {

    @Autowired
    private InventoryFeignClient inventoryFeignClient;

    @GetMapping("/order")
    public String placeOrder(@RequestParam("productId") String productId) {
        // 调用库存服务检查库存
        String inventoryResult = inventoryFeignClient.checkInventory(productId);
        // 处理订单逻辑
        return "Order placed. Inventory check result: " + inventoryResult;
    }
}

在设置请求头方面，Feign 可以通过 @RequestHeader 注解来设置请求头信息。例如，如果库存服务需要在请求头中传递认证信息：

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestHeader;

@FeignClient(name = "inventory-service")
public interface InventoryFeignClient {

    @GetMapping("/checkInventory")
    String checkInventory(@RequestHeader("Authorization") String authorization);
}

在订单服务调用时，设置相应的请求头：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class OrderController {

    @Autowired
    private InventoryFeignClient inventoryFeignClient;

    @GetMapping("/order")
    public String placeOrder() {
        String authorization = "Bearer someToken";
        // 调用库存服务检查库存
        String inventoryResult = inventoryFeignClient.checkInventory(authorization);
        // 处理订单逻辑
        return "Order placed. Inventory check result: " + inventoryResult;
    }
}

此外，Feign 还支持自定义错误解码器，以便在服务调用失败时进行更友好的错误处理。通过实现 ErrorDecoder 接口并注册为 Spring Bean，可以定制错误处理逻辑。

4. 分布式事务处理在服务协作中的挑战与解决方案

在微服务架构中，多个服务之间的协作往往涉及到分布式事务问题。例如，在电商系统的下单流程中，订单服务创建订单、库存服务扣减库存、支付服务处理支付这一系列操作需要保证要么全部成功，要么全部失败，以确保数据的一致性。然而，由于微服务的独立性和分布式特性，实现分布式事务面临诸多挑战。

4.1 分布式事务的挑战

  • 网络问题：微服务之间通过网络进行通信，网络故障、延迟等问题可能导致部分服务操作成功，而部分服务操作失败。例如，订单服务创建订单成功后，由于网络延迟，库存服务的扣减库存操作未能及时执行，此时就出现了数据不一致的情况。
  • 服务可用性：某个微服务可能由于各种原因（如资源耗尽、程序异常等）不可用，这会影响整个分布式事务的执行。如果在下单流程中，支付服务突然不可用，那么订单创建和库存扣减操作已经执行的情况下，如何处理后续的一致性问题就变得棘手。
  • 事务协调：在分布式环境下，协调多个服务的事务操作变得复杂。每个服务都有自己独立的数据库，传统的单体事务管理机制无法直接应用。需要一种分布式的事务协调机制来确保各个服务的操作在事务层面的一致性。

4.2 Spring Cloud 中的分布式事务解决方案

  • 基于消息队列的最终一致性方案：这种方案利用消息队列来异步处理分布式事务。以电商下单为例，订单服务创建订单后，发送一条消息到消息队列，库存服务和支付服务监听该消息队列。当库存服务接收到消息后，执行扣减库存操作，然后再发送一条消息表示库存处理完成。支付服务接收到库存处理完成的消息后，进行支付操作。如果某个环节出现问题，例如库存扣减失败，库存服务可以回滚操作，并重新发送消息，直到操作成功。这种方案虽然不能保证事务的强一致性，但通过重试机制和消息队列的可靠投递，可以最终达到数据一致性。

在 Spring Cloud 中，可以使用 RabbitMQ 或 Kafka 等消息队列实现这一方案。以下是一个简单的基于 RabbitMQ 的示例：

首先，在项目中添加 RabbitMQ 依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

订单服务发送消息：

import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class OrderController {

    @Autowired
    private RabbitTemplate rabbitTemplate;

    @PostMapping("/order")
    public String placeOrder(@RequestBody Order order) {
        // 创建订单逻辑
        // 发送消息到库存队列
        rabbitTemplate.convertAndSend("inventoryQueue", order);
        return "Order placed. Message sent to inventory service.";
    }
}

库存服务监听消息并处理：

import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;

@Component
public class InventoryListener {

    @RabbitListener(queues = "inventoryQueue")
    public void handleOrder(Order order) {
        // 扣减库存逻辑
        boolean success = reduceInventory(order.getProductId(), order.getQuantity());
        if (success) {
            // 发送库存处理完成消息到支付队列
            rabbitTemplate.convertAndSend("paymentQueue", order);
        } else {
            // 处理库存扣减失败，可进行重试等操作
        }
    }

    private boolean reduceInventory(String productId, int quantity) {
        // 实际的库存扣减逻辑
        return true;
    }
}
  • TCC（Try - Confirm - Cancel）模式：TCC 模式将事务分为三个阶段：Try 阶段进行资源预留，Confirm 阶段确认提交事务，Cancel 阶段回滚事务。以订单服务和库存服务为例，在 Try 阶段，订单服务尝试创建订单，库存服务尝试扣减库存预留资源；如果所有服务的 Try 阶段都成功，则进入 Confirm 阶段，订单服务正式创建订单，库存服务正式扣减库存；如果有任何一个服务的 Try 阶段失败，则进入 Cancel 阶段，订单服务取消订单创建，库存服务释放预留的库存。

Spring Cloud Alibaba 的 Seata 框架提供了对 TCC 模式的支持。使用 Seata 时，需要在各个微服务中引入相关依赖，并进行相应的配置。例如，在订单服务和库存服务中添加 Seata 依赖：

<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>1.4.2</version>
</dependency>

然后，在配置文件中配置 Seata 相关参数，如事务组、注册中心等。在业务代码中，通过注解标记 TCC 事务方法。例如，在库存服务中：

import io.seata.spring.annotation.GlobalLock;
import io.seata.spring.annotation.TCC;
import org.springframework.stereotype.Service;

@Service
@TCC
public class InventoryService {

    @GlobalLock
    public boolean tryReduceInventory(String productId, int quantity) {
        // 库存预留逻辑
        return true;
    }

    public boolean confirmReduceInventory(String productId, int quantity) {
        // 正式扣减库存逻辑
        return true;
    }

    public boolean cancelReduceInventory(String productId, int quantity) {
        // 释放库存预留逻辑
        return true;
    }
}

订单服务在调用库存服务时，通过 Seata 的事务管理机制来协调整个分布式事务。

5. 服务熔断与降级在服务协作中的应用

在微服务架构中，服务之间相互依赖。如果某个服务出现故障或性能下降，可能会导致依赖它的服务也受到影响，甚至引发级联故障，最终使整个系统瘫痪。为了避免这种情况的发生，服务熔断与降级机制应运而生。

5.1 服务熔断

服务熔断类似于电路中的保险丝，当某个服务的调用失败次数或延迟达到一定阈值时，熔断器会跳闸，后续对该服务的请求将不再直接发送到实际服务，而是快速返回一个预设的错误响应，避免大量请求长时间等待或占用资源。

Spring Cloud Hystrix 是一个常用的实现服务熔断的组件。在项目中添加 Hystrix 依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

在 Spring Boot 应用主类上添加 @EnableHystrix 注解开启 Hystrix 功能：

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.hystrix.EnableHystrix;

@SpringBootApplication
@EnableHystrix
public class OrderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }
}

在需要熔断保护的服务调用方法上添加 @HystrixCommand 注解，并指定熔断后的降级方法。例如，订单服务调用库存服务时：

import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;

@RestController
public class OrderController {

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/order")
    @HystrixCommand(fallbackMethod = "fallbackCheckInventory")
    public String placeOrder() {
        // 调用库存服务检查库存
        String inventoryResult = restTemplate.getForObject("http://inventory-service/checkInventory", String.class);
        // 处理订单逻辑
        return "Order placed. Inventory check result: " + inventoryResult;
    }

    public String fallbackCheckInventory() {
        return "Inventory service is unavailable. Order cannot be placed.";
    }
}

在上述代码中，如果库存服务调用失败次数或延迟超过 Hystrix 配置的阈值，熔断器跳闸，后续请求将直接调用 fallbackCheckInventory 方法返回降级响应。

5.2 服务降级

服务降级是指在系统资源紧张或某个服务不可用时，为了保证核心业务的正常运行，主动降低一些非核心服务的功能或性能。例如，在电商系统中，当系统面临高并发时，商品详情页中的一些非关键信息（如商品的推荐视频）可以暂时不加载，优先保证商品基本信息和购买功能的正常使用。

在 Spring Cloud 中，可以通过自定义降级逻辑来实现服务降级。结合 Hystrix，除了方法级别的降级，还可以在全局层面进行配置。例如，通过配置文件设置全局的降级策略：

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 1000
      fallback:
        enabled: true

在代码中，可以通过实现 HystrixFallbackProvider 接口来提供全局的降级响应。例如：

import com.netflix.hystrix.exception.HystrixTimeoutException;
import org.springframework.cloud.netflix.hystrix.fallback.HystrixFallbackProvider;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.http.ResponseEntity;
import org.springframework.stereotype.Component;

@Component
public class InventoryFallbackProvider implements HystrixFallbackProvider {

    @Override
    public String getRoute() {
        return "inventory-service";
    }

    @Override
    public ResponseEntity<String> fallbackResponse(Throwable cause) {
        if (cause instanceof HystrixTimeoutException) {
            return new ResponseEntity<>("Inventory service is timeout. Please try again later.",
                    getHeaders(), HttpStatus.SERVICE_UNAVAILABLE);
        } else {
            return new ResponseEntity<>("Inventory service is unavailable. Please try again later.",
                    getHeaders(), HttpStatus.SERVICE_UNAVAILABLE);
        }
    }

    private HttpHeaders getHeaders() {
        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_JSON);
        return headers;
    }
}

通过服务熔断与降级机制，在服务协作过程中可以有效提高系统的容错性和稳定性，确保在部分服务出现问题时，整个系统仍能维持基本的运行。

6. 总结与展望

Spring Cloud 为微服务架构下的服务协作提供了丰富且强大的工具和组件。从服务发现与注册到声明式服务调用，从分布式事务处理到服务熔断与降级，Spring Cloud 帮助开发者解决了微服务架构中服务协作的一系列关键问题。

通过 Eureka 实现服务的动态注册与发现，使得服务之间能够灵活交互；Feign 的声明式调用方式简化了服务调用的代码，提高了代码的可读性和可维护性；在分布式事务处理方面，基于消息队列的最终一致性方案和 TCC 模式提供了不同场景下的解决方案；服务熔断与降级机制则保障了系统在面对故障和高并发时的稳定性。

然而，随着微服务架构的不断发展和应用场景的日益复杂，服务协作仍面临一些挑战。例如，如何在大规模微服务集群中更高效地管理和监控服务之间的交互；如何进一步优化分布式事务处理，在保证数据一致性的同时提高系统性能等。未来，Spring Cloud 可能会在这些方面不断演进和完善，提供更强大、更智能的服务协作解决方案，助力开发者构建更加健壮、灵活和高效的微服务应用。同时，与其他新兴技术如 Service Mesh 的结合也可能为微服务架构下的服务协作带来新的思路和方法。开发者需要持续关注技术发展动态，不断学习和实践，以更好地应对微服务架构中的各种挑战。