远程服务调用的分布式框架，高性能透明化PRC 远程服务调用。SOA服务治理。
特征
1、透明化远程方法调用：像调用本地方法一样调用远程方法，只需简单的配置，没有任何API侵入。
2、软负载均衡和容错机制。
3、服务自动注册于发现，不需要写死服务提供方的地址。
dubbox工作流程
节点角色
provider：暴露服务的服务提供方 Service
Consumer：调用远程服务的服务消费方：controller
Registry：服务注册和发现中心
zookeeper(官方推荐)、redis、广播机制、Simple
Monitor：统计服务的调用次数和调用事件的监控中心。dubbox提供监控中心的war包。
Container：服务运行容器
service：spring容器
controller：SpringMVC容器
调用关系说明：
0. 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者在启动时，向注册中心注册自己提供的服务。
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推
送变更数据给消费者。
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，
如果调用失败，再选另一台调用。
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计
数据到监控中心。
dubbox的工作原理
说明：dubbox底层分为10层，每层作用如下
第一层：service层，接口层，给服务提供者和消费者来实现的
第二层：config层，配置层，主要是对dubbo进行各种配置的
第三层：proxy层，服务代理层，透明生成客户端的stub和服务单的skeleton
第四层：registry层，服务注册层，负责服务的注册与发现
第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
第六层：monitor层，监控层，对rpc接口的调用次数和调用时间进行监控
第七层：protocol层，远程调用层，封装rpc调用
第八层：exchange层，信息交换层，封装请求响应模式，同步转异步
第九层：transport层，网络传输层，抽象mina和netty为统一接口
第十层：serialize层，数据序列化层
dubbox负载均和策略和集群容错策略、动态代理策略
dubbo负载均衡策略：
- random loadbalance：默认情况下，dubbo是random load balance随机调用实现负载均衡，可以对provider不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。
- roundrobin loadbalance：还有roundrobin loadbalance，这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。
- leastactive loadbalance：这个就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求
- consistanthash loadbalance：一致性Hash算法，相同参数的请求一定分发到一个provider上去，provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略。
dubbo动态代理策略：
- 默认使用javassist动态字节码生成，创建代理类但是可以通过spi扩展机制配置自己的动态代理策略
dubbox的服务治理、降级、重试
服务降级：
比如说服务A调用服务B，结果服务B挂掉了，服务A重试几次调用服务B，还是不行，直接降级，走一个备用的逻辑，给用户返回响应。
public interface HelloService { void sayHello(); } public class HelloServiceImpl implements HelloService { public void sayHello() { System.out.println("hello world......"); } }
在provider中配置
<dubbo:reference id="fooService" interface="com.test.service.FooService" timeout="10000" check="false" mock="true">
将mock修改为true，然后在跟接口同一个路径下实现一个Mock类，命名规则是接口名称加Mock后缀。然后在Mock类里实现自己的降级逻辑。
public class HelloServiceMock implements HelloService { public void sayHello() { // 降级逻辑 } }
失败重试和超时重试
失败重试，就是consumer调用provider要是失败了，比如抛异常了，此时应该是可以重试的，或者调用超时了也可以重试。Dubbox默认请求时间是1000ms,请求三次.可以通过timeout设置超时时间，以及设置retries重试次数。
zookeeper注册中心如果挂掉了可以继续通信吗？
可以。因为在刚开始初始化的时候，消费者会将提供者的地址等系拉取到本地缓存中，所以注册中心挂掉了，可以继续通信。
dubbox 如何保证服务的安全？
通过令牌验证在注册中心控制权限，以决定要不要下发令牌给消费者，可以防止消费者绕过注册中心访问提供者，另外通过注册中心可灵活改变授权方式，而不需修改或升级提供者。
https://yq.aliyun.com/articles/284281
大部分的服务都是部署在内网的，基本很少外网开放，但是zookeeper 的用户权限认证好像起不了什么作用。
dubbox 的服务集群
集群的目的：实现高可用，容错功能，集群的服务器不要放在一台物理机上，要分散节点，才能实现高可用，高容错性。如果一台提供者挂了，还有其他的提供者，保证系统正常稳定的运行。
用户服务:pay-service-user
交易服务:pay-service-trade
在 121、122的服务器上同时启动这两个服务。
在DubboxAdmin 管理控制台中可以看待两个机器都注册了服务。
Dubbo服务容错配置--集群容错模式
1、failover cluster
失败自动切换，当出现失败，重试其他服务器（缺省），通常用于读操作，但重试会带来更长的延时，可通过retries=“2”来设置重试次数（不含第一次）
<dubbo:service retries="2"> 或者 <dubbo:reference retries="2"> 或者 <dubbo:reference> <dubbo:method name="findFoo" retries=2> <dubbo:reference/>
2、failfast cluster
快速失效，只发起一次调用，失败立即报错。通常用于非幂等性写操作，比如说新增记录
<dubbo:service cluster="failfast"> 或者 <dubbo:reference cluster="failfast"
3、failsaft cluster
失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作
<dubbo:service cluster="failsafe"> 或者 <dubbo:reference cluster="failsafe">
4、failback cluster
失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作
<dubbo:service cluster="failback"> 或者 <dubbo:reference cluster="failback">
5、forking cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多的服务器资源。可通过forks=“2”来设置最大并行数。
<dubbo:service cluster="forking"> 或者 <dubbo:reference cluster="forking">
