Dubbo

一、Dubbo简介 Dubbo是一个分布式服务框架，支持高性能远程调用，提供SOA服务治理解决方案。Ddubbo各个分层都是很多扩展，比如注册中心有redis、zookeeper选项，序列化有java序列化等，当然还有很多,这里就不一一介绍了。 二、核心部分 2.1、远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。 2.2、集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。 2.3、自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以减少机器。 三、作用 3.1、透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 3.2、软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 3.3、 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 四、使用 4.1、当我们在多个Tomcat部署不同的系统时, 例如A系统(TomcatA)想调用B系统(TomcatB)中的服务, 这时Dubbo就有了用武之地. 首先我们需要B系统在注册中心将自己的Url注册进去,

在收到提供者执行的结果时，当结果处理失败时，需要对其进行处理。 在Reference中，返回的Invoker是根据对应的容错机制生成的Invoker <dubbo:reference id="testService" interface="com.test.ITestService" cluster="failfast"/> failover cluster 失败的时候自动切换并重试其他服务器。 通过retries=2。 来设置重试次数（默认） failfast cluster 快速失败，只发起一次调用 ; 写操作。比如新增记录的时候， 非幂等请求 failsafe cluster 失败安全。 出现异常时，直接忽略异常 – 写日志 failback cluster 失败自动恢复。 后台记录失败请求，定时重发 forking cluster 并行调用多个服务器，只要一个成功就返回。 只能应用在读请求 broadcast cluster 广播调用所有提供者，逐个调用。.3其中一台报错就会返回异常 @SPI(FailoverCluster.NAME) public interface Cluster { @Adaptive <T> Invoker<T> join(Directory<T> directory) throws RpcException; } FailoverCluster

读累了就看看实操 https://www.cnblogs.com/huasky/p/10214642.html 一、SOA 概念：SOA：Service-Oriented Architecture，面向服务的架构，将应用程序的不同功能(服务)通过定义的接口来实现数据通信；服务治理；服务调度中心和治理中心； 架构演变：单一应用架构ORM | 垂直应用架构MVC | 分布式服务架构RPC | 流动计算架构SOA ORM ：流量小，单一应用，部署一起；关注于简化增删改查的对象关系映射， MVC ：流量增加，应用拆分；关注于提高前端开发速度； RPC ：远程过程调用；通过网络进行远程计算机服务的请求；核心业务抽取；关注于业务的复用和整合； 由统一到分布式： 使用场景由混乱到统一： SOA又叫服务治理，SOA就是帮助我们把服务之间调用的乱七八糟的关系给治理起来，然后提供一个统一的标准； 统一标准：各系统的协议、地址、交互方式。 新的交互方式：各个系统分别根据统一标准向数据总线进行注册，各子系统调用其他子系统时，我们并不关心如果找到其他子系统，我们只招数据总线，数据总线再根据统一标准找其他子系统，所以数据总线在这里充当一个只路人的作用。 数据总线是起到调度服务的作用，数据总线不是集成服务，数据总线更新一个调度框架，每个服务需要根据约定向数据总线注册服务；服务不是经过总线的

查看zookeeper中dubbo服务的生产者和消费者注册信息： cd /usr/local/wutongyu/tools/zookeeper/ //进入zookeeper安装目录 ./bin/zkCli.sh -server 192.168.0.1:2181 //链接 ls /dubbo //会看到dubbo服务提供的对外接口，及消息提供者 ls /dubbo/com.wutongyu.service.dubbo.ElasticsearchDubboService/consumers //查看消费者命令 ls /dubbo/com.wutongyu.service.dubbo.ElasticsearchDubboService/providers //查看服务提供者命令 ———————————————— 版权声明：本文为CSDN博主「wutongyuWxc」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/wutongyuWxc/article/details/87374780 来源： CSDN 作者： MakeGreatEffort 链接： https://blog.csdn.net/qq_36838191/article/details/103986025

