以下内容的代码可见:SpringCloud_learn/day01
1.认识微服务
单体架构和分布式架构
- 体架构:将业务的所有功能集中在一个项目中开发,打成一个包部署
- 优点:架构简单,部署成本低
- 缺点:耦合度高
- 分布式架构:根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,称为一个服务
- 优点:降低服务耦合,有利于服务升级拓展
- 分布式架构要考虑的问题:
- 服务拆分粒度如何?
- 服务集群地址如何维护?
- 服务之间如何实现远程调用?
- 服务健康状态如何感知?
微服务是什么?
微服务是一种经过良好架构设计的分布式架构方案,该架构特征如下:
- 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,避免重复业务开发
- 面向服务:微服务对外暴露业务接口
- 自治:团队独立、技术独立、数据独立、部署独立
- 隔离性强:服务调用做好隔离、容错、降级,避免出现级联问题
- 架构复杂,运维、监控、部署难度提高
2.服务拆分及远程调用
注意事项
- 单一职责:不同微服务,不要重复开发相同业务
- 数据独立:不要访问其它微服务的数据库
- 面向服务:将自己的业务暴露为接口,供其它微服务调用
案例分析
假设此时需要根据订单id查询订单的同时,把订单所属的用户信息一起返回,该如何完成?
传统方式:
- 在订单模块中根据订单id查询订单
- 在用户模块中根据用户id查询用户
- 将两个结果进行拼接
远程调用:即在订单模块(该接口地址为http://locahost:8080/order/xxx)中调用http://locahost:8081/user/xxx
- 在订单模块的
OrderApplication
中注册RestTemplate
:public class OrderApplication { public static void main(String[] args) { SpringApplication.run(OrderApplication.class, args); } @Bean public RestTemplate restTemplate(){ return new RestTemplate(); } }
- 修改订单模块中的
OrderService
的queryOrderById
方法:public Order queryOrderById(Long orderId) { // 1.查询订单 Order order = orderMapper.findById(orderId); // 2.查询用户 String url = "http://localhohst:8081/user/" + order.getUserId(); User user = restTemplate.getForObject(url, User.class); // 发送http请求 // 3.封装user信息 order.setUser(user); // 注意:Order类中具有User类型的字段,这与数据库中的字段不一致 // 4.返回 return order; }
提供者与消费者
服务提供者:一次业务中,被其它微服务调用的服务(提供接口给其它微服务,比如用户模块)
服务消费者:一次业务中,调用其它微服务的服务(调用其它微服务提供的接口,比如订单模块)
提供者与消费者角色是相对的,一个服务可以同时是服务提供者和服务消费者
3.Eureka注册中心
远程调用的问题
服务消费者该如何获取服务提供者的地址信息?在2.服务拆分及远程调用中采用的是硬编码的形式,如果有多个服务提供者则每次都要对
ip
地址进行更换如果有多个服务提供者,消费者该如何选择?
消费者如何得知服务提供者的健康状态?
Eureka的作用
消费者该如何获取服务提供者具体信息?
- 服务提供者启动时向
eureka
注册自己的信息eureka
保存这些信息- 消费者根据服务名称向
eureka
拉取提供者信息如果有多个服务提供者,消费者该如何选择?
- 服务消费者利用负载均衡算法,从服务列表中挑选一个
消费者如何感知服务提供者健康状态?
- 服务提供者会每隔30秒向
EurekaServer
发送心跳请求,报告健康状态eureka
会更新记录服务列表信息,心跳不正常会被剔除- 消费者就可以拉取到最新的信息
实践案例
搭建注册中心(即搭建
EurekaServer
):
- 创建新项目,引入
spring-cloud-starter-netflix-eureka-server
的依赖- 编写启动类,添加
@EnableEurekaServer
注解- 添加
application.yml
文件,编写以下配置:server: port: 10086 spring: application: name: eurekaserver eureka: client: service-url: defaultZone: http://127.0.0.1:10086/eureka/ # eureka本身也是一个服务,所以会将自己注册上去
注册
user-service
和order-service
(order-service
虽然是消费者,但与user-service
一样都是eureka
的客户端,同样可实现服务注册),以注册user-service
为例:
- 在
user-service
项目引入spring-cloud-starter-netflix-eureka-client
的依赖- 在
application.yml
文件编写以下配置:spring: application: name: userservice eureka: client: service-url: defaultZone: http://127.0.0.1:10086/eureka/
在
order-service
完成服务拉取:服务拉取基于服务名称获取服务列表,然后再对服务列表做负载均衡
- 修改
OrderService
的代码,修改访问的url路径,用服务名代替ip、端口:String url = "http://userservice/user/" + order.getUserId();
- 在
order-service
的启动类OrderApplication
中的RestTemplate
加负载均衡注解(因为开启了两个user-service
):@Bean @LoadBalanced public RestTemplate restTemplate(){ return new RestTemplate(); }
4.Ribbon负载均衡
负载均衡流程
当远程调用http://userservice/user/xxx时,该地址并不是一个可以直接访问的地址,这该咋办?此时需要
Ribbon
- 简易流程图:
- 详细流程图:
负载均衡策略
Ribbon
的负载均衡规则是由IRule
接口定义的,每一个子接口都是一种规则
通过定义
IRule
实现可以修改负载均衡规则,有两种方式:
- 在
order-service
中的OrderApplication
类中定义一个新的IRule
// 之后无论orderservice调用哪个服务模块都使用该规则 @Bean public IRule randomRule() { return new RandomRule(); }
- 在
order-service
的application.yml
文件中添加新的配置(更加灵活)# 指定服务名称,这样在调用该服务时才会使用到配置的规则 userservice: ribbon: NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则
饥饿加载:
Ribbon
默认是采用懒加载,即第一次访问(比如输入http://localhost:8080/order/101)时才去创建LoadBalanceClient
,请求时间很长- 饥饿加载会在项目启动时创建,降低第一次访问的耗时,通过下面配置开启饥饿加载:
ribbon: eager-load: enabled: true # 开启饥饿加载 clients: userservice # 指定对userservice服务进行饥饿加载
5.Nacos注册中心
Nacos
是阿里巴巴的产品,现在是SpringCloud
中的一个组件,相比Eureka
功能更加丰富,在国内受欢迎程度较高
安装nacos
tips:
- 如果启动不了,注意环境变量中是否存在名称为
JAVA_HOME
变量- 启动
nacos
:
- 进入
nacos
所在文件下的bin
目录- 在命令行窗口输入
startup.cmd -m standalone
(关闭的时候在另一个窗口输入shutdown.cmd
)- 打开网页后账号和密码都是
nacos
服务注册到Nacos
完成
Nacos
的安装后,进行以下几个步骤:
- 在父工程
cloud-demo
中添加管理依赖spring-cloud-alibaba-dependencies
- 注释
order-service
和user-service
中原有的eureka
依赖- 在
order-service
和user-service
中添加nacos
的客户端依赖spring-cloud-starter-alibaba-nacos-discovery
- 修改
user-service
和order-service
中的application.yml
文件,注释eureka
地址,添加nacos
地址:spring: cloud: nacos: # 配置nacos server-addr: localhost:8848 # nacos服务地址
- 启动并测试
Nacos服务分级存储模型
一个服务可以存在多个实例,每个实例又可以分布在不同的集群中:
服务跨集群调用问题
服务调用尽可能选择本地集群的服务,因为跨集群调用延迟较高
本地集群不可访问时再去访问其它集群
服务集群配置
假设存在
user-service1
、user-service2
和user-service3
三个实例,要将其中两个配置到同个集群中,剩余实例配置到另个集群中
- 修改
user-service
的application.yml
:在配置文件中添加以下内容后启动其中两个实例,再修改集群名称然后启动剩余实例spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: KM # 集群名称(自定义),另一个修改为DG
- 在
nacos
网页中可以看到user-service
对应的两个集群以及详细的实例信息
根据集群负载均衡
假设想让
order-service
调用KM
集群中的user-service
实例:
- 修改
order-service
的application.yml
:让该服务也在KM
集群中spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: KM # 集群名称(即让自己属于KM集群)
- 再次修改
order-service
的application.yml
:设置负载均衡的IRule
为NacosRule
(该规则会优先寻找与自己同集群的服务进行随机访问):userservice: ribbon: NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule
tips:
- 如果
KM
集群中的user-service
实例挂了或未启动,则order-service
再去访问DG
集群的user-service
实例
根据权重负载均衡
在
Nacos
网页中可以设置实例的权重值,进而控制不同机器承担不同数量的用户请求:
- 选择某个服务并进入其实例界面,点击编辑按钮
- 在权重框中自定义权重(权重越高被访问的频率越高,设置为0则完全不会被访问,方便对某个服务器进行停机升级的同时不影响用户使用服务)
环境隔离namespace
Nacos
中服务存储和数据存储的最外层都是一个名为namespace
的东西,用来做最外层隔离(图中集群在Service
下)
使用
namespace
的具体操作步骤如下:
- 创建
namespace
,用来隔离不同环境:
- 填写一个新的命名空间信息:
- 修改目标
application.yml
(这里以order-service
为例):将新空间的命名空间ID
添加到文件中spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: KM namespace: xxxx # 命名空间ID
- 重启
order-service
并访问http://localhost:8080/order/101,因为namespace
与user-service
(属于默认的public
命名空间)不同会导致找不到user-service
(不同namespace
下的服务互相不可见),控制台报错
原理
Nacos
与eureka
的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
Nacos
与Eureka
的区别
Nacos
支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式- 临时实例心跳不正常(即宕机)会被剔除,非临时实例则不会被剔除(标记为不健康),可使用以下代码配置临时(默认)和非临时实例
spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: KM ephemeral: false # 设置为非临时实例
Nacos
支持服务列表变更的消息推送模式,服务列表更新更及时(Eureka
采用pull
,Nacos
是push+pull
)Nacos
集群默认采用AP
方式,当集群中存在非临时实例时,采用CP
模式;Eureka
采用AP
方式