教学视频链接: 【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式,系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】
目录
- 前言
- 一、认识微服务
- 1.1 服务架构
- 1.2 微服务架构
- 1.3 SpringCloud
- 二、服务拆分及远程调用
- 2.1 服务拆分细节
- 2.2 服务间调用
- 三、服务注册中心Eureka
- 3.1 什么是Eureka
- 3.2 搭建Eureka服务
- 3.2 注册服务到Eureka
- 3.3 服务发现
- 3.4 Q&A
- 四、Ribbon负载均衡原理
- 4.1 Ribbon负载均衡原理
- 4.2 Ribbon负载均衡策略选择
- 4.3 Ribbon饥饿加载
- 五、服务注册中心Nacos
- 5.1 认识Nacos
- 5.2 搭建Nacos服务
- 5.2 注册服务到Nacos
- 5.3 Nacos服务分级存储模型
- 5.4 Nacos负载均衡规则
- 5.4.1 Nacos负载均衡规则配置
- 5.4.2 Nacos服务实例权重设置
- 5.5 Nacos
前言
一、认识微服务
1.1 服务架构
单体架构:将业务的所有功能集中在一个项目中开发,打成一个包部署。适合小型项目,如:学生管理系统
- 优点:架构简单,部署成本低;
- 缺点:耦合度高
分布式架构:根据业务功能对系统进行拆分,每个业务模块作为独立项目开发,称为一个服务。适合大型互联网项目,如:淘宝、京东
- 优点:服务耦合度低,有利于服务升级拓展;
- 缺点:架构复杂,开发维护难度大
微服务:微服务是一种经过良好架构设计的分布式架构方案,微服务架构特征:
- 单一职责:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,避免重复业务开发
- 面向服务:微服务对外暴露业务接口
- 高度自治:团队独立、技术独立、数据独立、部署独立
- 强隔离性:服务调用做好隔离、容错、降级,避免出现及联问题
- 优点:拆分粒度更小、服务更独立、耦合度更低
- 缺点:架构非常复杂,运维、监控、部署难度高
1.2 微服务架构
微服务这种方案需要技术框架来落地,全球的互联网公司都在积极尝试自己的微服务落地技术。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。
微服务技术对比
企业需求
1.3 SpringCloud
- SpringCloud是目前国内使用最广泛的微服务框架。官网地址:https://spring.io/projects/spring-cloud
- SpringCloud集成了各种微服务功能组件,并基于SpringBoot实现了这些组件的自动装配,从而提供了良好的开箱即用体验:
二、服务拆分及远程调用
2.1 服务拆分细节
服务拆分注意事项:
- 不同微服务,不要重复开发相同业务
- 微服务数据独立,不要访问其它微服务的数据库
- 微服务可以将自己的业务暴露为接口,供其它微服务调用
2.2 服务间调用
提供者与消费者
- 服务提供者:一次业务中,被其他微服务调用的服务(提供接口给其他服务)
- 服务消费者:一次业务中,调用其他微服务的服务(调用其他微服务提供的接口)
一个服务即可以是提供者又可以是消费者,具体的角色是相对于业务来谈的
三、服务注册中心Eureka
3.1 什么是Eureka
Eureka是Netflix开发的服务发现组件,本身是一个基于REST的服务。Spring Cloud将它集成在其子项目spring-cloud-netflix中,以实现Spring Cloud的服务注册与发现,同时还提供了负载均衡、故障转移等能力。
它是采用了C-S的设计架构。Eureka Server作为服务注册功能的服务器,它是服务注册中心。而系统中的其他微服务,使用Eureka的客户端连接到Eureka Server并维持心跳连接。这样系统的维护人员就可以通过Eureka Server来监控系统中各个微服务是否正常运行。SpringCloud的一些其他模块(比如Zuul)就可以通过Eureka Server来发现系统中的其他微服务,并执行相关的逻辑。
在Eureka架构中,微服务角色有两类:
- EurekaServer:服务端,注册中心
- 记录服务信息,监控服务心跳
- EurekaClient:客户端,包括服务提供者与服务消费者
- Provider:服务提供者
- 注册自己的信息到EurekaServer
- 每隔30s向EurekaServer发送心跳
- Consumer:服务消费者
- 根据服务名称从EurekaServer拉取服务列表
- 基于服务列表做负载均衡,选中一个微服务后发起远程调用
- Provider:服务提供者
3.2 搭建Eureka服务
- 在父工程的pom.xml中引入SpringCloud的依赖
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency>
- 在Eureka服务的pom.xml中引入如下eureka-server依赖,将此服务作为服务注册中心
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency>
- 在SpringBoot启动类上添加@EnableEurekaServer注解
- 在application.yml中配置eureka地址
server: port: 10086 spring: application: name: eurekaserver eureka: client: service-url: defaultZone: http://127.0.0.1:10086/eureka/
3.2 注册服务到Eureka
- 在需要注册的服务pom.xml中引入eureka-client依赖,此服务可以注册入eureka-server,也可以在eureka-server发现服务
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency>
- 在application.yml中配置eureka地址
spring: application: name: userservice eureka: client: service-url: defaultZone: http://127.0.0.1:10086/eureka/
3.3 服务发现
- 在pom.xml中引入eureka-client依赖
- 在application.yml中配置eureka地址
- 给RestTemplate注册Bean时添加@LoadBalanced注解
@Bean @LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); }
- 用服务提供者的服务名称远程调用:http://userservice:8080/user/userInfo/6
3.4 Q&A
服务消费者如何获取服务提供者具体信息?
服务提供者启动时在Eureka注册自己的信息,Eureka保存这些信息,消费者根据服务名称向Eureka拉取提供者信息
如果有多个服务提供者,消费者该如何选择?
服务消费者利用负载均衡算法,从服务列表中挑选一个
服务消费者如何感知服务提供者健康状态?
服务提供者会每隔30s向EurekaServer发送心跳请求,报告健康状态。Eureka会更新记录服务列表信息,心跳不正常会被删除。保证消费者可以拉取到最新的信息
同样作为服务注册中心,Eureka与Zookeeper的区别是什么?
Zookeeper是CP架构,Eureka是AP架构。
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。
但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30~120s,且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。
Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时,如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。
除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
-
Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
-
Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
-
当网络稳定时,当前实例新的注册信息会被同步到其它节点中。
因此,Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。
四、Ribbon负载均衡原理
4.1 Ribbon负载均衡原理
服务调用过程图
Ribbon的负载均衡规则是一个叫做IRule的接口来定义的,每一个子接口都是一种规则:
常见的Ribbon负载均衡规则如下,其中ZoneAvoidanceRule作为默认使用的规则
4.2 Ribbon负载均衡策略选择
通过定义IRule实现可以修改负载均衡规则,有两种方式:
- 代码方式:在服务消费者被@Configuration修饰的类中,定义一个新的IRule:
@Bean public IRule randomRule() { // 随机规则 return new RandomRule(); }
- 配置文件方式:在服务消费者的application.yml中,添加新的配置:
# 配置针对于userservice服务的负载均衡规则 userservice: # 指定服务名称 ribbon: NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 指定负载均衡规则
4.3 Ribbon饥饿加载
Ribbon默认使用懒加载,即第一次访问时才会去创建LoadBalanceClient,请求时间会很长。而饥饿加载则会在项目启动时创建,降低第一次访问的耗时,通过下面配置开启饥饿加载:
ribbon:
eager-load:
enabled: true # 开启饥饿加载
clients:
- userservice # 指定对userservice服务饥饿加载
五、服务注册中心Nacos
5.1 认识Nacos
Nacos是阿里巴巴的产品,现在是SpringCloud中的一个组件。相比Eureka功能更加丰富,在国内受欢迎程度较高。
5.2 搭建Nacos服务
- 在github地址下载对应环境与版本的nacos安装包:https://github.com/alibaba/nacos/releases
- 下载并解压至任意非中文目录,内容说明:
- bin:启动脚本
- conf:配置文件
- 执行sh bin/startup.sh -m standalone(表示以单机模式启动,其默认以集群方式启动)
5.2 注册服务到Nacos
- 在父工程的pom.xml中添加spring-cloud-alilbaba的管理依赖
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2.2.6.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency>
- 在需要注册的服务pom.xml中添加nacos的客户端依赖
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency>
- 在application.yml文件添加nacos地址:
spring: cloud: nacos: server-addr: localhost:8848
- 最后通过浏览器访问localhost:8848/nacos,用户名密码默认都是nacos
5.3 Nacos服务分级存储模型
Nacos服务分级存储模型:
- 一级是服务,例如user-service
- 二级是集群,例如北京集群或上海集群
- 三级是实例,例如北京机房的某台部署了user-service的服务器
无论是服务消费者还是服务生产者,都需要设置服务的集群属性——在application.yml中添加spring.cloud.nacos.discovery.cluster-name
属性。该属性相同的服务在同一集群下
spring:
cloud:
nacos: # 配置Nacos
server-addr: localhost:8848 # 配置Nacos地址
discovery:
cluster-name: BeiJing # 集群名称
启动服务后,可以在Nacos服务列表可看到如下结果:
点击userservice详情后可以看到具体集群与实例关系。下图中BeiJing集群下有2实例,ShangHai集群下有1实例
5.4 Nacos负载均衡规则
5.4.1 Nacos负载均衡规则配置
服务间的调用尽可能选择本地集群内的服务,跨集群调用延迟较高;当本地集群不可访问时,再去访问其它集群。由于负载均衡规则是通过Ribbon的IRule实现的,所以要想保证以上原则需要修改IRule的具体实现:
# 配置只针对于userservice服务的负载均衡规则
userservice: # 指定服务名称
ribbon:
NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则
5.4.2 Nacos服务实例权重设置
NacosRule负载均衡规则会优先调用同集群的服务,如果本集群下不存在该服务才会夸集群调用,其采用随机访问负载均衡策略。实际部署中会出现这样的场景:服务器设备性能存在差异,部分实例所在机器性能好,而部分则较差,我们希望性能好的机器承担更多的请求。
所以Nacos提供了权重配置来控制访问频率,权重越大则访问频率越高
权重控制:
- Nacos控制台可以设置实例的权重值,取值范围为0~1
- 同集群内的多个实例,权重越高被访问的频率越高
- 权重设置为0则完全不会被访问