在这只是记录： SpringBoot与ali的dubbo版本问题 在springBoot1.0+的项目中，dubbo的版本应是2.6.5(不包括)以下，而dubbo与springBoot的中间件(dubbo-starter.version)应是2.0.0以下。 在springBoot2.0+的项目中，dubbo的版本应是2.6.5(包括)以上，dubbo-starter.version是2.0.0(包括)以上 <dubbo-starter.version>2.0.0</dubbo-starter.version> <dubbo.version>2.6.5</dubbo.version> <zkclient.version>0.10</zkclient.version> <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>${dubbo.version}</version> </dependency> <dependency> <groupId>com.alibaba.spring.boot</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>${dubbo-starter

dubbo是一个服务治理中间件，一个分布式高性能的RPC远程调用框架，Dubbo一般和Zookeeper组合使用，Dubbo由容器（Spring容器）、服务生产者、注册中心（Zookeeper）服务消费者和监控中心组成，运行流程为容器启动时，服务生产者会把自己的服务接口地址注册到注册中心，服务消费者订阅它需要的服务，他去查询注册中心，获取服务地址，拿到地址去调用服务，监控中心监控生产者和消费者的健康状态，消费者的具体消费过程为：client一个线程调用远程接口，生成一个唯一id，将打包的方法和调用信息（如调用的接口名称，方法名称，参数列表）和处理结果的回调对象callback，全部封装在一起，组成一个对象Object，向专门存放调用信息的全局ConcurrentHashMap里面存放ID和对象，在将id和对象封装成一个对象ConnRequest对象，使用IoSession.write异步发送出去，当当前线程尝试获取远程调用的结果时，要先检查是否获取到结果，没有则让当前线程等待，服务器收到异步请求处理后，将结果发送给客户端，结果包含前面的id，客户端socket连接上专门监听消息的线程收到消息，分析结果，去到id在从前面的concurrentHahMap里面知道回调对象，唤醒前面等待的线程 Zookeeper是为分布式提供一致性的软件

dubbo与http区别 相关概念 RPC、REST、Dubbo、HTTP、RMI区别 RPC、REST区别，通俗讲两者API设计风格不同，如下： 功能 RPC RESTful 提交功能 POST/submit POST/goods 查看商品列表 GET/lists?index=1 POST/goods/1234 两种风格的API区别： RPC面向过程，只发送 GET 和 POST 请求。GET用来查询信息，其他情况下一律用POST。请求参数是动词，直接描述动作本身。 RESTful面向资源，使用 POST、DELETE、PUT、GET 请求，分别对应增、删、改、查操作。请求参数是名词，这个名词就是“增删改查”想要操作的对象。 RPC与dubbo区别 PRC全称是Remote Procedure Call，即远程过程调用<通信方式的一种>,不仅仅是一种api设计风格。这个"远"的概念也不一定是跨越网络的，同一台主机的两个进程之间相互交流也完全可以是RPC。 Dubbo是一种分布式服务框架也是一种协议，dubbo框架默认使用dubbo协议。dubbo协议是阿里巴巴自己实现的一种应用层协议，传输层还是TCP。所以Dubbo协议与HTTP、FTP，SMTP这些应用层协议是并列的概念。除了默认的Dubbo协议，Dubbo框架还支持RMI、Hessian、HTTP等协议。

1、配置原则 JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。 XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。 Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。 2、启动检查 Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check="true"。 可以通过 check="false" 关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。 另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务，请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果 check="false"，总是会返回引用，当服务恢复时，能自动连上。 通过 dubbo.properties dubbo.reference.com.foo.BarService.check =false 关闭某个服务的启动时检查 (没有提供者时报错) dubbo.reference.check =false dubbo.consumer.check

Dubbox的介绍和简单示例 https://github.com/dangdangdotcom/dubbox http://www.sohu.com/a/115234862_464071 Dubbo是一个来自阿里巴巴的开源分布式服务框架，当当根据自身的需求，为Dubbo实现了一些新的功能，包括REST风格远程调用、Kryo/FST序列化等等。并将其命名为Dubbox（即Dubbo Extensions） Demo地址：https://github.com/wosyingjun/DubboxDemo 类似范例：http://wosyingjun.iteye.com/blog/2312553 Dubbo架构 Provider: 暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。 Registry: 服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。 Container: 服务运行容器。 为什么使用Dubbox而不是Dubbo Dubbo是阿里开源的RPC服务调用框架，已经3年没有维护了,而当当网开源的Dubbox在保证Dubbo原有功能的基础上做了一系列优化。 使用Dubbox的好处 支持REST风格远程调用（HTTP + JSON/XML)：基于非常成熟的JBoss RestEasy框架，在dubbo中实现了REST风格

配置来源 首先，从Dubbo支持的配置来源说起，默认有四种配置来源： JVM System Properties，-D参数 Externalized Configuration，外部化配置 ServiceConfig、ReferenceConfig等编程接口采集的配置 本地配置文件dubbo.properties 覆盖关系 下图展示了配置覆盖关系的优先级，从上到下优先级依次降低： JVM启动-D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。 XML次之，如果在 XML 中有配置，则dubbo.properties中的相应配置项无效。 Properties最后，相当于缺省值，只有XML没有配置时，dubbo.properties的相应配置项才会生效，通常用于共享公共配置，比如应用名。 配置原则 推荐 dubbo推荐在Provider上尽量多配置Consumer端属性： 1、作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等 2、在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的 覆盖规则 方法级优先，接口级次之