技术栈:
-
认识微服务
-
服务架构演变
-
单体架构
- 将业务的功能集中在一个项目中开发,打成一个包部署
- 优点:
- 架构简单
- 部署成本低
- 缺点:
- 耦合度高
-
分布式架构
- 根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,称为一个服务。
- 优点:
- 降低服务耦合
- 有利于服务升级拓展
- 问题:
- 服务拆分粒度如何?
- 服务集群地址如何维护?
- 服务之间如何实现远程调用?
- 服务健康状态如何感知?
-
微服务是一种良好架构设计的分布式架构方案
- 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责,避免重复业务开发
- 面向服务:微服务对外暴露业务接口
- 自治:团队独立,技术独立,数据独立,部署独立
- 隔离性强:服务调用做好隔离,容错,降级,避免出现级联问题
- 缺点架构非常复杂,运维,监控,部署难度提高
-
-
微服务技术对比
-
企业需求
-
SpringCloud
-
SpringCloud是目前国内使用最广泛的微服务框架。官网地址:SpringCloud官网
-
SpringCloud集成了各种微服务功能组件,并基于SpringBoot实现了这些组件的自动装配,从而提供了良好的开箱即用体验:
-
SpringCloud与SpringBoot的版本兼容性关系如下
-
-
-
分布式服务架构案例
-
服务拆分及远程调用
-
服务拆分注意事项
- 不同微服务,不要重复开发相同业务
- 微服务数据独立,不要访问其它微服务的数据库
- 微服务可以将自己的业务暴露为接口,供其它微服务调用
-
拆分Demo
-
拆分服务之后产生的问题:在8080端口服务查询订单时并没有将用户信息一起返回
-
解决问题(微服务远程调用):
-
注册RestTemplate:在order-service的模块中注册RestTemplate
@Configuration public class RestTemplateConfig { /** * 创建RestTemplate并注入Spring容器 * @return */ @Bean public RestTemplate restTemplate(){ return new RestTemplate(); } }
在查询订单时发送http请求用户信息
@Service public class OrderService { @Autowired private OrderMapper orderMapper; @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,端口,接口路径,请求参数即可。
-
-
提供者与消费者
- 服务提供者:一次业务中,被其他微服务调用的服务。(提供接口给其它微服务)
- 服务消费者:一次业务中,调用其它微服务的服务。(调用其它微服务提供的接口)
- 提供者与消费者角色其实是相对的
- 一个服务可以同时是服务提供者和服务消费者
-