dubbo是什么框架,Dubbo简介及优缺点

dubbo是什么框架,Dubbo简介及优缺点详细介绍

本文目录一览： 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文件时，通过

这个配置指定消费者端要加载的过滤器，通过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:// ；http:// ；webservice:// ；thrift:// ；memcached:// ；redis:// ；rest:// 。

5、Dubbo需要容器吗？

不需要，如果硬要容器的话，会增加复杂性，同时也浪费资源。

6、Dubbo内置的服务容器

Spring Container；Jetty Container；Log4j Container。

7、Dubbo中节点角色

Register，Monitor，Provider，Consumer，Container(服务运行的容器)。

8、Dubbo的服务注册和发现的流程图

9、Dubbo的注册中心

默认使用Zookeper作为注册中心，还有Redis，Multicast，dubbo注册中心。

10、Dubbo的配置方式

Spring配置方式和Java API配置方式

11、Dubbo的核心配置

（1）dubbo:service 服务配置

（2）dubbo:referece 引用配置

（3）dubbo:protocol 协议配置

（4）dubbo:application 应用配置

（5）dubbo:registry 注册中心配置

（6）dubbo:monitor 监控中心配置

（7）dubbo:provider 提供方配置

（8）dubbo:consumer 消费方配置

（9）dubbo:method 方法配置

（10）dubbo:argument 参数配置

12、在Provider 节点上可以配置Consumer端的属性有哪些？

（1）timeout：方法调用超时

（2）retries：失败重试次数，默认是2次

（3）loadbalance：负载均衡算法，默认随机

（4）actives消费者端，最大并发调用控制

13、Dubbo启动时如果依赖的服务不可用会怎样

Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成。默认check ="true"。

14、Dubbo序列化框架

推荐使用Hessian序列化，还有Dubbo，FastJson，Java自带序列化。

15、Dubbo的通信框架

默认使用Netty框架，另外也提供了Mina，Grizzly。

16、Dubbo集群容错方案

（1）Failover Cluster，失败自动切换，自动重试其他服务器。

（2）Failfast Cluster，快速失败，立即报错，只发起一次调用。

（3）Failsafe Cluster，失败安全，出现异常时，直接忽略。

（4）Failback Cluster，失败自动恢复，记录失败请求，定时重发。

（5）Forking Cluster，并行调用多个服务器，只要一个返回成功即可。

（6）Broadcast Cluster，广播逐个调用所有提供者，任意一个报错则报错。

17、Dubbo的负载均衡策略

（1）Random LoadBalance，随机，按权重设置随机概率，默认。

（2）RoundRobin LoadBalace，轮询，按公约后的权重设置轮训比例。

（3）LeastActive LoadBalace，最少活跃调用数，相同活跃数的随机。

（4）ConsistenHash LoadBalance，一致性hash，相同参数的请求总是发到用一个服务器。

18、指定某一个服务

可以配置环境点对点直连，绕过注册中心，将以服务接口为单位，忽略注册中心的提供者列表。

19、Dubbo多协议

Dubbo允许配置多协议，在不同服务器上支持不同协议，或者同一服务支持多种协议。

20、当一个服务有多种实现时怎么做？

当一个接口有多种是现实，可以用group属性来分组，服务提供方和消费方都指定同一个group即可。

21、兼容旧版本

使用版本号过度，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。

22、Dubbo可以缓存吗？

Dubbo提供声明式缓存，用于加速热门数据的访问速度，以减少用户加缓存的工作量。

23、Dubbo服务之间的调用时阻塞的吗？

默认是同步等待结果阻塞的，支持异步调用。Dubbo是基于NIO的非阻塞实现并行调用的，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个Future对象。

24、Dubbo不支持分布式事务

25、Dubbo必须依赖的包

Dubbo必须依赖JDK，其他为可选。

26、Dubbo使用过程中的问题

Dubbo的设计目的是为了满足高并发小数据量的rpc请求，在大数据量下性能表现不是很好，建议使用rmi或http协议。

27、Dubbo的管理控制台的作用

路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡。

28、Spring boot整合Dubbo

（1）添加依赖

