使用dubbox后的一些记录

Dubbox的运行机制:

        配上自己画的运行图:

            

                                                (手残。。。。)

    服务调用说明：

        0.服务启动，加载，运行服务提供者

                配置：1.引入jar包

                          2.创建服务接口，小demo

                                    

                         3.接口实现   

                                

                        4.配置web.xml     配置一个监听器。加载spring容器

                                 

                        5.配置Service的配置文件applicationContext-service.xml

                                

                                    

        1.服务提供者启动时会去注册中心注册，启动的服务地址

        2.消费者启动时，会向注册中心订阅需要的服务

                消费者配置：1.    基本的web.xml配置

                                

                                

        3.注册中心返回服务提供者的地址列表给消费者，如果有变更，会推送变更数据给消费者

        4.服务消费者，根据地址列表，基于软负载均衡算法，选一台提供者进行调用，如果失败，调用另一台

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

服务注册中心：

        服务注册中心一般有zookeeper实现，通过注册中心可以实现集群，负载均衡，高可用等重要功能

        也可以使用redis和其他方式。

        当服务提供者注册服务时，会在 /dubbo节点下创建提供的服务节点，包括提供者 

        ip、port等信息。服务关闭时对应节点就会移除

        服务消费者会去注册中心寻找服务，可能一个服务会有多个提供者，注册中心

会帮我们找适合的服务提供者

集群容错

当服务调用失败时（比如响应超时），根据我们的业务不同，可以使用不同的策略来应对这种失败。 
      比如我们调用的服务是一个查询服务，不会修改数据库，那么可以给该服务设置容错方式为failover ， 当调用失败时，自动切换到其他服务提供者去调用，当失败次数超过指定重试次数，那么就抛出错误。
     如果服务是更新数据的服务，那就不能使用失败重试的方式了， 因为这样可能产生数据重复修改的问题，比如调用提供者A的插入用户方法，但是该方法业务逻辑复杂，执行过程很慢，导致响应超时， 那么此时如果再去调用另外一个服务提供者的插入用户方法，将会又重复插入同一个用户。   对于这种类型的服务，可以使用容错方式为failfast，如果第一次调用失败，立即报错，不需要重试。
    另外还有下面几种容错类型
    failsafe 出现错误，直接忽略，不重试也不报错
    failback 失败后不报错，会将该失败请求，定时重发，适合消息通知类型的服务

    forking    并行调用多个服务器，只要在某一台提供者上面成功，那么方法返回， 适合实时性要求较高的查询服务， 但是要牺牲性能。因为每台服务器会做同一个操作
   broadcast 广播调用所有服务提供者，逐个调用，任意一台报错则报错。  适合与更新每台提供者上面的缓存  这泓类型的服务

下面的转载于：http://blog.csdn.net/is_zhoufeng/article/details/46674911

3、直连提供者

   在开发阶段为了方便测试，通常系统客户端能指定调用某个服务提供者，那么可以在引用服务时加一个url参数去指定服务提供者

4、负载均衡
    当同一个服务有多个提供者在提供服务时， 客户端如何正确的选择提供者实现负载均衡dubbo也给我们提供了几种方案
    random  随机选提供者，并可以给提供者设置权重
    roundrobin  轮询选择提供者
    leastactive  最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
   consistenthash 一致性hash，相同参数的请求发到同一台机器上

5、服务版本，服务分组
   通过服务版本可以控制服务的不兼容升级， 当同一个服务有多种实现时，可以使用服务分组进行区分


6、多协议
   dubbo提供了多种协议给用户选择， 如dubbo、hessian、rmi 。 并可为每个服务指定不同的传输协议，粒度可以细化到方法， 不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议。