dubbo和eureka的区别？dubbo原理和机制是什么

本文目录

• dubbo和eureka的区别
• dubbo原理和机制是什么
• dubbo是局域网还是广域网
• dubbo和spring cloud区别
• Dubbo简介
• dubbo原理和机制
• spring cloud和dubbo哪个会被淘汰

dubbo和eureka的区别

dubbo和spring cloud区别是：

1、初始定位不同：

 SpringCloud定位为微服务架构下的一站式解决方案；Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理。

2、生态环境不同：

 SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。

3、调用方式： 

SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。

4、组件差异：

例如SpringCloud注册中心一般用Eureka，而Dubbo用的Zookeeper，SpringCloud生态丰富，功能完善，更像是品牌机，Dubbo则相对灵活，可定制性强，更像是组装机。

5、SpringCloud：

Spring公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案。

6、Dubbo：

阿里巴巴开源的RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。

两者的生态对比：

1、Spring Cloud 的功能很明显比 Dubbo 更加强大，涵盖面更广，而且作为 Spring 的旗舰项目，它也能够与 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 项目完美融合，这些对于微服务而言是至关重要的。

2、使用 Dubbo 构建的微服务架构就像组装电脑，各环节选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心。

3、而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础原理有足够的了解。

dubbo原理和机制是什么

dubbo原理和机制：应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

扩展资料：

Dubbo是使用AtomicLong从0开始累计数字的，将打包的方法调用信息（如调用的接口名称，方法名称，参数值列表等），和处理结果的回调对象callback，全部封装在一起，组成一个对象object向专门存放调用信息的全局ConcurrentHashMap里面put(ID, object)将ID和打包的方法调用信息封装成一对象connRequest，使用IoSession.write(connRequest)异步发送出去。

当前线程再使用callback的get()方法试图获取远程返回的结果，在get()内部，则使用synchronized获取回调对象callback的锁， 再先检测是否已经获取到结果，如果没有，然后调用callback的wait()方法，释放callback上的锁，让当前线程处于等待状态。

参考资料来源：百度百科-Dubbo

dubbo是局域网还是广域网

dubbo局域网和广域网都可以接。局域网是指在某一区域内由多台计算机互联成的计算机组。一般是方圆几千米以内。将各种计算机，外部设备和数据库等互相联接起来组成的计算机通信网。它可以通过数据通信网或专用数据电路，与远方的局域网、数据库或处理中心相连接，构成一个较大范围的信息处理系统。广域网是连接不同地区局域网或城域网计算机通信的远程网，主要使用分组交换技术，不同于互联网。广域网通常跨接很大的物理范围，覆盖的范围比局域网和城域网都广，所覆盖的范围从几十公里到几千公里，它能连接多个地区、城市和国家，或横跨几个洲并能提供远距离通信，形成国际远程网络。

dubbo和spring cloud区别

dubbo和spring cloud的定位不同。Dubbo的定位始终是一款RPC框架，而SpringCloud的目标是微服务架构下的一站式解决方案。Dubbo可以类比到Netflix OSS技术栈，而Spring Cloud集成了Netflix OSS作为分布式服务治理解决方案，但除此之外Spring Cloud还提供了配置、消息、安全、调用链跟踪等分布式问题解决方案。Spring Cloud是一系列微服务框架的有序集合，而Dubbo有两中常见理解，一种是狭义的理解，一种是广义的。狭义的Dubbo，指的是一款高性能的RPC框架，广义的Dubbo值得是一整套微服务解决方案！ 简而言之，Dubbo确实类似于Spring Cloud的一个子集，Dubbo功能和文档完善，在国内有很多的成熟用户。 Dubbo具有调度、发现、监控、治理等功能，支持相当丰富的服务治理能力。Dubbo架构下，注册中心对等集群，并会缓存服务列表已被数据库失效时继续提供发现功能，本身的服务发现结构有很强的可用性与健壮性，足够支持高访问量的网站。 SpringCloud有众多子项目组成，这其中有Spring Cloud Netflix，Spring Cloud Config，Spring Cloud Consul，Spring Cloud Alibaba，包含了Dubbo整套。SpringCloud提供了搭建分布式系统及微服务常用的工具，如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等，满足了构建微服务所需的所有解决方案。

Dubbo简介

