文章介绍了SpringCloud和Dubbo在国内的使用情况，SpringCloud主要基于SpringCloudNetflix，而SpringCloudAlibaba作为新的发展，包括Nacos、Sentinel等组件。文章还详细讨论了服务治理的各个模块，如注册中心、服务调用、负载均衡、服务降级和熔断、服务网关以及配置中心，强调了它们在微服务架构中的重要性，并对比了相关技术。
一、国内外技术栈介绍
首先，我们来看看这两个技术栈在国内的流行程度，据自己了解到：
- 对于国外，Spring Cloud 基本已经统一国外的微服务体系。
- 对于国内，老的系统使用 Dubbo 较多，新的系统使用 Spring Cloud 较多。
这样说起来，仿佛 Spring Cloud 和 Dubbo 是冲突的关系？！
实际上，并不然。我们现在所使用的 Spring Cloud 技术体系，实际上是 Spring Cloud Netflix 为主，例如说：
- Netflix Eureka 注册中心
- Netflix Hystrix 熔断组件
- Netflix Ribbon 负载均衡
- Netflix Zuul 网关服务
但是，开源的世界，总是这么有趣。随着Spring Cloud Netflix 将不再开发新的组件,项目进入维护模. 目前 Alibaba 基于开源组件和多个阿里云产品组成以及Spring Cloud 对的接口，实现了一套 Spring Cloud Alibaba 技术体系，并且已经获得 Spring Cloud 的认可，目前在国内使用人数很多了。组件如下：
- Nacos 注册中心 + 配置中心，对标 Eureka 。并且，还对标了 Spring Cloud Config 。
- Sentinel 服务保障，对标 Hystrix 。
- Dubbo 服务调用( 包括负载均衡 )，对标 Ribbon + Feign 。
- Gateway 网关服务。
个人态度上，还是非常看好 Spring Cloud Alibaba 技术体系的
二、各模块详细说明
1.注册中心
该模块主要功能为 自动提供服务的注册与发现，集中式管理服务，让 服务调用端发现服务，让服务提供端注册服务，倘若没有注册中心，那客户端就需要维护服务端调用信息（ip、端口），另外这样操作服务调用端是无法感知服务提供端的健康状态，需要人为添加与剔除服务，维护成本高，因此需要注册中心来帮助我们来完成这些事儿。
CAP定理：指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得
其中：
一致性（C）：所有节点都可以访问到最新的数据
可用性（A）：每个请求都是可以得到响应的，不管请求是成功还是失败
分区容错性（P）：除了全部整体网络故障，其他故障都不能导致整个系统不可用
-
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡
CA： 如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的
CP: 如果不要求A（可用），每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统
AP：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
注册中心对比：
Nacos的CP和AP的选择是在配置文件nacos.proper
更改一致性模型
-
找到配置文件:
- 在 Nacos 的安装目录中找到
conf/nacos.properties文件。
- 在 Nacos 的安装目录中找到
-
编辑配置文件:
- 打开
nacos.properties文件，并找到与一致性模型相关的配置项。
- 打开
一致性模型配置项
Nacos 通过以下配置项来设置一致性模型：
-
CP 模型:
- 为了启用 CP 模型，你需要设置
nacos.core.consistency.mode为strong。 - 示例配置：
properties1nacos.core.consistency.mode=strong
- 为了启用 CP 模型，你需要设置
-
AP 模型:
- 为了启用 AP 模型，你需要设置
nacos.core.consistency.mode为eventual。 - 示例配置：
properties1nacos.core.consistency.mode=eventual
- 为了启用 AP 模型，你需要设置
注意事项
-
重启服务:
- 修改配置后，需要重启 Nacos 服务以使更改生效。
-
备份配置:
- 在修改配置文件之前，建议备份原始的
nacos.properties文件，以防万一需要恢复默认设置。
- 在修改配置文件之前，建议备份原始的
-
集群模式:
- 如果你在集群模式下运行 Nacos，确保所有节点都使用相同的配置以保持一致性。
总结
Nacos 的一致性模型可以通过修改 nacos.properties 文件中的 nacos.core.consistency.mode 配置项来设置。将该配置项设置为 strong 可以启用 CP 模型，设置为 eventual 可以启用 AP 模型。确保在修改配置后重启 Nacos 服务，并在集群环境中保持一致性。
2、服务调用
该模块主要功能为负责各微服务之间的通讯， 实现服务端的远程调用，常见技术有，RestTemplate、Feign、OpenFeign。
服务调用框架对比：
RestTemplate详情调用博客(SpringCloud系列：微服务间如何通信_微服务之间如何通信_江夏、的博客-优快云博客)
Feign、OpenFeign。详情介绍,使用的博客(Feign 与 OpenFeign_BUG弄潮儿的博客-优快云博客)
Nacos 作为一个服务发现和配置管理平台，提供了心跳检测机制来监控服务实例的状态。心跳检测机制对于确保服务实例的健康状态和可用性非常重要。以下是 Nacos 中服务实例的心跳检测机制的概述：
心跳检测原理
-
客户端注册服务实例:
- 当服务实例首次启动时，它会向 Nacos 注册中心注册自己，并提供必要的元数据，如服务名称、IP 地址、端口号等。
-
客户端发送心跳:
- 注册成功后，客户端(服务提供端)会定期向 Nacos 发送心跳报文，以表明服务实例仍然活跃。这个心跳报文通常包含服务实例的标识信息。
-
服务实例超时机制:
- Nacos 服务器会维护一个超时时间阈值，如果在这个时间内没有收到服务实例的心跳报文，Nacos 会认为该服务实例已失效，并将其标记为不可用。
-
服务实例状态更新:
- 当 Nacos 收到服务实例的心跳报文时，会更新该服务实例的状态，并确保其在服务列表中处于活跃状态。
-
服务实例下线:
- 当服务实例主动下线时，它会向 Nacos 发送一个下线请求。Nacos 会将该服务实例从服务列表中移除。
配置参数
Nacos 的心跳检测机制可以通过以下配置参数进行调整：
-
客户端配置:
heartbeat.interval.millis:- 设置客户端向 Nacos 服务器发送心跳报文的时间间隔（毫秒）。
- 示例配置：
properties1heartbeat.interval.millis=5000
-
服务端配置:
client.ip.timeout.millis:- 设置客户端 IP 的超时时间（毫秒），即 Nacos 服务器在没有收到客户端心跳报文后的等待时间。
- 示例配置：
properties1client.ip.timeout.millis=20000
示例配置
假设你想调整 Nacos 的心跳检测机制，可以在客户端和服务端的配置文件中设置相应的参数。以下是一个示例配置：
-
客户端配置:
- 在客户端的 Nacos 配置文件中设置心跳间隔时间为 5 秒：
properties1heartbeat.interval.millis=5000
- 在客户端的 Nacos 配置文件中设置心跳间隔时间为 5 秒：
-
服务端配置
-
1client.ip.timeout.millis=20000
-
注意事项
-
重启服务:
- 修改配置后，需要重启客户端和服务端以使更改生效。
-
集群环境:
- 在集群环境中，确保所有节点上的配置保持一致。
-
监控和告警:
- Nacos 提供了监控和告警功能，可以通过配置来监控服务实例的状态，并在服务实例出现问题时发送告警。
总结
Nacos 的心跳检测机制通过客户端定期发送心跳报文和服务器维护超时时间来确保服务实例的健康状态。通过调整配置参数，可以自定义心跳检测的时间间隔和超时时间。这些配置参数可以在客户端和服务端的配置文件中设置。确保在集群环境中保持配置的一致性，并在修改配置后重启服务。
Nacos、Zookeeper 和 Eureka 是三个不同的服务发现和配置管理平台，它们各自有一套心跳检测机制来监测服务实例的健康状况。尽管它们的目标相似，但具体实现有所不同。下面是这三个平台的心跳检测机制的概述：
Nacos 心跳检测机制
-
客户端注册服务实例:
- 服务实例启动时，向 Nacos 注册中心注册，并提供必要的元数据。
-
客户端发送心跳:
- 客户端定期向 Nacos 发送心跳报文，表明服务实例仍然活跃。
-
服务实例超时机制:
- Nacos 服务器维护一个超时时间阈值，如果在这个时间内没有收到服务实例的心跳报文，则认为该服务实例已失效。
-
服务实例状态更新:
- 当 Nacos 收到服务实例的心跳报文时，会更新该服务实例的状态。
-
服务实例下线:
- 当服务实例主动下线时，它会向 Nacos 发送一个下线请求。
Zookeeper 心跳检测机制
-
客户端连接建立:
- 客户端与 Zookeeper 建立连接时，会发送一个握手报文，并协商一个会话超时时间。
-
心跳报文发送:
- 客户端定期向 Zookeeper 发送心跳报文，以维持会话的活动状态。
-
超时机制:
- 如果 Zookeeper 在会话超时时间内没有收到客户端的心跳报文，则认为客户端已断开连接。
-
会话过期:
- 如果客户端的会话过期，它所创建的所有临时节点都会被删除。
Eureka 心跳检测机制
-
客户端注册服务实例:
- 服务实例启动时，向 Eureka 注册中心注册，并提供必要的元数据。
-
客户端发送心跳:
- 客户端定期向 Eureka 发送心跳报文，表明服务实例仍然活跃。
-
服务实例超时机制:
- Eureka 服务器维护一个超时时间阈值，如果在这个时间内没有收到服务实例的心跳报文，则认为该服务实例已失效。
-
服务实例状态更新:
- 当 Eureka 收到服务实例的心跳报文时，会更新该服务实例的状态。
-
服务实例下线:
- 当服务实例主动下线时，它会向 Eureka 发送一个下线请求。
-
自我保护模式:
- 当 Eureka 检测到网络分区时，会进入自我保护模式，以避免误删服务实例。
比较
-
Nacos:
- 客户端定期发送心跳。
- 服务端维护超时时间。
- 支持服务实例的下线操作。
- 可以通过配置文件调整心跳间隔和超时时间。
-
Zookeeper:
- 客户端与 Zookeeper 建立连接时协商超时时间。
- 客户端定期发送心跳报文。
- 会话过期会导致临时节点被删除。
- 不支持服务实例的下线操作，而是通过会话超时来判断。
-
Eureka:
- 客户端定期发送心跳。
- 服务端维护超时时间。
- 支持服务实例的下线操作。
- 具有自我保护模式，以避免在网络分区时误删服务实例。
总结
虽然 Nacos、Zookeeper 和 Eureka 都提供了心跳检测机制来监测服务实例的健康状况，但它们的实现细节存在一些差异。Nacos 和 Eureka 在服务实例管理和心跳检测方面更为相似，而 Zookeeper 主要关注于会话管理，并且具有不同的超时机制。每种服务发现平台都有其特点和适用场景，选择合适的平台取决于具体的应用需求。
3、均衡负载
该模块主要功能是负责将 请求经过一定策略均衡的分配到服务端，当我们的服务提供端同一个服务配置额多个实例（集群）时，就需要负载均衡模块协助分配请求到对应服务实例，如果服务配置单个，就不要此模块，但是为了保证高可用都会配置多个实例。
常见负载均衡策略：轮询、随机、权重轮询、ip hash、根据响应时间计算、最优策略等。
负载均衡模块对比：
4、服务降级、熔断（容错）
服务降级、熔断、限流是微服务架构保证高可用的得力助手，之所以出现这三兄弟，是因为我们的微服务与微服务直接相互调用，错综复杂，调用链路很长，如果微服务体系中某个服务宕机，就会造成微服务系统瘫痪，如下图：
服务降级： 在服务调用（消费）端做的一种兜底措施，当服务器处理结果不符合预期（服务响应超时、服务出错、宕机等），就把兜底的结果返回客户，以此保证服务消费方正常运行，不至于死等服务器结果，链路积压崩溃。
服务熔断：发生在服务提供方，包含三个状态，降级->熔断->恢复。当满足熔断条件时就会触发熔断，触发熔断首先会降级处理，返回兜底数据，然后开启熔断，熔断开启后，不管三七二十一，请求正确与否，都会在一段时间内返回兜底数据，然后尝试恢复，也就是放行请求，如果请求处理正常，就会关闭熔断。（后面章节会代码演示）
服务限流：服务限流是为了让服务器平稳的处理请求，也是对服务的一种保护措施，不至于把服务拖死，比如我的服务10S内最多同时处理50个请求，突然间来了100个请求，50个以外要么排队要么丢弃，同一时间内我的服务只处理50个请求，如果不做限流，100个请求压在服务端，服务器忙不过来的！就有崩溃风险。
常见主流的技术： HyStrix、Sentinel、Resilience4j（国外使用）
5、服务网关
网关是在我们的微服务基础上在封装的一层服务，网关后面是我们系统的各个微服务，负责转发前端请求到各个服务，就像公司前台一样，公司外部人员首先接触的是前台人员，再由前台人员对接公司内部人员。
网关的功能
- 针对所有请求进行登陆统一鉴权（登录态）、限流、缓存、日志（用户打点）。
- 可以根据不同的请求路径pattern，来进行请求的鉴权、转发、和拒绝。
- 协议转化。针对后段多种不同的协议，在网关层统一处理后以HTTP对外提供服务。
- 提供统一的错误码。
- 请求转发，并且可以基于网关实现内网与外网的隔离。Gateway(网关-Gateway - 知乎)
目前主流的网关(Gateway,与zuul)
Gateway和ZUUL介绍:网关-Gateway - 知乎
目前主流技术为getway,zuul已经跟不上时代步伐了，因为他底层采用的是servlet，servlet是一种阻塞io，满足不了高并发场景，而且不支持任何长连接，而getway后期新秀，底层采用netty做支撑，是一种异步非阻塞io，处理请求能力远远强于 servlet。
6、配置中心
配置中心的存在主要是为了解决大量微服务下的公共配置以及动态配置问题，我们都知道，每个微服务是由springboot做支撑，每个springboot项目都会有一个application的配置文件，如果某些配置发生变化，得一个一个服务去修改，这样加大维护工作量，特别是运维老哥！ 另外每次修改配置还得重启服务，因此对动态配置也有强烈需求，基于这样的背景而产生配置中心模块。
常见配置中心技术支持有： springCloud config，nacos(主流并替换个config)。
7、服务总线
服务总线，顾名思义他是为我们所有服务提供服务，在微服务体系中通常会有一些公共的消息，比如上步骤提到的动态配置，就需要服务总线的支撑，各个微服务向服务总线订阅消息，进而监听总线，当总线发生变动时，订阅的服务可以感知，然后同步更新自己，服务总线一般搭配着消息中间件，如RabbitMq（MQ）、kafka等，此外服务总线还具有定点通知某个或多个服务的功能
总之服务总线就像一个妈妈管着一群孩子一样，通过妈妈向所有孩子或者某个孩子传达消息，从而改变孩子的某些行为或功能。
常见技术支撑有： springcloud bus，nacos
文档引用URL:https://www.zhihu.com/question/45413135/answer/547375094
文档引用:百度安全验证
https://baijiahao.baidu.com/s?id=1735036776620471897&wfr=spider&for=pc
文档引用:文档引用:百度安全验证https://baijiahao.baidu.com/s?id=1735036776620471897&wfr=spider&for=pc
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
