SpringCloud整合dubbo3 和 nacos

转载

mob64ca13f9e726 2024-10-11 06:29:17

对比参照表：

name	Dubbo	springcloud
服务注册中心	Zookeeper	SpringCloud Netflix Eureka
服务调用方式	RPC	REST Api
服务监控	Dubbo-monitor	Spring Boot Admin
断路器	不完善	SpringCloud Netflix Hystrix
服务网关	无	SpringCloud Netflix Zuul
分布式配置	无	SpringCloud Config
服务跟踪	无	SpringCloud Sleuth
消息总线	无	SpringCloud Bus
数据流	无	SpringCloud Stream
批量任务	无	SpringCloud task

SpringCloud整合dubbo3 和 nacos_Cloud

名词解释：

SpringCloud Netflix Eureka：
                     eureka服务:用以提供服务注册、发现
                     eureka-server: 相对client端的服务端，为客户端提供服务
                     eureka-client:客户端，通过向eureka服务发现注册的可用的eureka-server，向后端发送请求
REST Api：
                     是通信方式，不同与Dubbo的RPC通信
Spring Boot Admin：
                    当前处于活跃状态的会话数量、当前应用的并发数、延迟以及其他度量信息
SpringCloud Netflix Hystrix：
                    Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效                        请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
SpringCloud Netflix Zuul：
                     它就解决了上面的问题，你想调用某个服务，它会给你映射，把你服务的IP地址映射成某个路径，你输入该路径，                       它匹配到了，它就去替你访问这个服务，它会有个请求转发的过程，像Nginx一样，服务机器的具体实例，它不会                         直接去访问IP，它会去Eureka注册中心拿到服务的实例ID，即服务的名字。我再次使用客户端的负载均衡ribbon访                       问其 中服务实例中的一台。API网关主要为了服务本身对外的调用该怎么调用来解决的，还有解决权限校验的问                           题，你可以在这里整合调用一系列过滤器的，例如整合shiro,springsecurity之类的东西

SpringCloud Config：

SpringCloud整合dubbo3 和 nacos_客户端_02

a.spring cloud config server 作为配置中心的服务端：

　　　　1.拉取配置时更新git仓库副本，保证是最新结果

　　　　2.支持数据结构丰富，yml, json, properties 等

　　　　3.配合 eureke 可实现服务发现，配合 cloud bus 可实现配置推送更新

　　　　4.配置存储基于 git 仓库，可进行版本管理

　　　　5.简单可靠，有丰富的配套方案

　　b.Spring Cloud Config Client 客户端：

　　　　1.Spring Boot项目不需要改动任何代码，加入一个启动配置文件指明使用ConfigServer上哪个配置文件即可

SpringCloud Sleuth:

随着分布式系统越来越复杂，你的一个请求发过发过去，各个微服务之间的跳转，有可能某个请求某一天压力太大了，一个请求过去没响应，一个请求下去依赖了三四个服务，但是你去不知道哪一个服务出来问题，这时候我是不是需要对微服务进行追踪呀？监控一个请求的发起，从服务之间传递之间的过程，我最好记录一下，记录每一个的耗时多久，一旦出了问题，我们就可以针对性的进行优化，是要增加节点，减轻压力，还是服务继续拆分，让逻辑更加简单点呢？这时候springcloud-sleuth集成zipkin能帮我们解决这些服务追踪问题。

Span：基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)
span在不断的启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。
Trace：一系列spans组成的一个树状结构，例如，如果你正在跑一个分布式大数据工程，你可能需要创建一个trace。
Annotation：用来及时记录一个事件的存在，用于定义请求的开始和停止的一些核心注释是：

　　1.cs- Client Sent -客户端发起一个请求，这个annotion描述了这个span的开始

　　2.sr- Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟

　　3.ss- Server Sent -注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间

　　4.cr- Client Received -表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间

SpringCloud Bus:

你的配置信息改变了，需要及时修改内存中的配置信息。这时候我们就不要忘记消息队列的发布订阅模型。让所有为服务来订阅这个事件，当这个事件发生改变了，就可以通知所有微服务去更新它们的内存中的配置信息。这时Bus消息总线就能解决，你只需要在springcloud Config Server端发出refresh，就可以触发所有微服务更新了。

Spring Cloud Bus除了支持RabbitMQ的自动化配置之外，还支持现在被广泛应用的Kafka。

SpringCloud Stream:

是一个构建消息驱动微服务的框架,应用程序通过 inputs 或者 outputs 来与 Spring Cloud Stream 中binder 交互，通过我们配置来 binding ，而 Spring Cloud Stream 的 binder 负责与消息中间件交互。所以，我们只需要搞清楚如何与 Spring Cloud Stream 交互就可以方便使用消息驱动的方式。通过使用Spring Integration来连接消息代理中间件以实现消息事件驱动。Spring Cloud Stream 为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。目前仅支持RabbitMQ、Kafka。

SpringCloud整合dubbo3 和 nacos_客户端_03