dubbo负载均衡策略，dubbo路由规则配置

dubbo与nginx都可以做负载均衡,哪个相对来说更优秀为什么

dubbo的负载均衡已经是服务层面的了，和nginx的负载均衡还在http请求层面完全不同。至于二者哪个优秀，当然没办法直接比较，要硬要选一个的话就是nginx了。 111涉及到负载均衡就涉及到你的业务，根据业务来选择才是最适合的。

拓展：

1、Nginx(“engine x”)是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。 Nginx是由 Igor Sysoev为俄罗斯访问量第二的 Rambler.ru站点开发的，第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。2011年6月1日，nginx 1.0.4发布。

2、Nginx是一款轻量级的Web服务器/反向代理服务器及*(IMAP/POP3)代理服务器，并在一个BSD-like协议下发行。由俄罗斯的程序设计师Igor Sysoev所开发，供俄国大型的入口网站及搜索引擎Rambler(俄文:Рамблер)使用。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，*大陆使用nginx网站用户有:百度、新浪、网易、腾讯、淘宝等。

dubbo和zookeeper

dubbo是一个远程调用服务的分布式框架，可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务，使得远程调用的协议可以使用dobbo协议( dubbo://x.x.x.x)或者其它协议，可以配置zookeeper集群地址，实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候，它也是可以实现服务端和调用端的通信的，这种方式是点对点通信的，所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候，就会暴露许多的问题：增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心，来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。

Dubbo实现服务调用是通过RPC的方式，即客户端和服务端共用一个接口(将接口打成一个jar包，在客户端和服务端引入这个jar包)，客户端面向接口写调用，服务端面向接口写实现，中间的网络通信交给框架去实现。

咱们来看下Spring配置声明暴露服务，provider.xml文件

再来看服务消费者，consumer.xml文件

这就是典型的点对点的服务调用。当然我们为了高可用，可以在consumer.xml中配置多个服务提供者，并配置响应的负载均衡策略。

配置多个服务调用者在comsumer.xml的dubbo:reference标签的url属性中加入多个地址，中间用分号隔开即可；配置负载均衡策略在comsumer.xml的dubbo:reference标签中增加loadbalance属性即可，值可以为如下四种类型：

那么目前的架构有什么问题呢？

1.当服务提供者增加节点时，需要修改配置文件。

2.当其中一个服务提供者宕机时，服务消费者不能及时感知到，还会往宕机的服务发送请求。

这个时候就需要引入注册中心了，Dubbo目前支持4种注册中心(multicast、zookeeper、redis、simple)推荐使用Zookeeper注册中心，要使用注册中心，只需要将provider.xml和consumer.xml更改为如下：

如果zookeeper是一个集群，则多个地址之间用逗号分隔即可

把consumer.xml中配置的直连的方式去掉

注册信息在zookeeper中如何保存？

启动上面服务后，我们观察zookeeper的根节点多了一个dubbo节点及其他，图示如下

最后一个节点中服务的地址，为什么把最后一个节点标成绿色？因为最后一个节点是临时节点，而其他节点是持久节点，这样，当服务宕机时，这个节点就会自动消失，不再提供服务，服务消费者也不会再请求。如果部署多个DemoService，则providers下面会有好几个节点，一个节点保存一个DemoService的服务地址。

其实一个zookeeper集群能被多个应用公用，因为不同的框架会在zookeeper上建不同的节点，互不影响。如dubbo会创建一个/dubbo节点，storm会创建一个/storm节点。

zookeeper介绍：

zookeeper是 Apacahe Hadoop的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。

流程说明：

支持以下功能：

补充：

dubbo的协议使用什么序列化框架？

dubbo有多种协议，不同的协议默认使用不同的序列化框架。比如dubbo协议默认使用 Hessian2序列化(说明：Hessian2是阿里在 Hessian基础上进行的二次开发，起名为Hessian2)。rmi协议默认为 j*a原生序列化，http协议默认为为 json。

dubbo的通信方式？

采用单一长连接和NIO异步通信，基于Hessian2作为序列化协议。适合于小数据量（每次请求在100kb以内）大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。具体实现是消费者使用 NettyClient，提供者使用 NettyServer，Provider启动的时候，会开启端口监听，使用我们平时启动 Netty一样的方式。而 Client在 Spring getBean的时候，会创建 Client，调用远程方法的时候，将数据通过DubboCodec编码发送到 NettyServer，然后 NettServer收到数据后解码，并调用本地方法，并返回数据，完成一次完美的 RPC调用。

zookeeper选举机制？

zookeeper选举算法默认的是FastLeaderElection，选举机制的概念：

1.服务器ID：比如有三台服务器，编号分别是1、2、3，编号越大在选择算法中的权重越大。

2.事务ID：服务器中存放的最大数据ID(致使ZooKeeper节点状态改变的每一个*作都将更新事务id，即时间戳)，值越大说明数据越新，在选举算法中数据越新权重越大。

3.逻辑时钟，或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。

选举状态：LOOKING：竞选状态；FOLLOWING：随从状态，同步leader状态，参与投票；OBSERVING：观察状态,同步leader状态，不参与投票；LEADING：领导者状态。

初次选举简述：

目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：

1.服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。

2.服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。

3.服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数为3正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。

4.服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。

5.服务器5启动，后面的逻辑同服务器4成为小弟。

如果中间有节点挂掉，只要有半数以上节点存活，就可以正常服务，如果leader挂掉，则所有节点处于Looking状态，各自依次发起投票，投票包含自己的服务器ID和最新事务ID，如果发现别人的事务id比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的事务id所属节点(事务id一样，则数据id大的胜出)。每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。

引用：

Dubbo负载均衡

在分布式集群架构下，负载均衡很重要。集群本来就是为了分担压力，负载均衡做的不好，就会失去了集群的意义。

1.按照权重随机分配

按照权重随机分配，即是不均等随机*。比如一块不均匀的硬币，字面30%概率，花面70%概率。这种就是不均等的随机*。

从数学上看，即是一个区间0-10，然后均等随机产生0-10的随机数。然后在这个区间上划分，0-3，3-6,6-10.分别把这个三个区间看做三个随机*，那么这个三个随机*的概率即是30%，30%，40%。

列子：

权重分别为[2,4,8]，权重和为14，那么前面三个权重为2,4,8的三个*就对应[0,2,6,14]这个三个区间。比如6-14表示权重为8的随机*的概率为8/14。所以当产生一个随机数时，通过遍历权重数组，减等，当小于0时，他就落在那个权重*上。比如：随机数5落在2-6之间，2-6对应的是权重为4这个*，所以他属于权重为4的这个随机*。

2.轮询

当多线程出现时，使用原子类的整数去取莫轮询节点。

注意：sequences是成员变量，每次调用函数所有的权重都回归最初。

3.Hash方式

使用某种hash算法，同一请求总是会hash到同一台机子上。

传统的hash算法，存在当hash区间变化时，同样的值hash后的位置不一样了。而一致性hash算法把请求，节点都hash后，放到一个圆环上，按照顺时针转动到的第一个节点为结果。这样就减少了结果的变化。还可以通过增加虚拟节点的方式均衡hash后的概率问题，当然增加节点需要交叉增加。

1.怎么保证服务器少的情况下，hash的结果变化不大。

把消费者，提供者都去hash,hash的结果映射到一个环上。然后，要判断的那个消费者访问那个提供者的时候，进行顺时针的转动。遇到的第一个提供者节点就是。

2.怎么保证概率的问题

交叉的防止虚拟节点，只要节点够多，那就近似是想等的。

详见：一致性hash详解释

4.最少访问原则

如果有多台机子的最少活跃数相同，在这几个中使用第一种按权重随机的方式

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

使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

比如:同样是进行了10个请求，在一分钟内，A只处理了两个，B处理了5个。那么A的机会就更少，那么就会保证的系统整体的速度。

dubbo之Cluster(容错)

在介绍dubbo的cluster之前，先来看一下cluster在dubbo整体设计中的位置。按照*的说法，Cluster作为路由层，封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker为中心，核心扩展接口为 Cluster, Directory, Router, LoadBalance,接口间的依赖关系如下：

虚拟Invoker暴露流程程： Cluster=>(Directory=> Router)=> LoadBalance=> Invoker,依照这个顺序，我们先来看Cluster。Cluster不属于核心层，目的是将多个 Invoker伪装成一个 Invoker，这样其它人只要关注 Protocol层 Invoker即可，加上 Cluster或者去掉 Cluster对其它层都不会造成影响，因为只有一个提供者时，是不需要 Cluster的。本文主要关注Cluster层的容错及其核心接口（LoadBalance在之前的文章已经做过介绍）。

先来看Cluster层中的Cluster接口，支持SPI扩展、自适应扩展，默认SPI实现是FailOverCluster，核心只有一个join接口

比较好理解，把Directory中的所有原始Invoker合并成一个虚拟Invoker，虚拟Invoker是一系列通过合并原始Invoker，并在此基础上扩展带有容错机制的Invoker。以FailOverCluster为例，join返回FailoverClusterInvoker，具体的invoke逻辑由虚拟Invoker（ FailoverClusterInboker）实现,构造方法（这里以FailoverClsterInvoker为例，其他虚拟Invoker的构造方法大同小异）通过继承父类AbstractClusterInvoker实现，只有一个Directory参数：

当前dubbo版本提供的虚拟Invoker主要有下面几种，下面来分别介绍：

所有8种cluster中，除去AvailableCluster、MergeableCluster、BroadcastCluster，其他都需要根据LoadBalance选取可用Invoker，具体逻辑在AbstractClusterInvoker.select。先来看AbstractClusterInvoker的构造方法:

两个核心参数，Directory和URL，Directory本节先不做介绍，这里的URL是被调用服务的URL；*ailableCheck为了与服务的*ailableCheck做区分，这里的参数名是 cluster.*ailablecheck；核心关注上面提到的select方法，先来看逻辑：

整体select方法都是为了尽可能保证每次选出的Invoker不重复，也就是说最大限度的保证负载均衡；doSelect方法在处理的时候，通过loadBalance选出的Invoker，还会对其进一步判断是否已被选中过，步骤如下：

doSelect方法中的loadbalance.select已经在LoadBalance部分做了分析，这里不再冗述，重点关注reSelect方法；先把备选Invoker中，未被选中过的Invoker过滤出来，优先从中选取可用Invoker，步骤如下：

Cluster层的容错主要通过几种常用的容错机制配合负载均衡，保证最终通过Cluster暴露可用的Invoker；而且，dubbo在保证Invoker可用性前提下，要求尽可能均衡负载，过程会多次执行负载均衡策略。

注：dubbo源码版本2.7.1，欢迎指正。