SpringCloud01
1、认识微服务
- 单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。
- 分布式架构：根据业务功能对系统做出拆分，每个业务功能模块作为独立项目开发，称为一个服务。
- 微服务：
- 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责；
- 自治：团队独立、技术独立、数据独立，独立部署和交付；
- 面向服务：服务提供统一标准的接口，与语言和技术无关；
- 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题。
1.1SpringCloud
官网地址：https://spring.io/projects/spring-cloud。
SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。
常见组件：
- 服务注册发现：Eureka、Nacos、Consul
- 服务远程调用：OpenFeign、Dubbo
- 服务链路监控：Zipkin、Sleuth
- 统一配置管理：SpringCloudConfig、Nacos
- 统一网关路由：SpringCloudGateway、Zuul
- 流控、降级、保护：Hystix、Sentinel
2、服务拆分和远程调用
2.1服务拆分原则
- 不同微服务，不要重复开发相同业务
- 微服务数据独立，不要访问其它微服务的数据库
- 微服务可以将自己的业务暴露为接口，供其它微服务调用
2.2案例
order-service中根据id查询订单业务，要求在查询订单的同时，根据订单中包含的userId查询出用户信息，一起返回。
需要在order-service中向user-service发起一个http的请求，调用http://localhost:8081/user/{userId}这个接口。
步骤：
- 注册一个RestTemplate的实例到Spring容器
@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class, args);
}
//注册一个RestTemplate实例
@Bean
public RestTemplate restTemplate() {
return new RestTemplate();
}
- 修改order-service服务中的OrderService类中的queryOrderById方法，根据Order对象中的userId查询User
- 将查询的User填充到Order对象，一起返回
//1、查询订单
//2、远程查询user
String url = "http://localhost:xxxx/user/" + order.getUserId();
//3、发起调用
User user = restTemplate.getForObject(url,User.class);
//4、存入order
order.setUser(user);
//5、返回
return order;
2.3提供者和消费者
在服务调用关系中，会有两个不同的角色：
- 服务提供者：一次业务中，被其他微服务调用的服务（提供接口给其他微服务）
- 服务消费者：一次业务中，调用其他微服务的服务（调用其他微服务提供的接口）
3、Eureka注册中心
3.1Eureka的结构和作用
- order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？
- user-service将信息注册到eureka-server（服务注册）；eureka-server保存服务名称到服务实例地址列表的映射关系；order-service根据服务名称拉取实例地址列表（服务发现/服务拉取）
- 有多个user-service实例地址，order-service调用时该如何选择？
- order-service从实例列表中利用负载均衡算法选中一个实例地址
- 向该实例地址发起远程调用
- order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？
- user-service每隔（默认30s）向注册中心发请求报告状态（心跳）
- 当超过一定时间没有发送心跳时，eureka-server会认为微服务实例故障，将该实例从服务列表中剔除
- order-service拉取服务时，就能将故障实例排除了
一个微服务，既可以是服务提供者，又可以是服务消费者，因此eureka将服务注册、服务发现等功能统一封装到了eureka-client端
搭建注册中心->服务注册->服务发现
3.2搭建eureka-server
- 建模块：eureka-server的maven模块
- 导依赖：spring-cloud-starter-netflix-eureka-server
- 启动类：添加==@EnableEureServer==注解开启eureka的注册中心的功能
@SpringBootApplication
@EnableEurekaServer
public class EurekaApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaApplication.class, args);
}
}
- 配置类文件：
server:
port: 10086 #服务端口号
spring:
application:
name: eureka-server
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
启动 http://127.0.0.1:10086算成功。
3.3服务注册
- 服务提供者引入依赖：
- spring-cloud-netflix-eureka-client
- 配置文件
spring:
application:
name: userservice # 添加服务提供者名称
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka # 添加eureka地址
3.4服务发现/服务拉取
- 服务消费者引入依赖：
- spring-cloud-netflix-eureka-client
- 配置文件
spring:
application:
name: orderservice # 添加服务消费者名称
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka # 添加eureka地址
- 服务拉取和负载均衡：
- 在服务消费者启动类的RestTemplateBean上添加==@LoadBalanced==注解
- 修改url：http://userservice/user/
Spring会自动帮我们从注册中心根据userservice名称获取实例列表然后完成负载均衡。
4、Ribbon负载均衡
4.1负载均衡原理
为什么我们只输入service名称就可以访问？
- LoadBalancerInterceptor这个类会在对RestTemplate的请求进行拦截
- （intercept方法里的request.getURI（http://uservice/user/1）.getHost拿到userservice）然后根据Eureka从**服务id（也就是主机名）**获取服务列表
- （然后this.loadBalancer.execute()处理服务id和用户请求，execute方法中getLoadBalancer会获取一个负载均衡器loadBalancer，根据负载均衡器的算法getServer（LoadBalancer）在server列表中选择server）随后利用负载均衡算法得到真实的服务地址信息，替换服务id。
- IRule接口里指定策略。
- 拦截我们的RestTemplate请求http://userservice/user/1
- RibbonLoadBalancerClient会从请求url中获取服务名称，也就是user-service
- DynamicServerListLoadBalancer根据user-service到eureka拉取服务列表
- eureka返回列表，localhost:8081、localhost:8082
- IRule利用内置负载均衡规则，从列表中选择一个，例如localhost:8081
- RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，发起真实请求
4.2负载均衡策略
| 内置负载均衡规则类 | 规则描述 |
|---|---|
| RoundRobinRule | 简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。(只做轮询） |
| AvailabilityFilteringRule | 对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。 |
| WeightedResponseTimeRule | 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。 |
| ZoneAvoidanceRule | 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。 |
| BestAvailableRule | 忽略那些短路的服务器，并选择并发数较低的服务器。 |
| RandomRule | 随机选择一个可用的服务器。 |
| RetryRule | 重试机制的选择逻辑 |
| 默认ZoneAvoidanceRule，轮询。 |
4.3自定义负载均衡策略
- 代码方式：作用全局 在order-service中的OrderApplication类中，定义一个新的IRule：
在类中定义一个IRule的Bean作为Spring对象注入到容器
@Bean
public IRule randomRule(){
return new RandomRule();//规则从轮询变为随机
}
- 配置文件方式：针对指定微服务 在order-service的application.yml文件中，添加新的配置也可以修改规则：
userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则
一般用默认的负载均衡规则，不做修改。
4.3饥饿加载
Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。
而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：
ribbon:
eager-load:
enabled: true # 开启饥饿加载
clients: # 是一个集合
- userservice # 指定饥饿加载的服务名称
5、Nacos注册中心
需要先安装Nacos。
5.1服务注册到Nacos
（需要注释掉eureka依赖）
- 引入依赖（父工程导入）
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-alibaba-dependenciesartifactId>
<version>2.2.6.RELEASEversion>
<type>pomtype>
<scope>importscope>
dependency>
- 提供者和消费者引入依赖：
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
dependency>
- 配置Nacos地址（提供者和消费者中都要）：
spring:
cloud:
nacos:
server-addr: localhost:8848
- 重启
5.2服务分级存储模型
一个服务可以有多个实例，Nacos将同一机房内的实例划分为一个集群。即一个服务可以包含多个集群。
- 一级是服务
- 二级是集群
- 三级是实例
5.2.1给提供者配置集群
spring:
cloud:
nacos:
server-addr: localhost:8848
discovery:
cluster-name: HZ # 集群名称，可以自定义
5.2.2同集群优先的负载均衡
默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡。
因此Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。
- 给消费者配置集群信息：
spring:
cloud:
nacos:
server-addr: localhost:8848
discovery:
cluster-name: HZ # 集群名称，与userservice的yml文件中的设置保持一致
- 修改负载均衡规则：
userservice:
ribbon:
NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 优先访问本地集群，然后在本地集群中随机选择
5.3权重配置
考虑机器性能
在网页上编辑权重即可。
Nacos控制台可以设置实例的权重值，0~1之间
同集群内的多个实例，权重越高被访问的频率越高
权重设置为0则完全不会被访问
5.4环境隔离
Nacos提供了namespace来实现环境隔离功能。
- nacos中可以有多个namespace
- namespace下可以有group、service等
- 不同namespace之间相互隔离，例如不同namespace的服务互相不可见，不可互访
- 网页设置namespace
- 给微服务配置namespace（修改消费者配置）：
spring:
cloud:
nacos:
server-addr: localhost:8848
discovery:
cluster-name: HZ
namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间，填ID（默认或者自定义）
5.5Nacos和Eureka区别
Nacos的服务实例分为两种l类型：
- 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
- 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。
# 提供者yml
spring:
cloud:
nacos:
discovery:
ephemeral: false # 设置为非临时实例
- Nacos与eureka的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
- Nacos与Eureka的区别
- Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
- Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式