????????

? ? ? ?

? ? ? ? ? ?

com.alibaba.boot

? ? ? ? ? ?

dubbo-spring-boot-starter

? ? ? ? ? ?

0.1.0

? ? ? ?

? ? ? ?

? ? ? ?

? ? ? ? ? ?

com.101tec

? ? ? ? ? ?

zkclient

? ? ? ? ? ?

0.10

? ? ? ?

（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

[TOC]
1.Dubbo是什么
Apache Dubbo 是一款高性能Java RPC框架。
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东， 说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册） 其核心部分包含:
2.Dubbo能做什么
Dubbo采用全spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。
3.Dubbo架构
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
调用关系说明：
4.Dubbo的使用方法
Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。如果不想使用Spring配置，可以通过API的方式进行调用（注解式，不推荐使用）
下载安装zookeeper注册中心（不建议使用multicast）
1.Windows
下载地址：https://www.apache.org/dyn/closer.cgi/zookeeper/
使用方法：下载解压即可，进入解压目录运行zkServer.cmd启动注册服务中心
截图：
2.MacOS
下载地址：https://www.apache.org/dyn/closer.cgi/zookeeper/
使用方法：下载解压即可，进入解压目录运行zkServer.sh start启动注册服务中心
3.Linux
下载地址：https://www.apache.org/dyn/closer.cgi/zookeeper/
使用方法：下载解压即可，进入解压目录运行zkServer.sh start启动注册服务中心
服务提供者
1.定义服务接口(该接口需单独打包，在服务提供方和消费方共享)
DemoService.java
2.服务提供方实现接口：(对服务消费方隐藏实现)
DemoServiceImpl.java
dubbo-provider.xml：
4.加载Spring配置，启动服务：
Provider.java：
或者使用springBoot启动
服务消费者：
applicationContext-dubbo.xml 中注册自己需要调用的接口。
1.通过Spring配置引用远程服务
dubbo-consumer.xml：
2.加载Spring配置，并调用远程服务：
Consumer.java
或者使用springBoot启动
并添加对应的restful接口提供接口访问
修改对应index页面
3.dubbo管理页面：
启动后访问 http://localhost:8080/dubbo-admin/
输入账号密码root/root
应用页面：
提供者页面:
消费者页面：
服务页面：
测试是否成功，只要看状态是否正常，就ok了 ....
provider-log:
5.使用Dubbo可能遇到的问题
1、org.springframework.beans.factory.BeanCreationException
原因分析：
解决方案
2、org.apache.dubbo.rpc.RpcException
原因分析
解决方案
可能是因为providers没有启动，或者是provider对应暴露的服务被禁用，启动providers或者解除禁用即可
3、java.lang.IllegalStateException
原因分析
解决方案
总结以上两点，通俗点讲，就是重启了工程（可能是因为直接修改代码，工程reload了）， 并且，连过了数据库（登录等），才出现了上述报错信息。原因是因为在tomcat重启的时候，之前的tomcat的线程还没有完全关闭，最新启动tomcat就会报这个异常。
4、org.apache.dubbo.remoting.TimeoutException
原因分析
解决方案
在dubbo-provider.xml增加超时时间

什么是dub

1、dub是的Dubbo缩写。2、Dubbo实现风格上与java传统的RMI、EJB技术都是非常相似的，在整个的开发处理之中依然是以接口（远程接口）为主进行服务提供的。3、Dubbo是一个分布式的服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是SOA服务化治理方案的核心框架。

dubbo通俗一点的理解是干什么用的？

Dubbo是一种服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。
主要的核心部件：
Remoting: 网络通信框架，实现了 sync-over-async 和
request-response 消息机制.
RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能
Registry: 服务目录框架用于服务的注册和服务事件发布和订阅

Dubbo分布式服务框架介绍

