微服务学习笔记
文章目录
- 微服务学习笔记
- 认识微服务
- 微服务技术栈
- 微服务学习要点
- 微服务远程调用
- 1)注册RestTemplate
- 2) 服务远程调用RestTemplate
- Eureka注册中心
- 简介
- 操作过程
- 搭建EurekaServer
- 注册user-service
- 在order-service完成服务拉取
- Ribbon负载均衡
- IRule负载均衡策略
- 饥饿加载
- Nacos注册中心
- 步骤
- 服务注册到Nacos
- Nacos服务搭建
- 分级存储模型
- 服务集群属性
- 根据集群负载均衡
- 根据权重负载均衡
- 环境隔离-namespace
- 临时实例和非临时实例
- Nacos与eureka的共同点
- Nacos与Eureka的区别
- Nacos配置管理
- 统一配置管理
- 微服务获取Nacos配置
- 配置热更新
- 多环境配置共享
- 多种配置的优先级
- 搭建Nacos集群
- http客户端Feign
- 使用步骤
- Feign的自定义配置
- Feign的性能优化
- 连接池配置
- Feign的最佳实践
- 统一网关Gateway
- 搭建网关服务
- 路由断言工厂
- 过滤器
- 路由过滤器 GatewayFilter
- 全局过滤器GlobalFilter
- 过滤器顺序
- 跨域问题处理
- Docker
- 服务异步通讯
- 异步调用方案
- 初识MQ
- 产品
- RabbitMQ快速入门
- 安装
- 消息模型
- SpringAMQP(RabbitMQ)
- 消息发送
- Work Queue工作队列
- 发布(publish)订阅(Subscribe)
- 广播Fanout Exchange
- 路由Direct Exchange
- 主题TopicExchange
- 消息转换器
- 个人小结
- 分布式搜索
- 初识ElasticSearch
- 倒排索引
- 索引
- 安装ES
- 安装kibana
- 分词器
- 字典的个性化拓展
- 索引库操作
- mapping映射属性
- 索引库的CRUD
- 创建索引库
- 修改索引库
- 查询索引库
- 删除索引库
- 文档操作
- 添加文档
- 查询文档
- 删除文档
- 修改文档
- RestClient操作索引库
- 初始化JavaRestClient
- 创建索引库
- 删除索引库
- 判断索引库是否存在
- RestClient操作文档
- 初始化JavaRestClient
- 添加酒店数据到索引库
- 根据id查询酒店数据
- 根据id修改文档
- 根据id删除文档
- 批量导入数据
- ElasticSearch 搜索功能
- DSL查询文档
- 全文检索查询
- 精确查询
- 地理查询
- 复合查询
- function score 查询
- Boolean Query 查询
- 搜索结果处理
- 排序
- 分页
- 深度分页问题
- 分页对比
- 高亮
- RestClient查询文档
- 快速入门
- match查询
- 精确查询
- 复合查询
- 排序、分页、高亮
- 数据聚合
- 聚合的种类
- DSL实现聚合
- bucket聚合
- Metrics聚合
- RestAPI实现聚合
- 自动补全
- 拼音分词器
- 自定义分词器
- 自动补全查询
- 数据同步
- 数据同步思路分析
- ElasticSearch集群
- 搭建ES集群
- 集群职责与脑裂
- 集群分布式存储
- 集群分布式查询
- 集群故障转移
- 微服务保护
- 初识Sentinel
- 雪崩问题及解决方案
- 服务保护技术对比
- Sentinel介绍和安装
- 微服务整合Sentinel
- 流量控制
- 快速入门
- 流控模式
- 关联模式
- 链路模式
- 流控效果
- warm up 预热模式
- 排队等待
- 热点参数限流
- 隔离和降级
- FeignClient整合Sentinel
- 线程隔离(舱壁模式)
- 熔断降级
- 熔断策略
- 授权规制
- 基本规则
- 如何获取origin
- 给网关添加请求头
- 自定义异常结果
- 规制持久化
- 规则管理模式
- 实现push模式
- 1）修改order-service服务
- 2)修改sentinel-dashboard源码
- 分布式事务
- 理论基础
- CAP定理
- BASE理论
- 初识Seata
- Seata的架构
- 部署TC服务
- 微服务集成Seata
- 总结
- XA模式
- XA模式的优缺点
- 实现XA模式
- AT模式
- AT模式的优缺点
- 实现
- TCC模式
- TCC的空回滚和业务悬挂
- 优缺点
- 实现
- SAGA模式
- 优缺点
- 四种模式对比
- 高可用
- 高可用集群结构
- 分布式缓存
- 数据持久化
- RDB
- RDB原理
- AOF持久化
- AOF和RDB的优缺点
- 主从复制
- 搭建主从架构
- 主从数据同步原理
- 全量同步
- 增量同步
- 总结
- Redis哨兵
- 哨兵的作用和原理
- 作用
- 服务状态监控（判断实例是否健康）
- 选举新的master
- 如何实现故障转移
- 搭建哨兵集群
- RedisTemplate的哨兵模式
- Redis分片集群
- 分片集群结构
- 散列插槽
- 集群伸缩
- 转移插槽
- 故障转移
- 自动故障转移
- 手动故障转移
- RedisTemplate访问分片集群
- 多级缓存
- 多级缓存介绍
- JVM进程缓存
- 初始Caffeine
- 缓存分类
- Caffeine入门
- 可靠消息服务
- 消息可靠性
- 消息幂等性
- 延迟消息
- MQ集群
认识微服务
微服务技术栈
1、服务集群：系统功能的实现
2、注册中心：记录每个服务的IP、端口、功能等。起到服务注册和服务发现的作用。
3、配置中心：实现各个服务的配置问题
4、服务网关：用户访问的时候进行校验、路由到服务、负载均衡。所有的服务调用都调用到网关，然后在网关里配置路由，进行服务的转发，类似于代理的作用。当然网关需要配合注册中心进行使用，去发现转发到哪个服务上去。
5、分布式缓存：缓存数据
6、分布式搜索：快速搜索
7、消息队列：异步通信
8、分布式日志：统一对日志存储、统计、分析
9、系统监控链路追踪：实时追踪每个服务的负载、CPU运行状态、内存等。出问题可以快速追踪。
微服务学习要点
1、微服务治理：SpringCloud相关技术
2、异步通信技术
3、缓存技术
4、搜索技术
5、DevOps
微服务远程调用
Spring提供了 RestTemplate 用于远程调用。
1)注册RestTemplate
在order-service的OrderApplication中注册RestTemplate
@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class，args);
@Bean//返回一个RestTemplate对象交给Spring IOC容器进行管理，方便之后进行自动注入
public RestTemplate restTemplate(){
return new RestTemplate0;
}
}
2) 服务远程调用RestTemplate
修改order-service中的OrderService的queryOrderByld方法
@Service
public class OrderService {
@Autowired
private RestTemplate restTemplate:
public Order queryOrderById(Long orderId) {
// 1.查询订单
Order order = orderMapper.findById(orderId);
// TODO 2.查询用户
String url ="http:// localhost:8081/user/" + order.getUserId();
User user = restTemplate.getForObject(url,User.class);//使用restTemplate发送远程调用
// 3.封装user信息
order.setUser(user);
// 4.返回
return order;
}
}
Eureka注册中心
简介
在Eureka架构中，微服务角色有两类
**EurekaServer:**服务端，注册中心
记录服务信息
心跳监控
**EurekaClient:**客户端
Provider:服务提供者，例如案例中的 user-service
注册自己的信息到EurekaServer
每隔30秒向EurekaServer发送心跳
consumer:服务消费者，例如案例中的order-service
根据服务名称从EurekaServer拉取服务列表
基于服务列表做负载均衡，选中一个微服务后发起远程调用
消费者该如何获取服务提供者具体信息?
服务提供者启动时向eureka注册自己的信息
eureka保存这些信息
消费者根据服务名称向eureka拉取提供者信息
如果有多个服务提供者，消费者该如何选择?
服务消费者利用负载均衡算法，从服务列表中挑选一个消费者
如何感知服务提供者健康状态?
服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态eureka会更新记录服务列表信息，心跳不正常会被剔除
消费者就可以拉取到最新的信息
操作过程
搭建EurekaServer
1.创建项目，引入spring-cloud-starter-netflix-eureka-server的依赖
<dependency>
<groupId>org.springframework.coud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
2.编写启动类，添加@EnableEurekaServer注解
3.添加application.ym[文件，编写下面的配置:
server:
port: 10086
spring:
application:
name: eurekaserver
eureka:
client:
service-url: # 指定eureka服务端的注册地址,可以指定多个
defaultZone: http://127.0.0.1:10086/eureka
注册user-service
1.在user-service项目引入spring-cloud-starter-netflix-eureka-client的依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
2.在application.yml文件，编写下面的配置
spring:
application:
name: userservice
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
另外，我们可以将user-service多次启动，模拟多实例部署，但为了避免端口冲突，需要修改端口设置.
在Service中选中相关实例然后复制一份，并配置端口
在order-service完成服务拉取
服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡
1.修改OrderService的代码，修改访问的url路径，用服务名代替ip、端口:
String url = "http://userservice/user/" + order.getUserId();
2.在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解:
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
Ribbon负载均衡
请求将会被LoadBalanceInterceptor负载均衡拦截器拦截下来。
这个拦截器会将请求交割RibbonLoadBalancerClient（之后简称R）这个对象，它会将服务id交给DynamicServeListLoadBalancer （后面简称D）这个对象。之后D会向Eureka拉取服务列表，Eureka返回列表后D将会寻找IRule负责负载均衡。IRule将会选择某个服务返回R，R将会修改Url从而发起真实的请求。
IRule负载均衡策略
| 内置负载均衡规则类 | 规则描述 |
|---|---|
| RoundRobinRule | 简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。 |
| AvailabilityFilteringRule | 对以下两种服务器进行忽略: (1)在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。(2)并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的<clientName>,<clientConfigNameSpace>,ActiveConnectionsLimit属性进行配置。 |
| WeightedResponseTimeRule | 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。 |
| ZoneAvoidanceRule（默认） | 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。 |
| BestAvailableRule | 忽略哪些短路的服务器，并选择并发数较低的服务器。 |
| RandomRule | 随机选择一个可用的服务器 |
| RetryRule | 重试机制的选择逻辑 |
通过定义IRule实现可以修改负载均衡规则，有两种方式
1.代码方式:在order-service中的OrderApplication类中，定义一个新的IRule:
@Bean
public IRule randomRule(){
return new RandomRule();
}
2.配置文件方式:在order-service的application.yml文件中，添加新的配置也可以修改规则:
userservice:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则
饥饿加载
Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长.而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载:
ribbon:
eager-load:
enabled: true # 开启饥饿加载
cLients:
- userservice # 指定对userservice这个服务饥饿加载
Nacos注册中心
步骤
服务注册到Nacos
1.在cloud-demo父工程中添加spring-cloud-alilbaba的管理依赖:
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>2.2.5.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
2.注释掉order-service和user-service中原有的eureka依赖
3.添加nacos的客户端依赖:
<!-- nacos客户端依赖 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
4.修改user-service&order-service中的application.yml文件，注释eureka地址，添加nacos地址:
spring:
cloud:
nacos:
server-addr: localhost:8848 # nacos 服务端地址
5.启动并测试:
Nacos服务搭建
下载安装后在bin下运行
startup.cmd -m standalone
分级存储模型
服务->集群->实例
服务集群属性
1.修改application.yml，添加如下内容:
spring:
cloud:
nacos:
server-addr: localhost:8848 # nacos 服务端地址
discovery:
cluster-name: HZ # 配置集群名称，也就是机房位置，例如: HZ，杭州
2.在Nacos控制台可以看到集群变化:
根据集群负载均衡
1修改order-service中的application.yml，设置集群为HZ:
spring:
cloud:
nacos:
server-addr: localhost:8848 # nacos 服务端地址
discovery:cluster-name: HZ # 配置集群名称，也就是机房位置
2然后在order-service中设置负载均衡的IRule为NacosRule，这个规则优先会寻找与自己同集群的服务:
userservice:
ribbon:
NFLoadBalancerRuleclassName: com.albaba.cloudnacos.ribbon.NacosRule # 负载均衡规则
3.注意将user-service的权重都设置为1
根据权重负载均衡
实际部署中会出现这样的场景:
服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求
Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高
1.在Nacos控制台可以设置实例的权重值，首先选中实例后面的编辑按钮
2.将权重设置为0.1，测试可以发现8081被访问到的频率大大降低
环境隔离-namespace
Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西，用来做最外层隔离
namespace用来做环境隔离每个namespace都有唯一id不同namespace下的服务不可见
Namespace->Group->Service/Data
1.在Nacos控制台可以创建namespace，用来隔离不同环境
2.然后填写一个新的命名空间信息:
3.保存后会在控制台看到这个命名空间的id:
4.修改order-service的application.yml，添加namespace
spring:
cloud:
nacos:
server-addr: localhost:8848
discovery:
cluster-name: SH # 上
namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4bof9 # 命名空间，填ID
临时实例和非临时实例
服务注册到Nacos时，可以选择注册为临时或非临时实例。
临时实例如果不健康将会直接删除对应的实例。非临时将会实时监测健康状态，等待恢复健康。通过下面的配置来设置
spring:
cloud:
nacos:
discovery:
ephemeral: false # 设置为非临时实例
Nacos与eureka的共同点
都支持服务注册和服务拉取
都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式，非临时实例采用主动检测模式。临时实例心跳不正常会被剔除，非临时实例则不会被剔除
Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式;Eureka采用AP方式
Nacos配置管理
统一配置管理
配置更改热更新。
在Nacos客户端的配置列表进行配置
配置名称的约定一般如下：功能-运行环境。比如：userservice-dev.yaml
不是所有配置都更新过来，而是有热更新需求的配置放在其中。
配置获取步骤：
项目启动->读取bootstap.yml文件获取nacos地址。读取nacos中配置文件
微服务获取Nacos配置
1.引入Nacos的配置管理客户端依赖
<dependency>
<groupId> com.alibaba.cloud </groupId>
<artifactId> spring-cloud-starter-alibaba-nacos-config </artifactId>
</dependency>
2.在userservice中的resource目录添加一个bootstrap.yml文件，这个文件是引导文件，优先级高于
application.yml:
spring:
application:
name: userservice # 服务名称
profiles:
active: dev #开发环境，这里是dev
cloud:
nacos:
server-addr: localhost:8848 # Nacos地址
config:
file-extension: yaml # 文件后名
配置热更新
Nacos中的配置文件变更后，微服务无需重启就可以感知。不过需要通过下面两种配置实现
方式一:在@Value注入的变量所在类上添加注解@RefreshScope
此时的注入需要使用@Value注解
@Value("${pattern.dateformat}")
private String dateformat;
方式二（推荐）:使用@ConfigurationProperties注解完成配置自动加载，注意前缀名和变量名的凭借要和配置一致。
@Component
@Data
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
private String dateformat;
}
此时的注入采用自动装配。
@Autowired
private PatternProperties properties;
多环境配置共享
某些配置是多个环境下一样的。
微服务启动时会从nacos读取多个配置文件:
1、[spring.application.name]-[spring.profiles.active].yaml，例如: userservice-dev.yaml
2、[spring.application.name].yaml，例如: userservice.yaml
无论profile如何变化，[spring.application.name].yaml这个文件一定会加载，因此多环境共享配置可以写入这个文件
多种配置的优先级
服务名-profile.yaml>服务名称yaml >本地配置
搭建Nacos集群
搭建集群的基本步骤:
1、搭建数据库，初始化数据库表结构
2、下载nacos安装包
3、配置nacos
进入nacos的conf目录，修改配置文件cluster.conf.example，重命名为cluster.conf:
添加节点信息，如：
127.0.0.1:8845
127.0.0.1:8846
修改application.properties文件，添加数据库配置：
# 打开数据源
spring.datasource.platform=mysql
#配置url和用户信息
修改application.properties文件，修改对应的端口号
server.port=8845
4、启动nacos集群
在bin目录下启动startup.cmd
5、nginx反向代理
在nginx的conf目录下修改nginx.conf文件,在http中添加以下内容：
upstream nacos-cluster {
server 127.0.0.1:8845;
server 127.0.0.1:8846;
server 127.0.0.1:8847;
}
server {
listen 80;
server_name 1ocalhost;
location /nacos {
proxy_pass http://nacos-cluster;
}
}
http客户端Feign
RestTemplate方式调用存在的问题：1、代码可读性差，编程体验不统一；2、参数复杂URL难以维护
Feign是一个声明式的http客户端，其作用就是帮助我们优雅的实现http请求的发送，解决上面提到的问题。
Feign使用ribbon实现了负载均衡
使用步骤
1、引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
2、在order-service的启动类添加注解开启Feign功能：
@EnableFeignClients
3、编写Feign客户端：
//指定服务名称
@FeignClient("userservice")
public interface UserClient{
@GetMapping("/user/{id}")
User findById( @PathVariable("id") Long id);
}
主要是基于SpringMVC的注解来声明远程调用的信息，比如:
服务名称: userservice
请求方式:GET
请求路径: /user/{id)
请求参数: Long id
返回值类型:User
4、使用Feign进行远程调用
public Order queryOrderById(Long orderId){
// 1.查询订单
Order order = orderMapper.findById(orderId);
// 2.用Feign远程调用
User user = userclient.findById(order.getUserId());
// 3.封装user到Order
order.setUser(user);
// 4.返回
return order;
}
Feign的自定义配置
Feign运行自定义配置来覆盖默认配置，可以修改的配置如下：
| 类型 | 作用 | 说明 |
|---|---|---|
| feign.Logger.Level | 修改日志级别 | 包含四种不同的级别:NONE、BASIC、 HEADERS、 FULL |
| feign.codec.Decoder | 响应结果的解析器 | http远程调用的结果做解析,例如解析json字符串为java对象 |
| feign.codec.Encoder | 请求参数编码 | 将请求参数编码,便于通过http请求发送 |
| feign. Contract | 支持的注解格式 | 默认是SpringMVC的注解 |
| feign. Retryer | 失败重试机制 | 请求失败的重试机制,默认是没有,不过会使用Ribbon的重试 |
配置Feign日志有两种方式:
方式一:配置文件方式
全局生效:
feign:
client:
config:
default: #这里用default就是全局配置，如果是写服务名称，则是针对某个微服务的配置
loggerLevel: FULL
局部生效：
feign:
client:
config:
userservice:
loggerLevel: FULL
方式二:java代码方式，需要先声明一个Bean:
public class FeignClientConfiguration{
@Bean
public Logger.Level feignLogLevel(){
return Logger.Level.BASIC;
}
}
如果在启动类上的@EnableFeignClients注解中声明则代表全局
@EnableFeignClients(defaultConfiguration = FeignClientConfiguration.class)
如果在客户端上的@FeignClient注解中声明则代表某服务
@Feignclient(value = "userservice",configuration = FeignclientConfiguration.class)
Feign的性能优化
Feign底层的客户端实现
- URLConnection:默认实现，不支持连接池
- Apache HttpClient:支持连接池
- OKHttp:支持连接池
因此优化Feign的性能主要包括:
-
使用连接池代替默认的URLConnection
-
日志级别，最好用basic或none
连接池配置
1、引入依赖
<!--httpClient的依赖-->
<dependency>
<groupId>io.github.openfeign</groupId>
<artifactId>feign-httpclient</artifactId>
</dependency>
2、配置连接池，开启Feign对连接池的支持
feign:
httpclient:
enabled: true # 开feign对HttpClient的支持
max-connections: 200 # 最大的连接数
max-connections-per-route: 50 # 每个路的最大连接数
Feign的最佳实践
方式一(继承)（不推荐）:给消费者的FeignClient和提供者的controller定义统一的父接口作为标准
public interface UserAPI{
@GetMapping("/user/{id}")
User findById(@PathVariable("id") Long id);
}
之后定义的客户端和controller接口继承该接口。
方式二(抽取):将FeignClient抽取为独立模块，并且把接口有关的POJO、默认的Feign配置都放到这个模块中，提供给所有消费者使用
1、首先创建一个module，命名为feign-api，然后引入feign的starter依赖
2、将order-service中编写的UserClient、User、DefaultFeignConfiguration都复制到feign-api项目中
3、在order-service中引入feign-api的依赖
4、修改order-service中的所有与上述三个组件有关的import部分，改成导入feign-api中的包
重启测试
5、重启测试
在使用过程中，当定义的FeignClient不在SpringBootApplication的扫描包范围时，这些FeignClient无法使用。有两种方式解决:
方式一:指定FeignClient所在包
@EnableFeignClients(basePackages = "cn.itcast.feign.clients")
方式二（推荐）:指定FeignClient字节码
@EnableFeignClients(clients = {UserClient.class})
统一网关Gateway
网关功能：
- 身份认证和权限校验
- 服务路由、负载均衡
- 请求限流
网关的技术实现：
在SpringCloud中网关的实现包括两种 gateway、zuul
Zuul是基于Servlet的实现，属于阻塞式编程。而SpringCloudGateway则是基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能。
搭建网关服务
1、创建新的module，引入SpringCloudGateway的依赖和nacos的服务发现依赖。
<!-- 网关依赖-->
<dependency>