Dubbo是Alibaba开源的分布式服务框架，它按照分层的方式来架构，使用这种方式可以使各层解耦。 Dubbo在调用远程的服务的时候再本地有一个接口，就想调用本地方法一样去调用，底层实现好参数传输和远程服务运行结果传回之后的返回。 Dubbo的特点： （1）它主要使用高效的网络框架和序列化框架，让分布式服务之间调用效率更高。 （2）采用注册中心管理众多的服务接口地址，当你想调用服务的时候只需要跟注册中心询问即可，不像使用WebService一样每个服务都得记录好接口调用方式。 （3）监控中心时实现服务方和调用方之间运行状态的监控，还能控制服务的优先级、权限、权重、上下线等，让整个庞大的分布式服务系统的维护和治理比较方便。 （4）高可用，如果有服务挂了，注册中心就会从服务列表去掉该节点，客户端会像注册中心请求另一台可用的服务节点重新调用。同时注册中心也能实现高可用（ZooKeeper）。 （5）负载均衡，采用软负载均衡算法实现对多个相同服务的节点的请求负载均衡。 Dubbo需要四大基本组件：Rigistry,Monitor,Provider,Consumer。1、监控中心的配置文件-dubbo.properties文件 （1）容器，监控中心是在jetty和spring环境下运行，依赖于注册中心，日志系统是log4j     dubbo.container = log4j,spring,registry,jetty （2）监控服务的名称，监控系统对整个Dubbo服务系统来说也是一个服务     dubbo.application.name = simple-monitor （3）服务的所有者，这是Dubbbo的服务的功能，可以指定服务的负责人     dubbo.application.owner = coselding （4）注册中心的地址，配置后监控中心就能通过注册中心获取当前可用的服务列表及其状态，在页面向你汇报Dubbo中的服务运行情况。     dubbo.registr.address = multicast://{ip}:{port} //广播     dubbo.registr.address = zookeeper://{ip}:{port} //zookeper     dubbo.registr.address = redis://{ip}:{port} //redis     dubbo.registr.address = dubbo://{ip}:{port} //dubbo （5）dubbo协议端口号     dubbo.protocol.port = 7070 （6）jetty工作端口号     dubbo.jetty.port = 8082 （7）工作目录，用于存放监控中心的数据     dubbo.jetty.directory = ${user.home}/monitor （8）监控中心报表存放目录     dubbo.charts.directory=${dubbo.jetty.directory}/charts （9）监控中心数据资料目录     dubbo.statistics.directory=${user.home}/monitor/statistics （10）监控中心日志文件路径     dubbo.log4j.file=logs/dubbo-monitor-simple.log （11）监控中心日志记录级别     dubbo.log4j.level=WARN 2、Dubbo提供负载均衡方式 （1）Random，随机，按权重配置随机概率，调用量越大分布越均匀，默认方式。 （2）RounRobin，轮询，按权重设置轮询比例，如果存在比较慢的机器容易在这台机器上请求阻塞较多。 （3）LeastActive，最少活跃调用数，不支持权重，只能根据自动识别的活跃数分配，不能灵活调配。 （4）ConsistenHash，一致性hash，对相同参数的请求路由到一个服务提供者上，如果有类似灰度发布需求可采用。 3、Dubbo过滤器 Dubbo初始化过程加载ClassPath下的META-INF/dubbo/internal/，META-INF/dubbo/，META-INF/services/三个路径下的com.alibaba.dubbo.rpc.Filter文件。文件内容：     Name = FullClassName,这些类必须实现Filter接口。自定义Filter类： 配置文件在配置过滤器，consumer.xml中：Dubbo对过滤器的加载过程：     先加载三个路径下的com.alibaba.dubbo.rpc.Filter文件里面的键值对，key为过滤器名称，value为过滤器的类的全限定名(这个类必须实现Dubbo中的Filter接口)。     自定义的类中@Active注解是过滤器设定的全局基本属性。     Spring在加载consumer.xml文件时，通过 《dubbo:consumer filter="xxx" id = "xxx" retrries = "0"》这个配置指定消费者端要加载的过滤器，通过filter属性指定过滤器名称。 @Activate注解-自动激活，group属性是表示匹配了对应的角色才被加载，value表示表明过滤条件，不写则表示所有条件都会被加载，写了则只有dubbo URL中包含该参数名且参数值不为空才被加载，这个参数会以dubbo协议的一个参数K-V对传到Provider。 4、Dubbo的Provider配置 5、Dubbo的Consumer配置 1、Dubbo是什么？ Dubbo是阿里巴巴开源的基于Java的高性能RPC分布式框架。 2、为什么使用Dubbo？ 很多公司都在使用，经过很多线上的考验，内部使用了Netty，Zookeeper，保证了高性能可用性。 使用Dubbo可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可以提高业务复用灵活性扩展，使前端应用能快速的响应对边的市场需求。分布式架构可以承受更大规模的并发流量。 Dubbo的服务治理图： 3、Dubbo和Spring Cloud的区别 两个没有关联，但是非要说区别，有如下几点： （1）通信方式不同，Dubbo使用RPC通信，Spring Cloud使用HTTP Restful方式 （2）组成部分不同4、Dubbo支持的协议 dubbo://  （推荐）；rmi:// ；hessian:// ； 28、Spring boot整合Dubbo （1）添加依赖         《!-- https://mvnrepository.com/artifact/com.alibaba.boot/dubbo-spring-boot-project --》         《dependency》             《groupId》com.alibaba.boot《/groupId》             《artifactId》dubbo-spring-boot-starter《/artifactId》             《version》0.1.0《/version》         《/dependency》         《!-- https://mvnrepository.com/artifact/com.101tec/zkclient --》         《dependency》             《groupId》com.101tec《/groupId》             《artifactId》zkclient《/artifactId》             《version》0.10《/version》         《/dependency》（2）配置dubbo     ## Dubbo 服务提供者配置     spring.dubbo.application.name=provider     spring.dubbo.registry.address=zookeeper://127.0.0.1:2181     spring.dubbo.protocol.name=dubbo     spring.dubbo.protocol.port=20880     spring.dubbo.scan=org.spring.springboot.dubbo    ## Dubbo 服务消费者配置     spring.dubbo.application.name=consumer     spring.dubbo.registry.address=zookeeper://127.0.0.1:2181     spring.dubbo.scan=org.spring.springboot.dubbo

