目录
为什么会引出微服务,我们之前的架构存在那些问题?
单体架构
单体架构:将业务的所有功能集中在一个项目中开发,打成一个包部署
- 优点:架构简单、部署成本低
- 缺点: 耦合度高
比如:在开发中,订单的查询里面可能包含有用户的信息,那么我们在查询订单的业务中,需要有查询用户的操作,这样导致订单表和用户表需要在同一个数据库中,并且两个业务在同一个项目块中。
这样会导致什么结果呢 ?
- 代码耦合度高
- 重复开发(因为用户业务中,已经存在查询用户的操作)
- 服务需要升级,会引发一系列的代码修改
新的架构
分布式架构
分布式架构:根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,称为一个服务。
- 每个业务都是一个独立的项目,对应其唯一的数据库
- 业务之间互不交叉,相互独立
优点:降低服务耦合、有利于服务升级拓展
缺点:架构非常复杂,运维、监控、部署难度提高
微服务
微服务是一种经过良好架构设计的分布式架构方案,微服务架构特征:
- 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责,避免重复业务开发
- 面向服务:微服务对外暴露业务接口
- 自治:团队独立、技术独立、数据独立、部署独立
- 隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题 (防止一个出错,影响到另一个也出错)
服务拆分
目标:订单业务和用户服务拆分成,相互独立的项目
- 微服务需要根据业务模块拆分,做到单一职责,不要重复开发相同业务
- 微服务可以将业务暴露为接口,供其它微服务使用
- 不同微服务都应该有自己独立的数据库
一个项目中,两个模块,分别是订单模块,用户模块
两个模块分别连接其对应的数据库
RestTempate的使用
1.导入maven依赖包,在org.springframework.web.client.RestTemplate这个包中
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
2.在订单业务的OrderApplication中,注册RestTemplate
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class, args);
}
/**
* 完成restTemplate的创建,并注入spring容器
* @return
*/
@Bean
public RestTemplate restTemplate(){
return new RestTemplate();
}
}
3.在对应的查询方法中使用RestTemplate,发送http请求
在RestTemplate中对应的getForEntity方法和delete方法等,就是对应Restful风格编程
方法参数,需要传入url路径,这里的路径就是指在用户业务中,查找user的接口路径
@Autowired
private RestTemplate restTemplate;
public Order queryOrderById(Long orderId) {
// 1.查询订单
Order order = orderMapper.findById(orderId);
// 2.利用RestTemplate发送http请求,查询用户信息
// 2.1获得url
String url = "http://localhost:8081/user/" + order.getUserId();
// 2.2发送http请求,实现远程调用
User user = restTemplate.getForObject(url, User.class);
// 3 封装user到order
order.setUser(user);
// 4.返回
return order;
}
微服务调用方式
-
基于RestTemplate发起的http请求实现远程调用
-
http请求做远程调用是与语言无关的调用,只要知道对方的ip、端口、接口路径、请求参数即可。
谢谢观看