服务提供者在启动的时候，向zk上的/dubbo/${serviceName}/providers目录下写下自己的URL地址

dubbo会先调用checkAndUpdateSubConfigs方法检查配置是否合理，如果合理再调用doExportUrlsFor1Protocol方法通过配置组装URL，然后调用doExportUrl方法进行服务暴露
注：注册中心

客户端会先检查配置是否合理，然后创建RegisterDirectory实例，生成服务消费者链接向注册中心注册，然后订阅providers，configurators，routers节点下的数据
由于一个服务可能部署在多台服务器上，这样就会在 providers 产生多个节点，这个时候就需要 Cluster 将多个服务节点合并为一个，并生成一个 Invoker。
Zookeeper：

分布式协调和通知：不同的客户端都对Zookeeper上的同一个数据节点进行Watcher注册，监听数据节点的变化。若数据节点发生变化，那么所有订阅的客户端都能够接收到相应的Watcher通知，并作出相应处理。
2)集群管理：

a.客户端如果对Zookeeper的数据节点注册Watcher监听，那么当该数据及诶单内容或是其子节点列表发生变更时，Zookeeper服务器就会向订阅的客户端发送变更通知。b. 对在Zookeeper上创建的临时节点，一旦客户端与服务器之间的会话失效，那么临时节点也会被自动删除。

3）负载均衡：com.alibaba.dubbo.rpc.cluster.LoadBalance类

Random LoadBalance(默认使用)

随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
看方法的细节就是首先遍历每个提供服务的机器，获取每个服务的权重，然后累加权重值，判断每个服务的提供者权重是否相同，如果每个调用者的权重不相同，并且每个权重大于0，那么就会根据权重的总值生成一个随机数，再用这个随机数，根据调用者的数量每次减去调用者的权重，直到计算出当前的服务提供者随机数小于0，就选择那个提供者！另外，如果每个机器的权重的都相同，那么权重就不会参与计算，直接选择随机算法生成的某一个选择，完全随机。可以看出，随机调用法，
RoundRobin LoadBalance

轮询，按公约后的权重设置轮询比率。
存在慢的提供者类即请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
轮询调用，轮询调用的过程主要是维护了局部变量的一个LinkdesHashMap（有顺序的Map）去存储调用者和权重值的对应关系，然后遍历每个调用者,把调用者和当前大于0的权重值放进去，再累加权重值。还有一个全局变量的map，找到第一个服务调用者，首先是找到每个服务的key值和method，这里可以理解为标识第一个调用者的唯一key，然后再给它对应的值保证原子性的+1（AtomicPositiveInteger是原子的），再对这个值取模总权重，再每次对其权重值-1，知道它取模与总权重值等于0就选择该调用者，可以称之为"降权取模"（只是一种的计算层面,而不是真正降权）。总结：轮询调用并不是简单的一个接着一个依次调用，它是根据权重的值进行循环的。
LeastActive LoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
最少活跃数调用法：这个方法的主要作用根据服务的提供者的运行状态去选择服务器,主要的思路就是遍历每个调用者，然后获取每个服务器的运行状态，如果当前运行的运行状态小于最小的状态-1，把它保存在leastIndexs中的第一个位置，并且认定所有的调用者权重都相同，然后直接返回那个调用者(这里的逻辑是：找到最少活跃数(在代码层反应就是：active的值))。如果计算出的权重值和最少的权重值相同，那么把它保存在leastIndexs数组里面，累加权重值，如果当前的权重值不等于初始值firstWeight，那么就认定不是所有的调用者的权重不同。然后再遍历lestIndexs，取权重累加值的随机数生成权重偏移量，在累减它，到它小于0的时候返回那个调用者。如果这些都不符合，就从leastIndexs随机选一个index，返回那个调用者！
ConsistentHash LoadBalance

一致性Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动。


注意调度策略：
Dispatch

   所有的sent事件方法、心跳请求全部在IO线程上执行。

   1、all : 除sent事件回调方法、心跳外，全部在线程池上执行。

   2、execution : 与all类似，唯一区就是all在线程池未指定时，可以使用共享线程池，这个差别等同于没有。

   3、 message : 只有请求事件在线程池中执行，其他在IO线程上执行。

   4、connection : 请求事件在线程池中执行，连接、断开连接事件排队执行（含一个线程的线程池）

   5、direct : 所有事件都在IO线程中执行。