随着业务的发展、用户量的增长、系统并发访问需求越来越大，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。而Dubbo则是SOA服务化治理方案的一个核心框架。
Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。
Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出和输入功能，和Spring框架可以无缝集成。
作为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括：
Dubbo最大的特点是按照分层架构思维构建应用服务，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出 服务提供方（Provider） 和 服务消费方（Consumer） 两个角色。
Dubbo包含 远程通讯、服务集群和服务发现与注册 三个核心部分。提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
Dubbo服务组件调用关秕说明 ：
Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。
下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：
从上图可以看出， Dubbo对于服务提供方和服务消费方，从框架的10层中分别提供了各自需要关心和扩展的接口，构建整个服务生态系统（服务提供方和服务消费方本身就是一个以服务为中心的） 。
根据官方提供的，对于上述各层之间关系的描述，如下所示：

小白也能看懂的dubbo3应用级服务发现详解

dubbo 是一款开源的 RPC 框架，主要有3个角色： 提供者（provider） 、 消费者（consumer） 、 注册中心（registry）
提供者启动时向注册中心注册服务地址，消费者启动时订阅服务，并通过获取到的提供者地址发起调用，当提供者地址变更时，通过注册中心向消费者推送变更。这就是 dubbo 主要的工作流程。
在2.7.5之前，dubbo 只支持接口级服务发现模型，>=2.7.5的版本提供了接口级与应用级两种服务发现模型，3.0之后的版本应用级服务发现更是非常重要的一个功能。
本文将从为什么需要引入应用级服务发现，dubbo 实现应用级服务发现的难点以及dubbo3 是如何解决这些问题这三个部分进行讲解。
开始前，我们先了解下 dubbo 最初提供的接口级服务发现是怎样的。
dubbo 服务的注册发现是以 接口 为最小粒度的，在 dubbo 中将其抽象为一个 URL ，大概长这样：
看着很乱？捋一捋：
无论是存储还是变更推送压力都可能遇到瓶颈，数据多表现在这两个方面：
这个问题好解决： 拆！
dubbo 在 2.7 之后的版本支持了 元数据中心 与 配置中心 ，对于URL的参数进行分类存储。持久不变的（如application、method等）参数存储到元数据中心中，可能在运行时变化（timeout、tag）的存储到配置中心中
无论是增加一台机器还是增加一个接口，其增长都是线性的，这个问题比单条数据大更严重。
当抹去注册信息中的 interface 信息，这样数据量就大大减少
只用过 dubbo 的同学可能觉得这很主流。
但从服务发现的角度来看：
无论是用的最多的服务注册发现系统 DNS ，又或者是 SpringCloud 体系、 K8S 体系，都是以应用为维度进行服务注册发现的，只有和这些体系对齐，才能更好地与之进行打通。
在我了解的范围里，目前只有 dubbo 、 SOFARPC 、 HSF 三个阿里系的 RPC 框架支持了接口级的服务发现。
provider端暴露服务：
consumer端引用服务：
本地调用远程的方法时，只需要配置一个 reference ，然后直接使用 interface 来调用，我们不必去实现这个 interaface，dubbo 自动帮我们生成了一个代理进行 RPC 调用，屏蔽了通信的细节，让我们有种 像调用本地方法一样调用远程方法的感觉 ，这也是 dubbo 的优势。
从这里我们能看出为什么 dubbo 要设计成接口级服务发现，因为要为每一个 interface 生成一个代理，就必须定位到该 interface 对应服务暴露的服务地址，为了方便，dubbo 就这么设计了。
如果让我来设计应用级服务发现，注册不必多说，按应用名注册即可。
至于订阅，在目前 dubbo 机制下，必须得告诉消费者消费的每个接口是属于哪个应用，这样才能定位到接口部署在哪里。
实现 dubbo 应用级服务发现，难点在于
保留接口级服务发现，且默认采取双注册方式，可配置使用哪种服务发现模型，如下配置使用应用级服务发现
名词有点高大上，但道理很简单，让 dubbo 自己去匹配，提供者注册的时候把接口和应用名的映射关系存储起来，消费者消费时根据接口名获取到部署的应用名，再去做服务发现。
数据存储在哪里？显然元数据中心非常合适。该方案用户使用起来和之前接口级没有任何不同，但需要增加一个元数据中心，架构变得复杂。
且有一个问题是，如果接口在多个应用下部署了，dubbo 查找的策略是都去订阅，这可能在某些场景下不太合适。
本文从接口级服务发现讲到应用级服务发现，包含了为什么 dubbo 设计成接口级服务发现，接口级服务发现有什么痛点？基于 dubbo 现状如何设计应用级服务发现，应用级服务发现实现有什么难点等等问题进行解答，相信看完的小伙伴一定有所收获。

