关于dubbo的理解

服务方和消费方仅在启动时，才与注册中心交互(注册中心：服务方注册，消费方订阅)。注册中心不做请求转发，减少其压力；

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销；

服务消费者是采用拉取的方式，调用注册中心的服务列表接口，获取服务列表。并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销 ；

如果服务不可用，注册中心采用的是推送方式（注册中心通过长连接感知服务提供方的可用性），通知消费者，消费者基于服务列表，通过负载，热备，failover配置等方式，去尝试与其他服务的提供者通讯；

已运行的提供者和消费者，消费者在本地缓存了提供者列表 ，所以注册中心（监控中心）都是可选的，服务消费者可以直连服务提供者。

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

服务治理包含：服务的定义（服务边界），服务的注册与服务间的通讯，流控，服务状态的监控（调用次数，服务的关系展示，动态服务关系的绑定，服务的升降级）。

基于以上，可总结dubbo如何实现的软负载均衡：

dubbo中关于负载的核心层：cluster，包括路由层，封装多个提供者的路由及负载均衡，并桥接注册中心
 服务消费者，从提供者地址列表中（注册中心下发[某服务方挂掉时，推送新的url列表]，当然消费方也有缓存），基于软负载均衡算法，选一台提供者进行调用，如果调用
 失败，再选另一台调用。
 那么选一台进行调用，如何选？
“服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。“
所以既然能够得到调用次数，就可以知道集群中服务者的状态，由cluster层进行实现负载的算法，结合路由，把调用定位到最终的服务者去。

然后采取相应的算法和策略
 随机，轮循，最少活跃调用数，一致性Hash（相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动）