任何分布式架构都离不开服务的拆分,微服务也是一样。
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 {@Autowiredprivate 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 {@Autowiredprivate 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使用教程:RestTemplate 使用教程-CSDN博客
首先,我们在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);}@Beanpublic RestTemplate restTemplate() {return new RestTemplate();}
}
2.3.3.实现远程调用
修改order-service服务中的cn.itcast.order.service包下的OrderService类中的queryOrderById方法:
@RestController
@RequestMapping("order")
public class OrderController {@Autowiredprivate OrderService orderService;@Autowiredprivate 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既可以是服务提供者,也可以是服务消费者