dubbo和zookeeper

dubbo 是一个远程调用服务的分布式框架，可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务，使得远程调用的协议可以使用dobbo协议( dubbo://x.x.x.x )或者其它协议，可以配置zookeeper集群地址，实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候，它也是可以实现服务端和调用端的通信的，这种方式是点对点通信的，所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候，就会暴露许多的问题：增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心，来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。
Dubbo实现服务调用是通过RPC的方式，即客户端和服务端共用一个接口(将接口打成一个jar包，在客户端和服务端引入这个jar包)，客户端面向接口写调用，服务端面向接口写实现，中间的网络通信交给框架去实现。
咱们来看下Spring 配置声明暴露服务，provider.xml文件
再来看服务消费者，consumer.xml文件
这就是典型的点对点的服务调用。当然我们为了高可用，可以在consumer.xml中配置多个服务提供者，并配置响应的负载均衡策略。
配置多个服务调用者在comsumer.xml的dubbo:reference标签的url属性中加入多个地址，中间用分号隔开即可；配置负载均衡策略在comsumer.xml的dubbo:reference标签中增加loadbalance属性即可，值可以为如下四种类型：
那么目前的架构有什么问题呢？ 1.当服务提供者增加节点时，需要修改配置文件。 2.当其中一个服务提供者宕机时，服务消费者不能及时感知到，还会往宕机的服务发送请求。
这个时候就需要引入注册中心了，Dubbo目前支持4种注册中心(multicast、zookeeper、redis、simple)推荐使用Zookeeper注册中心，要使用注册中心，只需要将provider.xml和consumer.xml更改为如下：
如果zookeeper是一个集群，则多个地址之间用逗号分隔即可
把consumer.xml中配置的直连的方式去掉
注册信息在zookeeper中如何保存？ 启动上面服务后，我们观察zookeeper的根节点多了一个dubbo节点及其他，图示如下
最后一个节点中服务的地址，为什么把最后一个节点标成绿色？因为最后一个节点是临时节点，而其他节点是持久节点，这样，当服务宕机时，这个节点就会自动消失，不再提供服务，服务消费者也不会再请求。如果部署多个DemoService，则providers下面会有好几个节点，一个节点保存一个DemoService的服务地址。 其实一个zookeeper集群能被多个应用公用，因为不同的框架会在zookeeper上建不同的节点，互不影响。如dubbo会创建一个/dubbo节点，storm会创建一个/storm节点。
zookeeper 介绍： zookeeper是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。
流程说明：
支持以下功能：
补充： dubbo的协议使用什么序列化框架？ dubbo有多种协议，不同的协议默认使用不同的序列化框架。比如dubbo协议默认使用 Hessian2 序列化(说明：Hessian2 是阿里在 Hessian 基础上进行的二次开发，起名为Hessian2)。rmi协议默认为 java 原生序列化，http协议默认为为 json。
dubbo的通信方式？ 采用单一长连接和NIO异步通信，基于Hessian2作为序列化协议。适合于小数据量（每次请求在100kb以内）大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。具体实现是消费者使用 NettyClient，提供者使用 NettyServer，Provider 启动的时候，会开启端口监听，使用我们平时启动 Netty 一样的方式。而 Client 在 Spring getBean 的时候，会创建 Client，调用远程方法的时候，将数据通过DubboCodec编码发送到 NettyServer，然后 NettServer 收到数据后解码，并调用本地方法，并返回数据，完成一次完美的 RPC 调用。
zookeeper选举机制？ zookeeper选举算法默认的是FastLeaderElection，选举机制的概念： 1.服务器ID：比如有三台服务器，编号分别是1、2、3，编号越大在选择算法中的权重越大。 2.事务ID：服务器中存放的最大数据ID(致使ZooKeeper节点状态改变的每一个操作都将更新事务id，即时间戳)，值越大说明数据越新，在选举算法中数据越新权重越大。 3.逻辑时钟，或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。 选举状态：LOOKING：竞选状态；FOLLOWING：随从状态，同步leader状态，参与投票；OBSERVING：观察状态,同步leader状态，不参与投票；LEADING：领导者状态。 初次选举简述： 目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下： 1.服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。 2.服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。 3.服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数为3正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。 4.服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。 5.服务器5启动，后面的逻辑同服务器4成为小弟。 如果中间有节点挂掉，只要有半数以上节点存活，就可以正常服务，如果leader挂掉，则所有节点处于Looking状态 ，各自依次发起投票，投票包含自己的服务器ID和最新事务ID，如果发现别人的事务id比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的事务id所属节点(事务id一样，则数据id大的胜出)。每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。
引用： https://www.cnblogs.com/iisme/p/10620125.html

Dubbo简介及优缺点

Dubbo开始于电商系统，因此在这里先从电商系统的演变讲起。

一款分布式服务框架
高性能和透明化的RPC远程服务调用方案
SOA服务治理方案
每天为2千多个服务提供大于30亿次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点以及别的公司的业务中。

Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次数和调用时间的监控中心。

调用流程

Dubbo注册中心
对于服务提供方，它需要发布服务，而且由于应用系统的复杂性，服务的数量、类型也不断膨胀；
对于服务消费方，它最关心如何获取到它所需要的服务，而面对复杂的应用系统，需要管理大量的服务调用。
而且，对于服务提供方和服务消费方来说，他们还有可能兼具这两种角色，即既需要提供服务，有需要消费服务。
通过将服务统一管理起来，可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。

Dubbo提供的注册中心有如下几种类型可供选择：

优点：

缺点：

Dubbo+zookeeper+spring搭建： https://www.jianshu.com/p/9cbfb8679e1d

Dubbo 协议

Dubbo是 Alibaba 开源的分布式服务框架远程调用框架，在网络间传输数据，就需要通信协议和序列化。
Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议，但是Dubbo官网是推荐我们使用Dubbo协议的，默认也是用的dubbo协议。
先介绍几种常见的协议：
缺省协议，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。 连接个数：单连接 连接方式：长连接 传输协议：TCP 传输方式：NIO异步传输 序列化：Hessian二进制序列化 适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。 适用场景：常规远程服务方法调用
1、dubbo默认采用dubbo协议，dubbo协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况 2、他不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。 配置如下：

3、Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接。

4、为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护

Java标准的远程调用协议。 连接个数：多连接 连接方式：短连接 传输协议：TCP 传输方式：同步传输 序列化：Java标准二进制序列化 适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。 适用场景：常规远程服务方法调用，与原生RMI服务互操作
RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式 。
基于Hessian的远程调用协议。 连接个数：多连接 连接方式：短连接 传输协议：HTTP 传输方式：同步传输 序列化：表单序列化 适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。 适用场景：需同时给应用程序和浏览器JS使用的服务。
1、Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现。 2、Hessian是Caucho开源的一个RPC框架： http://hessian.caucho.com ，其通讯效率高于WebService和Java自带的序列化。
基于http表单的远程调用协议。参见：[HTTP协议使用说明] 连接个数：多连接 连接方式：短连接 传输协议：HTTP 传输方式：同步传输 序列化：表单序列化 适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。 适用场景：需同时给应用程序和浏览器JS使用的服务。
基于WebService的远程调用协议。 连接个数：多连接 连接方式：短连接 传输协议：HTTP 传输方式：同步传输 序列化：SOAP文本序列化 适用场景：系统集成，跨语言调用
序列化是将一个对象变成一个二进制流就是序列化， 反序列化是将二进制流转换成对象 为什么要序列化？
Dubbo序列化支持java、compactedjava、nativejava、fastjson、dubbo、fst、hessian2、kryo，其中默认hessian2。其中java、compactedjava、nativejava属于原生java的序列化。
hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2序列化，而是阿里修改过的，它是dubbo RPC默认启用的序列化方式。 json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。 java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。