服务提供者在启动的时候，向zk上的/dubbo/${serviceName}/providers目录下写下自己的URL地址

dubbo会先调用checkAndUpdateSubConfigs方法检查配置是否合理，如果合理再调用doExportUrlsFor1Protocol方法通过配置组装URL，然后调用doExportUrl方法进行服务暴露
注：注册中心

客户端会先检查配置是否合理，然后创建RegisterDirectory实例，生成服务消费者链接向注册中心注册，然后订阅providers，configurators，routers节点下的数据
由于一个服务可能部署在多台服务器上，这样就会在 providers 产生多个节点，这个时候就需要 Cluster 将多个服务节点合并为一个，并生成一个 Invoker。
Zookeeper：

分布式协调和通知：不同的客户端都对Zookeeper上的同一个数据节点进行Watcher注册，监听数据节点的变化。若数据节点发生变化，那么所有订阅的客户端都能够接收到相应的Watcher通知，并作出相应处理。
2)集群管理：

a.客户端如果对Zookeeper的数据节点注册Watcher监听，那么当该数据及诶单内容或是其子节点列表发生变更时，Zookeeper服务器就会向订阅的客户端发送变更通知。b. 对在Zookeeper上创建的临时节点，一旦客户端与服务器之间的会话失效，那么临时节点也会被自动删除。

3）负载均衡：com.alibaba.dubbo.rpc.cluster.LoadBalance类

Random LoadBalance(默认使用)

随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
看方法的细节就是首先遍历每个提供服务的机器，获取每个服务的权重，然后累加权重值，判断每个服务的提供者权重是否相同，如果每个调用者的权重不相同，并且每个权重大于0，那么就会根据权重的总值生成一个随机数，再用这个随机数，根据调用者的数量每次减去调用者的权重，直到计算出当前的服务提供者随机数小于0，就选择那个提供者！另外，如果每个机器的权重的都相同，那么权重就不会参与计算，直接选择随机算法生成的某一个选择，完全随机。可以看出，随机调用法，
RoundRobin LoadBalance

轮询，按公约后的权重设置轮询比率。
存在慢的提供者类即请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
轮询调用，轮询调用的过程主要是维护了局部变量的一个LinkdesHashMap（有顺序的Map）去存储调用者和权重值的对应关系，然后遍历每个调用者,把调用者和当前大于0的权重值放进去，再累加权重值。还有一个全局变量的map，找到第一个服务调用者，首先是找到每个服务的key值和method，这里可以理解为标识第一个调用者的唯一key，然后再给它对应的值保证原子性的+1（AtomicPositiveInteger是原子的），再对这个值取模总权重，再每次对其权重值-1，知道它取模与总权重值等于0就选择该调用者，可以称之为"降权取模"（只是一种的计算层面,而不是真正降权）。总结：轮询调用并不是简单的一个接着一个依次调用，它是根据权重的值进行循环的。
LeastActive LoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
最少活跃数调用法：这个方法的主要作用根据服务的提供者的运行状态去选择服务器,主要的思路就是遍历每个调用者，然后获取每个服务器的运行状态，如果当前运行的运行状态小于最小的状态-1，把它保存在leastIndexs中的第一个位置，并且认定所有的调用者权重都相同，然后直接返回那个调用者(这里的逻辑是：找到最少活跃数(在代码层反应就是：active的值))。如果计算出的权重值和最少的权重值相同，那么把它保存在leastIndexs数组里面，累加权重值，如果当前的权重值不等于初始值firstWeight，那么就认定不是所有的调用者的权重不同。然后再遍历lestIndexs，取权重累加值的随机数生成权重偏移量，在累减它，到它小于0的时候返回那个调用者。如果这些都不符合，就从leastIndexs随机选一个index，返回那个调用者！
ConsistentHash LoadBalance

一致性Hash，相同参数的请求总是发到同一提供者。
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动。


注意调度策略：
Dispatch

   所有的sent事件方法、心跳请求全部在IO线程上执行。

   1、all : 除sent事件回调方法、心跳外，全部在线程池上执行。

   2、execution : 与all类似，唯一区就是all在线程池未指定时，可以使用共享线程池，这个差别等同于没有。

   3、 message : 只有请求事件在线程池中执行，其他在IO线程上执行。

   4、connection : 请求事件在线程池中执行，连接、断开连接事件排队执行（含一个线程的线程池）

   5、direct : 所有事件都在IO线程中执行。