dubbo怎么用？dubbo现在还用吗

dubbo为什么要使用zookeeper作为注册中心

意思就是zk是一个第三方的注册中心,消费者和提供者都通过第三方调度的,消费者不用care是谁提供的服务,只负责调用就好了

微服务框架spring cloud和dubbo有什么区别

首先，从严格意义上来说，Dubbo和SpringCloud的定位是不一样的。Dubbo是一个高性能的、基于java的开源RPC框架，注意它的定位是是高性能和RPC框架。SpringCloud提供了一系列通用工具来帮助开发者在分布式系统里快速构建一些常见模式，比如分布式配置管理、服务发现、熔断降级、智能路由、微代理、控制总线、一次性令牌、全局锁、分布式选主、分布式session等一些列解决方案，它的设计目标是提供一整套服务治理能力，它具有一套完整的微服务解决方案体系。

dubbo只是一个分布式的RPC框架，如果一定要按照分布式系统架构里的功能来定义的话，只是解决了服务发现、服务路由、服务降级和负载均衡方面的能力，新版本里也提供了动态配置中心和服务治理相关的能力，但相比SpringCloud而言，还是差了相当一部分的能力。

从功能支持上来说，dubbo的角色定位可能更像是另外一个大名鼎鼎的框架，那就是gRPC，而且两者在使用的方式以及工作原理上都非常相似，都是基于序列化协议来解决分布式系统中的远程调用问题，在使用上可以通过约定接口或者通过proto文件生成代码文件来“提升用户的使用”。

如果你在系统设计之初就已经考虑到了后续可能会涉及到各种服务治理能力，比如分布式配置、全局锁、分布式session等常见需求，那么使用SpringCloud将会减少你很多的工作，因为这些基本上都是"套件"，相互配合使用会非常顺畅。如果你想要的只是解决分布式架构后的远程调用问题，那么Dubbo是一个不错的选择。

SpringCloud和Dubbo的基本差异大概就是如上所述，如果你不知道该如何做选择，这里再补充几个比较关键的差异点，希望能帮助你更好的结合自身业务做出选择：

能力支持方面

上文也提到，SpringCloud提供了一整套微服务治理的功能组件，很多组件基本上都是"开箱即用"的，并且相互之间能很好的兼容，举个例子，如果要在SpringCloud里实现服务发现、负载均衡和熔断降级，你只需要引用SpringCloud的依赖组件即可，直接通过注解便可使用，基本上零配置；而dubbo框架，除了上述提到的能力支持之外，如果想要使用熔断降级，那你可能需要额外引用hystrix或者resilience4j来实现；温馨提示，hystrix官方目前也已经宣布不再更新，并且推荐使用resilience4j。

协议兼容方面

SpringCloud里并没有限制服务之间的通信协议，但是主流的一些客户端比如restTemple、feign等都是直接支持使用Ribbon来做服务注册发现和智能路由的，其底层通信的协议都是HTTP；而dubbo框架缺省是基于NIO异步传输使用TCP长连接并采用Hessian二进制序列化方式通信的；

这会涉及后续系统在扩展上的兼容性问题，比如需要调用一个三方系统或者是被第三方系统调用，相比而言HTTP协议可能更加通用。

模型定义方面

dubbo在模型设计上将一个接口定义为一个服务，而SpringCloud里则是将一个应用定义为一个服务，这两者在模型上是存在很大差异的，你也许会奇怪，这个对使用会有影响吗？从现有使用方面来说是没有什么影响的，但是你如果有关注ServiceMesh最新微服务技术的话，目前对Dubbo协议这块可能支持暂时还不完善，其中很大一部分原因就是因为在服务模型上与K8S的服务模型有差异；

调用性能方面

如果分布式系统中比较关注远程调用的性能，那Dubbo可能是一个较好的选择，基于NIO和TCP长连接的通信传输方式，在性能上相比HTTP协议是有绝对优势的；当然基于SpringCloud你也可以使用gRPC协议来解决性能问题，那就是另外一个问题了。

dubbo 接口配置

一、dubbo配置之间的关系：

左边是服务提供方的相关配置，右边是服务消费方的相关配置。中间是两方的共享配置。下边是方法和方法参数的相关配置。

