1 .什么是1.Dubbo？ Dubbo是一个分布式、高性能、透明的RPC服务框架，提供了服务自动注册、自动发现等高效的服务治理解决方案，可以与Spring框架无缝集成。
RPC是远程调用协议，意思是两个服务器交换数据。
2.Dubbo的由来？ 互联网的迅速发展、web APP应用规模的扩大，一般是以下四个发展阶段… 单一应用架构
如果网站流量很小，一个APP应用程序只需要将所有功能放在一起
垂直应用架构
随着访问次数的逐渐增加，将一个APP应用程序按业务线划分为多个APP应用程序，从而提高效率。
此时，用于加速前页开发的Web框架(MVC )是关键。
分布式服务架构
随着垂直的APP应用越来越多，APP应用之间的交互不可避免，提取核心业务，作为独立的服务，逐渐形成稳定的服务中心，使前端APP应用能够更快地适应变化的市场需求。
此时，用于提高业务复用和整合的分布式服务框架(RPC)很重要。
流动计算架构
随着服务增加，容量评估、小服务资源浪费等问题日益突出，需要增加基于访问压力实时管理集群容量的调度中心，提高集群利用率。
此时，用于提高设备利用率的资源调度和管理中心(SOA )很重要。
3.Dubbo的主要应用场景？ 透明的远程方法调用与调用本地方法一样，只需调用和轻松配置远程方法，而没有API入侵。 通过软负载平衡和容错机制，可以在内部网上使用它来代替F5等硬件负载分散机，从而降低成本，减少单点。服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。4.Dubbo的核心功能？ 主要是以下三个核心功能。
Remoting：网络通信框架
Cluster：服务框架
Registry：服务注册基于注册中心的目录服务，服务消费者动态搜索服务提供者，并透明地址，以允许服务提供者顺利地增加或减少机器。
5.Dubbo核心组件？
6.Dubbo服务注册和发现的过程？
7.Dubbo的体系结构设计？Dubbo框架设计一共划分了10个层：
服务接口层（Service）:该层涉及实际业务逻辑，根据服务提供方和服务消费方的业务设计对应的接口和实现。 33558 www.Sina.com/:以服务配置和参考配置为中心的对外部署接口。配置层（Config）()服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton。服务代理层（Proxy:封装服务地址注册和发现，以服务URL为中心。服务注册层（Registry）:封装多个提供程序的路由和负载平衡，围绕Invoker桥接注册中心。 http://www.Sina.com/:监视RPC调用次数和调用时间。 33558 www.Sina.com/:封装RPC呼叫，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。集群层（Cluster）:封装请求响应模式，异步传输，以请求和响应为中心。监控层（Monitor）:抽象mina和netty是统一接口，以消息为中心。
8.Dubbo的服务呼叫流程？
9.Dubbo支持哪些协议？ 各协议的应用场景、优缺点是？远程调用层（Protocol）:单一长连接和NIO异步通信，大容量、小容量的服务呼叫和消费者远远大于提供商。 传输协议TCP、异步、Hessian串行化； 3358 www.Sina.com/:采用JDK标准的rmi协议实现，传输参数和返回参数对象需要实现串行化接口，使用java标准串行化机制，进行分块支持多短连接、TCP协议传输、同步传输、常规远程服务呼叫和rmi互操作。 依赖于低版本公共收集包的java序列化存在安全漏洞； web服务：基于WebSer
vice的远程调用协议，集成CXF实现，提供和原生WebService的互操作。多个短连接，基于HTTP传输，同步传输，适用系统集成和跨语言调用；http： 基于Http表单提交的远程调用协议，使用Spring的HttpInvoke实现。多个短连接，传输协议HTTP，传入参数大小混合，提供者个数多于消费者，需要给应用程序和浏览器JS调用；hessian： 集成Hessian服务，基于HTTP通讯，采用Servlet暴露服务，Dubbo内嵌Jetty作为服务器时默认实现，提供与Hession服务互操作。多个短连接，同步HTTP传输，Hessian序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文件；memcache： 基于memcached实现的RPC协议redis： 基于redis实现的RPC协议 10.dubbo推荐用什么协议？默认使用dubbo协议
11.Dubbo有些哪些注册中心？ Multicast注册中心： Multicast注册中心不需要任何中心节点，只要广播地址，就能进行服务注册和发现。基于网络中组播传输实现；Zookeeper注册中心： 基于分布式协调系统Zookeeper实现，采用Zookeeper的watch机制实现数据变更；redis注册中心： 基于redis实现，采用key/Map存储，住key存储服务名和类型，Map中key存储服务URL，value服务过期时间。基于redis的发布/订阅模式通知数据变更；Simple注册中心 Zookeeper有哪几种节点类型?持久：创建之后一直存在，除非有删除操作，创建节点的客户端会话失效也不影响此节点。
持久顺序：持久节点名后缀加上一个10位数字。
临时：创建客户端会话失效（注意是会话失效，不是连接断了），节点也就没了。不能建子节点。
临时顺序：临时节点名后缀加上一个10位数字。
不是。官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。
为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，这太消耗性能了。
一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。
在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。
可以的，启动dubbo时，消费者会从zookeeper拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用。
14.Dubbo与Spring的关系？Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。
15.Dubbo使用的是什么通信框架?默认使用NIO Netty框架
16.Dubbo集群提供了哪些负载均衡策略？ Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀；RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题；LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求；ConstantHash LoadBalance: 一致性Hash策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动；缺省时为Random随机调用 17.Dubbo的集群容错方案有哪些？
Failover Cluster
失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。
Failfast Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
Failsafe Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
Forking Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=”2″ 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。
18.Dubbo的默认集群容错方案？Failover Cluster
19.Dubbo支持哪些序列化方式？默认使用Hessian序列化，还有Duddo、FastJson、Java自带序列化。
20.Dubbo超时时间怎样设置？Dubbo超时时间设置有两种方式：
服务提供者端设置超时时间，在Dubbo的用户文档中，推荐如果能在服务端多配置就尽量多配置，因为服务提供者比消费者更清楚自己提供的服务特性。服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端为主，即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时，服务端线程不会定制，会产生警告。 21.服务调用超时问题怎么解决？dubbo在调用服务不成功时，默认是会重试两次的。
22.Dubbo在安全机制方面是如何解决？Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。
23.dubbo 和 dubbox 之间的区别？dubbox 基于 dubbo 上做了一些扩展，如加了服务可 restful 调用，更新了开源组件等。
24.除了Dubbo还有哪些分布式框架？大家熟知的就是Spring cloud，当然国外也有类似的多个框架。
25.Dubbo和Spring Cloud的关系？Dubbo是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。
26.dubbo和spring cloud的区别？最大的区别：Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。而SpringCloud是基于Http协议+Rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。