dubbo详解

一、dubbo是什么

dubbo是一个分布式的服务框架，致力于提升性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

简言之，dubbo就是一个服务框架，若是没有分布式的需求，其实不须要用的，只有分布式的时候，才须要dubbo这样的分布式框架

本质里，dubbo就是个服务调用的东东。。

说白了就是个远程服务调用的分布式框架(告别webservice模式中的wsdl，以服务者与消费者的方式在dubbo上注册)

dubbo能够和spring无缝集成

二、dubbo能干什么

1)透明化的远程方法调用，就像调用本地方法同样，只需简单配置，没有任何API侵入

2)软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，下降成本，减小单点

3)服务自动注册与发现，再也不须要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，而且可以平滑添加或删除服务提供者

4)dubbo采用全spring配置方式，透明化接入应用，对应用没有任何API侵入，只需spring加载dubbo的配置便可，dubbo基于spring的schema扩展进行加载

三、dubbo怎么用——即dubbo工做原理

dubbo的核心：

1)远程通信：提供多种基于长链接的NIO框架封装，包括多线程模型，序列号，以及“请求-响应”模式的信息交换方式

2)集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持

3)自动发现：基于注册中心目录服务，使服务消费方可以动态查找服务提供方，使地址透明，使服务提供方能够平滑增长或减小机器

dubbo主要核心部件

Remoting：网络通讯框架，实现了sync-over-async和request-response消息机制。

RPC：一个远程过程调用的抽象，支持负载均衡、容灾和集群功能。

Registry：服务目录框架用于服务的注册和服务事件发布和订阅。

dubbo核心架构图：

角色说明：

provider:服务提供方

consumer:服务消费方

registry:服务注册与发现的注册中心

monitor:统计服务的调用次数和调用时间的监控中心

container:服务运行容器

调用关系说明：

0.服务器负责启动、加载、运行服务提供者

1.服务提供者在启动时，向注册中心注册本身提供的服务

2.服务消费者在启动时，向注册中心订阅本身所需的服务

3.注册中心返回服务提供者地址列表给消费者，若是有变动，注册中心将基于长链接推送变动数据给消费者

4.服务消费者，从提供者列表中，基于软负载均衡算法，选一台提供者进行调用，若是调用失败，更换另外一台调用

5.服务消费者和服务提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

四、dubbo怎么用

dubbo基于spring的schema扩展进行加载

服务提供者：

1)下载zookeeper注册中心

2)定义服务接口(该接口需单独打包，在服务提供方和消费方共享)

3)spring配置声明暴露服务

//具体的实现Bean

<dubbo:application name="x_provider" /> //提供方信息

<dubbo:egister address="multicast://ip" />//multicast广播注册中心，暴露服务地址

<dubbo:register address="zookeeper://ip:2181" />//zookeeper注册中心暴露服务地址

<dubbo:protocol name="dubbo" port="20880" />//用dubbo协议在20880端口暴露服务

<dubbo:service interface="..." ref="demoService"/>//声明需暴露的服务接口

服务消费者：

applicationContext-dubbo.xml:注册本身须要调用的接口(业务多了，按照业务将拆分红N多个applicationContext-dubbo-xxx.xml)

经过spring配置引用远程服务

<dubbo:application name=".._consumer"/>//消费方应用名

<dubbo:register address="zookeeper://ip:2181"/>//使用zookeeper注册中心暴露服务地址

<dubbo:reference id="demoService" interface="..demoService"/>//生成远程服务代理，能够像使用本地bean同样使用demoService

服务保护:

服务保护的原则上是避免发生相似雪崩效应，尽可能将异常控制在服务周围，不要扩散开。

说到雪崩效应，还得提下dubbo自身的重试机制，默认3次，当失败时会进行重试，这样在某个时间点出现性能问题，而后调用方再连续重复调用，很容易引发雪崩，建议的话仍是很据业务状况规划好如何进行异常处理，什么时候进行重试。

服务保护的话，目前咱们主要从如下几个方面来实施，也不成熟，还在摸索：

考虑服务的dubbo线程池类型（fix线程池的话考虑线程池大小）、数据库链接池、dubbo链接数限制是否都合适

考虑服务超时时间和重试的关系，设置合适的值

必定时间内服务异常数较大，则可考虑使用failfast让客户端请求直接返回或者让客户端再也不请求

zkclient问题

前文已经提到过zkclient有两个问题，修改服务器时间会致使容器挂掉；dubbo使用zkclient没有传超时时间致使zookeeper没法链接的时候，直接阻塞Integer.MAX_VALUE。

正在调研curator，目前只能说curator不会在没法链接的时候直接阻塞。

另外zkclient和curator的jar包应该都是jdk1.6编译的，因此系统还在jdk1.5如下的话没法使用。

