为什么要用dubbo（dubbo用的什么协议）

　　推荐学习消息中间件合集：MQ（ActiveMQRabbitMQRocketMQ）Kafka笔记肝了30天，整出这份〔分布式宝典：限流缓存通讯〕，秋招跳槽有望一箭双雕！Alibaba架构师，纯手打CloudBoot微服务架构笔记Dubbo
　　简单的介绍一下Dubbo？（Dubbo是什么）
　　dubbo就是个服务调用的东东。
　　为什么怎么说呢？
　　因为Dubbo是由阿里开源的一个RPC分布式框架
　　那么RPC是什么呢？
　　就是不同的应用部署到不同的服务器上，应用之间想要调用没有办法直接调用，因为不在一个内存空间，需要通过网络通讯来调用，或者传达调用的数据。而且RPC会将远程调用的细节隐藏起来，让调用远程服务像调用本地服务一样简单。
　　dubbo有哪些组件？
　　紫色虚线：在Dubbo启动时完成的功能蓝青色的线：都是程序运行过程中执行的功能，虚线是异步操作，实线是同步操作Provider：提供者，服务发布方。如果是采用SOA开发的模式，这个就是和数据库交互的接口，也就是service主要放在生产者这边Consumer：消费者，调用服务方。面向前端的Controller主要是在这边，可以远程调用生产者中的方法，生产者发生变化时也会实时更新消费者的调用列表。具体的看下面介绍Container：主要负责启动、加载、运行服务提供者。Dubbo容器，依赖于Spring容器。这里比较注意的就是Dubbo是依赖与Spring容器的。所以必须要和Spring配合着使用Registry：注册中心。当Container启动时把所有可以提供的服务列表上Registry中进行注册。作用：告诉Consumer提供了什么服务和服务方在哪里。Monitor：监控中心：监控中心负责统计各服务调用次数、调用时间
　　运行原理？0。Start：启动容器，相当于在启动Dubbo的Provider，并且会创建对应的目录结构，例如代码中的共用接口名为com。learnDubbo。demo。DemoService，就会创建dubbocom。learnDubbo。demo。DemoService目录，然后在创建providers目录，再在providers目录下写入自己的URL地址。1。Register：启动后会去注册中心进行注册，注册所有可以提供的服务列表。即订阅dubbocom。learnDubbo。demo。DemoService目录下的所有提供者和消费者URL地址。2。Subscribe：Consumer在启动时，不仅仅会注册自身到consumers目录下，同时还会订阅providers目录，实时获取其上Provider的URL字符串信息。当服务消费者启动时：会在dubbocom。learnDubbo。demo。DemoService目录创建consumers目录，并在consumers目录写入自己的URL地址。3。notify：当Provider有修改后，注册中心会把消息推送给Consummer。也就是注册中心会对Provider进行观察，这里就是使用设计模式中的观察者模式。以Zookeeper注册中心为例，Dubbo中有ZookeeperRegistry中的doSubscribe方法也就是进行生产者订阅和监听。4、invoke：根据获取到的Provider地址，真实调用Provider中功能。这里就是唯一一个同步的方法，因为消费者要得到生产者传来的数据才能进行下一步操作，但是Dubbo是一个RPC框架，RPC的核心就在于只能知道接口不能知道内部具体实现。所以在Consumer方使用了代理设计模式，创建一个Provider方类的一个代理对象，通过代理对象获取Provider中真实功能，起到保护Provider真实功能的作用。5、Monitor：Consumer和Provider每隔1分钟向Monitor发送统计信息，统计信息包含，访问次数，频率等Dubbo与SpringCould相比它为什么效率要高一些
　　首先看一下Dubbo支持什么协议？dubbo各种协议的性能对比：
　　thrift协议：
　　thrift原生协议性能表现卓越，是dubbo原生性能的6倍
　　dubbo协议：
　　定义：缺省协议、采用了单一长连接和NIO异步通讯、使用线程池并发处理请求，能减少握手和加大并发效率
　　适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。适用场景：常规远程服务方法调用
　　hession协议：定义：用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。适用场景：页面传输，文件传输，或与原生hessian服务互操作。
　　案例测试：
　　可以看出dubbo通信的效率上高于SpringCould，那为什么会高于呢？
　　SpringCloud服务间的通信方式有两种RestTemplate方式Feign的方式
　　不管是什么方式，它都是通过REST接口调用服务的http接口，参数和结果默认都是通过jackson序列化和反序列化。
　　也就是说SpringCould是Http请求。
　　dubbo我们都知道是RPC分布式框架，默认是基于dubbo自定义的二进制协议进行传输，消息体比较简单，传输数据要小很多。
　　案例测试：
　　结论：RPC请求的效率是HTTP请求的1。6倍左右，性能明显比HTTP请求要高很多，因为HTTP协议包含大量的请求头、响应头信息。Zookeeper
　　Zookeeper的实现原理？（工作原理）
　　Zookeeper会维护一个类似于标准的文件系统的具有层次关系的数据结构。这个文件系统中每个子目录项都被称为znode节点，这个znode节点也可以有子节点，每个节点都可以存储数据，客户端也可以对这些node节点进行getChildren，getData，exists方法，同时也可以在znodetree路径上设置watch（类似于监听），当watch路径上发生节点create、delete、update的时候，会通知到client。client可以得到通知后，再获取数据，执行业务逻辑操作。Zookeeper的作用主要是用来维护和监控存储的node节点上这些数据的状态变化，通过监控这些数据状态的变化，从而达到基于数据的集群管理。
　　为什么要用zookeeper作为dubbo的注册中心？能选择其他的吗？
　　Zookeeper的数据模型是由一系列的Znode数据节点组成，和文件系统类似。zookeeper的数据全部存储在内存中，性能高；zookeeper也支持集群，实现了高可用；同时基于zookeeper的特性，也支持事件监听（服务的暴露方发生变化，可以进行推送），所以zookeeper适合作为dubbo的注册中心区使用。redis、Simple也可以作为dubbo的注册中心来使用。
　　项目中主要用zookeeper做了什么？（作用）
　　作为注册中心用；主要是在服务器上搭建zookeeper，其次在spring管理的dubbo的配置文件中配置（暴露方和消费方都需要配置）作者：java小丑
　　原文链接：https：blog。csdn。netjavawxidarticledetails107029848