目录
1.注册中心
以前我们实现微服务拆分是通过Http请求实现了跨微服务的远程调用。不过这种手动发送Http请求的方式存在一些问题：假如商品微服务被调用较多，为了应对更高的并发，我们可能需要进行多实例部署，如图：
此时，每个item-service的实例其IP或端口不同，问题来了：
- item-service这么多实例，cart-service如何知道每一个实例的地址？
- http请求要写url地址，
cart-service服务到底该调用哪个实例呢？ - 如果在运行过程中，某一个
item-service实例宕机，cart-service依然在调用该怎么办？ - 如果并发太高，
item-service临时多部署了N台实例，cart-service如何知道新实例的地址？
为了解决上述问题，就必须引入注册中心了
服务流程：
- 服务启动时就会注册自己的服务信息（服务名、IP、端口）到注册中心
- 调用者可以从注册中心订阅想要的服务，获取服务对应的实例列表（1个服务可能多实例部署）
- 调用者自己对实例列表负载均衡，挑选一个实例
- 调用者向该实例发起远程调用
当服务提供者的实例宕机或者启动新实例时，调用者如何得知呢？
- 服务提供者会定期向注册中心发送请求，报告自己的健康状态（心跳请求）
- 当注册中心长时间收不到提供者的心跳时，会认为该实例宕机，将其从服务的实例列表中剔除
- 当服务有新实例启动时，会发送注册服务请求，其信息会被记录在注册中心的服务实例列表
- 当注册中心服务列表变更时，会主动通知微服务，更新本地服务列表
2.Nacos注册中心
目前开源的注册中心框架有很多，国内比较常见的有：
- Eureka：Netflix公司出品，目前被集成在SpringCloud当中，一般用于Java应用
- Nacos：Alibaba公司出品，目前被集成在SpringCloudAlibaba中，一般用于Java应用
- Consul：HashiCorp公司出品，目前集成在SpringCloud中，不限制微服务语言
以上几种注册中心都遵循SpringCloud中的API规范，因此在业务开发使用上没有太大差异。由于Nacos是国内产品，中文文档比较丰富，而且同时具备配置管理功能，因此在国内使用较多
使用指南：day03-微服务01 - 飞书云文档
服务治理包括服务注册和服务发现，导入的依赖是相同的，这个依赖中同时包含了服务注册和发现的功能。因为任何一个微服务都可以调用别人，也可以被别人调用，即可以是调用者，也可以是提供者
<!--nacos 服务注册发现-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
<version>2021.0.4.0</version> <!-- 替换为你所需的具体版本 -->
</dependency>服务调用者去订阅服务时，由于有多个实例，而真正发起调用时只需要知道一个实例的地址，因此，服务调用者必须利用负载均衡的算法，从多个实例中挑选一个去访问。常见的负载均衡算法有：
- 随机
- 轮询
- IP的hash
- 最近最少访问
最简单的随机负载均衡实现：3分钟处微服务01-14.服务治理-服务发现和负载均衡_哔哩哔哩_bilibili
3.OpenFeign
利用RestTemplate实现了服务的远程调用的方式太麻烦了，而且这种调用方式，与原本的本地方法调用差异太大，编程时的体验也不统一，一会儿远程调用，一会儿本地调用。因此，为了改变远程调用的开发模式，让远程调用像本地方法调用一样简单，这就要用到OpenFeign组件了。
其实远程调用的关键点就在于四个参数：请求方式、请求路径、请求参数、返回值类型，所以，OpenFeign就利用SpringMVC的相关注解来声明上述4个参数，然后基于动态代理帮我们生成远程调用的代码，而无需我们手动再编写day03-微服务01 - 飞书云文档
3.1快速入门
3.2连接池
在 OpenFeign 中，连接池（Connection Pool）是一种管理 HTTP 连接的机制，旨在重复利用现有的 HTTP 连接，以减少频繁创建和销毁连接带来的开销，提高远程调用的性能和效率。
为什么需要连接池？
- HTTP 连接的开销：每次建立新的 HTTP 连接都需要进行 TCP 三次握手，在高并发场景下，这种开销会显著影响性能
- 减少连接创建时间：通过重用已有的连接，可以避免重复创建和销毁连接，降低延迟
- 提高并发性能：连接池可以同时保持多个连接，从而支持多个请求的并发处理
- 资源管理：合理控制最大连接数，防止资源耗尽
3.3抽取feignClient为api
3.4日志配置
OpenFeign只会在FeignClient所在包的日志级别为DEBUG时，才会输出日志。而且其日志级别有4级：
- NONE：不记录任何日志信息，这是默认值
- BASIC：仅记录请求的方法，URL以及响应状态码和执行时间
- HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息
- FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据
Feign默认的日志级别就是NONE，所以默认我们看不到请求日志
3.5OpenFeign vs Dubbo
- Dubbo：是一种基于 Java 的 RPC 框架，基于二进制协议，提供了服务发现、服务注册、负载均衡、熔断、流量控制等功能。主要用于构建分布式系统中高性能、高可靠性的服务通信
- OpenFeign：是 Spring Cloud 生态中的 HTTP 客户端工具，基于 Http 协议和 REST 风格的接口调用，更适合基于 HTTP 的微服务架构，提供了声明式的 REST 客户端功能
简单来说就是Dubbo 在协议灵活性和性能上占优；OpenFeign 受限于 HTTP 协议，但简单易用。
4.Http协议和二进制协议
HTTP 协议：
- 使用文本格式（如 JSON、XML、HTML）进行数据传输
- 文本数据可读性强，方便调试和理解
- 由于需要将数据序列化为字符串，且附带较多的头信息，体积通常较大
- 开销较大，因为每次请求都包含 HTTP 头部信息（如方法、状态码、Headers）
- 适合人类和机器之间的交互，但在高并发和大量小数据传输场景下效率较低
二进制协议：
- 直接使用二进制格式传输数据，数据更加紧凑，传输效率高
- 不可读性强，需要特定的工具或解码器来分析数据
- 减少了文本格式的序列化/反序列化开销
- 更适合频繁的请求和响应（如 RPC 调用）
- 适合大规模分布式系统中的高性能通信
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
