协议：

        Dubbo是一种分布式服务框架也是一种协议，dubbo框架默认使用dubbo协议。dubbo协议是阿里巴巴自己实现的一种应用层协议，传输层还是TCP。所以Dubbo协议与HTTP、FTP，SMTP这些应用层协议是并列的概念。除了默认的Dubbo协议，Dubbo框架还支持RMI、Hessian、HTTP等协议。

• RPC面向过程，只发送 GET 和 POST 请求。GET用来查询信息，其他情况下一律用POST。请求参数是动词，直接描述动作本身。
• RESTful面向资源，使用 POST、DELETE、PUT、GET 请求，分别对应增、删、改、查操作。请求参数是名词，这个名词就是“增删改查”想要操作的对象。

为什么是高性能的呢？

1、可以在某个服务器集群中提供单一专注的服务，这样不与其他服务混杂，同时dubbo接口有SOA调度通过监控每台服务器而实现负载均衡。
consumer端无需关注provider端如何实现，只需在注册中心订阅即可到相应服务器请求服务，这样就实现了高性能和透明化。
说到底，Dubbo接口就是一个分布式服务框架。

2、协议不同：

        报文格式不同：

                 http协议报文包括请求头，请求首行，请求体。传输数据量大，占用大。http通信需要三次握手。消耗资源。

                dubbo协议报文短小，包括调用的接口权限定名称，参数列表参数值即可。不需要三次握手。消费端和服务提供端建立单一长连接的方式，且dubbo的报文传输数据小，所以支持高并发。通信采用NIO异步通信的方式。

        建立连接不通：

                dubbo协议，消费者和服务者建立单一的长连接，减少了建立连接的资源消耗。

                http协议，消费者和服务者建立多连接，并且需要三次握手，消耗资源。

        通信方式不通：

                dubbo协议采用NIO通信模式。

                http协议采用同步传输。

        序列化数据不同：

                dubbo采用Hessian作为序列化协议，采用PB数据存储格式（Protocol Buffer），采用proto编译器，自动进行序列化和反序列化，数据压缩体积更小，单一长连接中传输更加方便。（Protocol Buffer 其实是 Google 出品的一种轻量并且高效的结构化数据存储格式，性能比 JSON、XML 要高很多。）

                http采用JSON

不同点：

        1、SpringCloud基于Http调用的方式，更加灵活，但是消息封装臃肿(可以使用gzip压缩)；Dubbo基于RPC调用的方式，使服务就像可以调用自己本地的服务一样调用别人的服务。
        2、Dubbo在传输前需要将数据进行序列化，同时接收返回数据结果也需要以统一的序列化方式反序列化；而SpringCloud需要封装请求头和请求体，通过Http向服务发起请求，在经过服务的处理之后封装响应头和响应体返回相应信息
        3、SpringCloud可以跨语言，基于Http请求。
 

Dubbo的节点角色：运行原理

运行原理
（1）启动容器，相当于在启动Dubbo的Provider
（2）启动后回曲注册中心进行注册，注册所有可以提供的服务列表
（3）在Consumer启动后会去Registry中获取服务列表和Provider的地址，进行订阅
（4）当Provider有修改后，注册中心会把消息推送给Consummer，使用了观察者设计模
式
（5）根据获取到的Provider地址，真实调用Provider中的功能，在consummer方使用了代理设计模式，创建了一个Provider方类的一个代理对象。通过代理对象获取Provider中的真实功能，起到保护Provider真实功能的作用。
（6）Consumer和Provider每隔一分钟会向Monitor发送统计信息，统计信息包括访问次数，频率等。
 

总结：

        Dubbo服务容器Container启动之后，将服务提供者Provider对外暴露的服务注册进注册中心Register，一般使用ZK作为注册中心，同时本地存储对外暴露服务和实现类的映射关系。服务消费者Consumer向注册中心订阅自己需要消费的服务，同时Consumer和Register基于长连接保持通讯，采用观察者模式进行监听服务提供者的变化，如果服务提供者发生改变，注册中心会通知服务消费者。服务提供者和服务消费者都与Dubbo的监控中心建立连接，监控中心用户监控服务调用情况，调用频率等。

        服务调用过程：

首先对引用服务生成代理对象，通过ZK获取到服务提供者列表，通过Selector选择一个服务(负载均衡)Invoker。

Dubbo的特点：

        1.面向接口的代理模式高性能RPC调用。

        2.智能的服务客户端负载均衡。

        3.服务的自动注册与发现。

        4.服务的限流。

        5.高扩展性。支持很多种协议，支持很多种序列化方式。因为序列化和反序列化协议要统一。

        6.可视化的服务治理。 

解决高并发的三把利器：降级、限流、缓存。

Dubbo的服务降级：针对的是服务的消费者

        比如A服务对外提供了一个访问请求，A服务中调用了B服务，B服务是一个远程服务，当A服务调用量很大是，此时如果B服务不重要，那么A调用B服务，A作为服务的消费方，可以对调用的B服务进行服务的降级处理。那么就是服务消费者A进行对服务提供者B的降级处理。

        分为两种：屏蔽和容错：

        屏蔽：不发起远程服务的调用，直接返回null对象。

        容错：会发起远程服务调用，如果调用失败或者超时不会抛出异常，而是null。

集群容错：

        服务提供者有多个集群，单点故障之后，Dubbo消费者正常调用：默认是，失败自动切换节点重试。

Dubbo的默认限流机制：

        Dubbo默认使用令牌桶算法实现限流。某段时间内，桶里面只能放进n个令牌，然后来一个请求就减少一个令牌，如果桶里面的令牌没有了，则不能继续执行请求。

限流通过com.alibaba.dubbo.rpc.filter.TpsLimitFilter实现。

public boolean isAllowable() {// 获取现在的时间long now = System.currentTimeMillis();// 当经过了interval时间间隔if (now > lastResetTime + interval) {// 重新设置token令牌的个数token.set(rate);// 从现在开始，经过interval的时间lastResetTime = now;}// 获取令牌的值int value = token.get();boolean flag = false;// 使用CAS实现乐观锁while (value > 0 && !flag) {// 能够执行请求，则令牌减一flag = token.compareAndSet(value, value - 1);value = token.get();}return flag;
}

限流采用令牌桶算法来实现，假如桶里有10个令牌，来一个请求，就减少一次，限流涉及到两个参数，一个是限流的间隔时间，一个是这个时间内有多少个请求。如果间隔时间过了，就需要重新刷新桶中的令牌数量。多线程并发访问，这个桶的减少使用的是CAS操作。