springcloud day01
单体架构：业务所有功能都在一个项目中开发，打成一个包部署 优点是架构简单 部署成本低 缺点是 耦合度高
分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为一个独立的项目开发，也称为一个服务 优点是 耦合度低 缺点是 关系更复杂了
微服务：就是一种经过良好架构设计的分布式架构方案
springcloud是国内使用最广泛的微服务框架，他是微服务架构的一站式解决方案，集成了各种优秀的微服务功能组件
微服务的拆分原则
1.不同的微服务不能重复开发相同的业务
2.微服务之间的数据独立，且不能访问其他微服务的数据库
3.微服务可以把自己的业务暴露成接口供其他微服务调用
微服务的远程调用
大概步骤为
1.注册一个RestTemplate的实例到spring容器中
2.
3.将查询的User填充到Order对象，一起返回
提供者与消费者
服务消费者：一次业务中，调用其他微服务的服务
服务提供者：一次业务中，被其他微服务调用的服务
这两个角色不是绝对的 只是相对于业务而言
ribbon负载均衡
负载均衡策略
| 规则描述 | |
|---|---|
| RoundRobinRule | 简单轮询服务列表来选择服务器。 |
| AvailabilityFilteringRule | 对以下两种服务器进行忽略： （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的<clientName>.<clientConfigNameSpace>.ActiveConnectionsLimit属性进行配置。 |
| WeightedResponseTimeRule | 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。 |
| ZoneAvoidanceRule | 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。 |
| BestAvailableRule | 忽略那些短路的服务器，并选择并发数较低的服务器。 |
| RandomRule | 随机选择一个可用的服务器。 |
| RetryRule | 重试机制的选择逻辑 |
其中ZoneAvoidanceRule为默认的策略
更改负载均衡规则有两种方式
一般用默认的负载均衡规则，不做修改！！！！！！！！！！！！
1.定义一个新的IRule
@Bean
public IRule randomRule(){
return new RandomRule();
}
2.在配置文件中添加新的规则
userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则
饥饿加载
Ribbon默认的是懒加载
可以改成饥饿加载 更改方式如下
ribbon:
eager-load:
enabled: true
clients: userservice
<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>
子工程
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
2.配置nacos地址
在子工程的yml文件中添加nacos地址
spring:
cloud:
nacos:
server-addr: localhost:8848
3.重启
服务分级存储模型
Nacos将同一机房内的实例划分为一个集群。Nacos使用多副本集群技术，可以让多台服务器在同一个网络中共享配置信息和服务发现。当某个实例宕机时，其他实例依然可以正常工作，确保Nacos服务的高可用性。
