Spring Cloud服务拆分和使用RestTemplate远程调用

2024-11-27 来源：个人技术集锦

任何分布式架构都离不开服务的拆分，微服务也是一样。

2.1.服务拆分原则

这里我总结了微服务拆分时的几个原则：

单一职责原则：每个微服务应负责单一的业务功能，避免服务过于复杂或承担过多职责。这有助于降低服务间的耦合度，提高系统的可维护性和可测试性。
业务能力原则：微服务的拆分应以业务能力为依据，将业务功能模块化。每个微服务应围绕特定的业务能力构建，以便于独立部署和扩展。
数据库独立原则：每个微服务应拥有自己的数据库，以减少服务间的耦合度。独立数据库有助于提高系统的可扩展性和性能。
语言和技术独立原则：微服务可以使用不同的编程语言和技术栈，以提高系统的灵活性和可扩展性。但应避免过度使用新技术，以免增加维护成本。
范围原则：微服务的粒度应适中，过细或过粗都会带来问题。过细可能导致服务数量过多，难以管理；过粗则可能使服务过于庞大，难以维护。
高内聚、低耦合：每个服务只完成自己职责内的任务，对于不是自己职责的功能交给其他服务来完成。
闭包原则（CCP）：当我们需要改变一个微服务时，所有依赖都在这个微服务的组件内，不需要修改其他微服务。
服务自治、接口隔离原则：尽量消除对其他服务的强依赖，这样可以降低沟通成本，提升服务稳定性。服务通过标准的接口隔离，隐藏内部实现细节。这使得服务可以独立开发、测试、部署、运行，以服务为单位持续交付。
持续演进原则：在服务拆分的初期，很难确定服务究竟要拆成什么样。应逐步划分，持续演进，避免服务数量的爆炸性增长。
拆分的过程尽量避免影响产品的日常功能迭代：要一边做产品功能迭代，一边完成服务化拆分。比如优先剥离比较独立的边界服务（如短信服务等），从非核心的服务出发减少拆分对现有业务的影响。
服务接口的定义要具备可扩展性：服务接口是微服务间交互的桥梁，应设计简洁、易用、可扩展的接口。

2.2.服务拆分示例

以微服务cloud-demo为例，其结构如下：

cloud-demo：父工程，管理依赖

order-service：订单微服务，负责订单相关业务
user-service：用户微服务，负责用户相关业务

要求：

订单微服务和用户微服务都必须有各自的数据库，相互独立
订单服务和用户服务都对外暴露Restful的接口
订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户数据库

2.3.实现远程调用案例

在order-service服务中，有一个根据id查询订单的接口：


@RestController
@RequestMapping("order")
public class OrderController {

   @Autowired
   private OrderService orderService;

    @GetMapping("{orderId}")
    public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
        return orderService.queryOrderById(orderId);
       
    }
}

根据id查询订单，返回值是Order对象，如图：

其中的user为null

在user-service中有一个根据id查询用户的接口：

@Slf4j
@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired
    private UserService userService;

    /**
     * 路径： /user/110
     *
     * @param id 用户id
     * @return 用户
     */
    @GetMapping("/{id}")
    public User queryById(@PathVariable("id") Long id) {
        return userService.queryById(id);
    }
}

查询的结果如图：

2.3.1.案例需求：

修改order-service中的根据id查询订单业务，要求在查询订单的同时，根据订单中包含的userId查询出用户信息，一起返回。

因此，我们需要在order-service中向user-service发起一个http的请求，调用http://localhost:8081/user/{userId}这个接口。

大概的步骤是这样的：

注册一个RestTemplate的实例到Spring容器
修改order-service服务中的OrderService类中的queryOrderById方法，根据Order对象中的userId查询User
将查询的User填充到Order对象，一起返回

2.3.2.注册RestTemplate

RestTemplate使用教程：

首先，我们在order-service服务中的OrderApplication启动类中，注册RestTemplate实例：

import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

@MapperScan("com.loong.order.mapper")
@SpringBootApplication
public class OrderApplication {

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

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

2.3.3.实现远程调用

修改order-service服务中的cn.itcast.order.service包下的OrderService类中的queryOrderById方法：

@RestController
@RequestMapping("order")
public class OrderController {

   @Autowired
   private OrderService orderService;
   @Autowired
   private RestTemplate restTemplate;

    @GetMapping("{orderId}")
    public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
        // 根据id查询订单并返回
        Order order = orderService.queryOrderById(orderId);
        //获取用户id组装url地址
        Long userId = order.getUserId();
        String url="http://localhost:8081/user/"+userId;
        User user = restTemplate.getForObject(url, User.class);
        order.setUser(user);
        return order;
    }
}

2.4.提供者与消费者

在服务调用关系中，会有两个不同的角色：

服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）

服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

但是，服务提供者与服务消费者的角色并不是绝对的，而是相对于业务而言。

如果服务A调用了服务B，而服务B又调用了服务C，服务B的角色是什么？

对于A调用B的业务而言：A是服务消费者，B是服务提供者
对于B调用C的业务而言：B是服务消费者，C是服务提供者

因此，服务B既可以是服务提供者，也可以是服务消费者

显示全文

全部栏目