注册中心的分组group和服务的不一样实现group

这两个东西彻底不一样的概念，使用的时候不要弄混了。

registry上能够配置group，用于区分不一样分组的注册中心，好比在同一个注册中心下，有一部分注册信息是要给开发环境用的，有一部分注册信息时要给测试环境用的，能够分别用不一样的group区分开，目前对这个理解还不透彻，大体就是用于区分不一样环境。

service和reference上也能够配置group，这个用于区分同一个接口的不一样实现，只有在reference上指定与service相同的group才会被发现，还有前文提到的分组合并结果也是用的这个。

五、dubbo的容错方案

当咱们的系统中用到Dubbo的集群环境,由于各类缘由在集群调用失败时，Dubbo提供了多种容错方案，缺省为failover重试。

Dubbo的集群容错在这里想说说他是由于咱们实际的项目中出现了此类的问题,由于依赖的第三方项目出现异常,致使dubbo调用超时,此时使用的是默认的集群容错方式,而配置的reties='3',这样前段系统连续掉用了三次服务,结果可想而知.

先说一下各节点关系：

这里的Invoker是Provider的一个可调用Service的抽象，Invoker封装了Provider地址及Service接口信息。

Directory表明多个Invoker，能够把它当作List，但与List不一样的是，它的值多是动态变化的，好比注册中心推送变动。

Cluster将Directory中的多个Invoker假装成一个Invoker，对上层透明，假装过程包含了容错逻辑，调用失败后，重试另外一个。

Router负责从多个Invoker中按路由规则选出子集，好比读写分离，应用隔离等。

LoadBalance负责从多个Invoker中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，须要重选。

集群容错模式： Failover Cluster

失败自动切换，当出现失败，重试其它服务器。(缺省)

一般用于读操做，但重试会带来更长延迟。

可经过retries="2"来设置重试次数(不含第一次)。正是文章刚开始说的那种状况.

Failfast Cluster

快速失败，只发起一次调用，失败当即报错。

一般用于非幂等性的写操做，好比新增记录。

Failsafe Cluster

失败安全，出现异常时，直接忽略。

一般用于写入审计日志等操做。

Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。

一般用于消息通知操做。

Forking Cluster

并行调用多个服务器，只要一个成功即返回。

一般用于实时性要求较高的读操做，但须要浪费更多服务资源。

可经过forks="2"来设置最大并行数。

Broadcast Cluster

广播调用全部提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)

一般用于通知全部提供者更新缓存或日志等本地资源信息。

重试次数配置如：(failover集群模式生效)

dubbo:serviceretries="2"/

或：dubbo:referenceretries="2"/

或：dubbo:reference

dubbo:methodname="findFoo"retries="2"/

</dubbo:reference>

集群模式配置如： dubbo:servicecluster="failsafe"/

或：dubbo:referencecluster="failsafe"/

六、dubbo负载均衡策略

在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。

RandomLoadBalance

随机，按权重设置随机几率。

在一个截面上碰撞的几率高，但调用量越大分布越均匀，并且按几率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobinLoadBalance

轮循，按公约后的权重设置轮循比率。

存在慢的提供者累积请求问题，好比：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，长此以往，全部请求都卡在调到第二台上。

LeastActiveLoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用先后计数差。

使慢的提供者收到更少请求，由于越慢的提供者的调用先后计数差会越大。

ConsistentHashLoadBalance

一致性Hash，相同参数的请求老是发到同一提供者。

当某一台提供者挂时，本来发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引发剧烈变更。

Dubbo的集群容错和负载均衡一样也是Dubbo自己的高级特性.正如咱们在说自定义扩展的时候同样,这两个特征一样也能够进行自定义扩展,用户能够根据本身实际的需求来扩展他们从而知足项目的实际需求。

七、服务之间如何实现通讯

1)同步调用

REST(JAX-RS，Spring Boot)

RPC(Thrift,Dubbo,HSF)

2)异步消息调用(kafka,Notify,NetaQ)

RESTFUL和RPC比较：

restful基于HTTP，更易实现，服务端技术更灵活，各语言都支持，跨客户端，对客户端无特殊要求，只需封装HTTP的SDK就能调用

RPC:传输协议更高效，安全更可控

特别在一个公司内部，若是有统一的开发规范和统一的服务框架时，开发效率优点更明显

同步：调用问题，性能差(特别是层次多时)

异步：减低调用服务之间的耦合，调用之间的缓冲，确保消息挤压不会冲垮被调用方，同时保证调用方的服务体验，继续干本身该干的活，不至于被后台性能拖慢，付出的代价是一致性的减弱，须要接受数据最终一致性，后台服务通常要实现幂等性，由于消息发送处于性能的考虑通常会有重复；必须引入一个独立的broker。

有兴趣的朋友们能够前往球球：1903832579