ReferenceConfig继承ConsumerConfig，ServiceConfig继承ProviderConfig。如果没有进行Reference和Service的配置，默认是Consumer和Provider的配置。

二、配置覆盖关系：

1、方法级优先，接口级次之，全局配置再次之。（级别小的优先）

2、如果级别一样，则消费方优先，提供方次之。

其中，服务提供方配置，通过URL经由注册中心传递给消费方。

(配置的查找顺序，其他retries，loadbalance,actives等类似)

三、标签：

四、举例

1、项目中的配置

dubbo.xml的配置如下：

<!--应用信息，用于计算依赖关系-->

<dubbo:applicationname="basicInfoservice"/>

<!--使用zookeeper注册中心暴露服务地址-->

<dubbo:registryprotocol="zookeeper"address="${dubbo.registry.address}"register="${dubbo.registry.register}"/>

<!--使用dubbo协议，basicInfoservice应用的端口为20881-->

<dubbo:protocolname="dubbo"port="20881"/>

<!--提供方的超时时间为3s-->

<dubbo:providertimeout="3000"/>

<!--消费方的超时时间为3s-->

<dubbo:consumercheck="false"timeout="3000"/>

<!--需要引用的服务-->

<dubbo:referenceid="dictionaryFacade"interface="com.dmsdbj.itoo.singleTableMaintain.facade.DictionaryFacade"/>

<!--需要暴露的服务-->

<dubbo:serviceid="studentFacade"interface="com.dmsdbj.itoo.basicInfo.facade.StudentFacade"/>

<!--studentFacade服务的超时时间为30s，addStudent方法的超时时间为60s-->

<dubbo:serviceid="studentFacade"interface="com.dmsdbj.itoo.basicInfo.facade.StudentFacade"timeout="30000"

loadbalance="roundrobin">

<dubbo:methodname="addStudent"timeout="60000"/>

</dubbo:service>

dubbo-server.properties配置如下：

dubbo.registry.address=zookeeper://192.168.22.156:2181?backup=192.168.22.154:2181,192.168.22.156:2182

dubbo.basicInfo.group=basicInfo

dubbo.basicInfo.version=1.0.0

dubbo.registry.register=false

上述实例，我们的全局的超时时间为3s,负载均衡策略为随机，student服务的超时时间为30s，负载均衡策略为轮询。addStudent的超时时间为60s。

2、

<dubbo:annotationpackage="com.dmsdbj.itoo.basicInfo.facade"/>

这段配置的作用是开启注解扫描。

开启注解之后，就可以使用@Reference和@Service来订阅服务或者暴露服务啦。需要注意的是@Service并不是Spring的注解，而是

dubbo的注解importcom.alibaba.dubbo.config.annotation.Service;

也可以说<dubbo:reference>标签+@Autowired等价于<dubbo:annotationpackage="">+@Reference。

dubbo为什么使用hessian序列号

dubbo默认协议：

单一TCP长连接，Hessian二进制序列化和NIO异步通讯

适合于小数据包大并发的服务调用和服务消费者数远大于服务提供者数的情况

不适合传送大数据包的服务

hessian协议：

底层Http通讯，Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现

可与原生Hessian服务互操作

通讯效率高于WebService和Java自带的序列化

参数及返回值需实现Serializable接口，自定义实现List、Map、Number、Date、Calendar等接口

适用于传输数据包较大，提供者比消费者个数多，提供者压力较大。

dubbo协议

Dubbo框架定义了私有的RPC协议，它优点：

○协议设计上很紧凑，能用1个bit表示的，不会用一个byte来表示，比如boolean类型的标识。

○请求、响应的header一致，通过序列化器对content组装特定的内容，代码实现起来简单。

但是Dubbo协议没有预留扩展字段，没法新增标识，扩展性不太好，比如新增响应上下文的功能，只有改协议版本号的方式，但是这样要求客户端和服务端的版本都进行升级，对于分布式场景很不友好。

一台服务器需要用dubbo吗

Dubbo是一个分布式服务框架，如果是一个小的erp系统，一台服务器足够支撑项目运行，项目就不会用Dubbo。

如果是一个大的商城项目，用户访问量比较大，一台无法器根本无法支撑运行时，我们可以把订单模块，支付模块，静态页面等独立出来，放置在同一个局域网，不同服务器运行，这时我们就需要使用Dubbo