dubbo原理和机制

dubbo原理和机制：应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

扩展资料

在大规模dubbo服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。

(1)当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。

此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。

并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。

(2)当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。

这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。

(3)接着，服务的调用量越来越大，服务的容量问题就暴露出来。

为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。

其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

spring cloud和dubbo哪个会被淘汰

事实上，很多系统根本就没必要用什么所谓微服务。目前过度设计已经泛滥，明明是一个用户数量有限，功能并不复杂的系统，也要套用所谓的微服务架构，或者要大搞所谓中台，既浪费时间，又浪费金钱，最后系统运维还比较复杂，需要持续投入运维。

以服务调用的方式，固然可以有更好的复用性，也可以解耦复杂系统。但实际上，我认为微服务也仅仅是组件化的一种实现方式。对于组件化，广义的讲，有多种实现方式：

第一种，最原始的方式就是以静态函数库或者包的形式存在。这种形式优点是开发方式简单，调用效率高，数据以参数方式进行传递，但耦合度也高，底层组件函数一旦发生变化，则需要重新编译整个工程。通常对于不经常发生变化的基础函数库，可以用这种形式进行开发，形成所谓的公共函数库，供大家使用。

第二种，称之为动态函数库，在windows环境下以dll形式存在，linux环境下以so形式存在。动态函数库相对于静态函数库，优势在于可以在运行时动态加载，可以在不用重新启动整个应用的情况下进行更新。缺点是动态函数不能共享原应用程序的存储空间，导致动态函数调用有时需要传递大量参数，导致一些不便。动态函数库也具有一定耦合度，函数名和参数必须严格按照约定调用，否则会报错。在早期单体架构下，动态函数库还是有大量使用的。

第三种，就是目前所谓的微服务架构了。微服务事实上也是可以看作是一种函数调用方式，提供基于RPC和restful远程调用方式。调用时需要传递调用的服务名称及数据报文。这种方式耦合度自然是比较低一些的，但是调用效率肯定低于函数调用方式，主要是数据传输和报文解析方面消耗的时间。此外还需要考虑通讯流量控制，超时机制，服务寻址，服务可用性等方面的问题。因而降低耦合度，事实上是以增加了系统的整体复杂度和降低调用效率为代价的。个人认为不应该过度解耦，或者仅仅强调可复用性。要知道，任何事情都是有代价的，必须要充分评估这种代价是否值得。

第四种，就更进一步，即以独立的系统存在，该系统具有独立性和完备性，可以不过于依赖其他外部系统独立运行，对外部以服务或api的形式进行交互。例如，单点登录系统，信贷系统，核心系统等。

因而，在系统架构设计和建设过程中，必须认真进行评估，不应该过分侧重于某一方面特性的实现，否则就是过犹不及，最后导致整体出现问题。

个人认为，目前大部分所谓基于微服务的中台系统就是陷入了过于强调解耦的误区，导致过度的解耦设计，而忽略了由此带来的弊端，最后陷入了泥潭。