Dubbo

1.http://www.importnew.com/20327.html 

2.dubbo学习:http://www.cnblogs.com/renhq/p/4654925.html

常见异常：https://blog.csdn.net/so_geili/article/details/84896416

使用kryo协议，无法保证接口返回值添加属性时升级过程中的兼容，而hessian则可以兼容。

Kryo平均响应时长，每秒事务数，带宽节省等相对来说，的确是比较出众，当Kryo在Dubbo中应用足够成熟之后，使用其作为序列化的确是一个不错的选择。

http://arthinking.github.io/2016/10/15/java/dubbo/2016101501_dobbo%E5%BA%8F%E5%88%97%E5%8C%96%E6%96%B9%E5%BC%8F%E4%B8%8E%E7%89%88%E6%9C%AC%E5%8D%87%E7%BA%A7%E7%9A%84%E9%97%AE%E9%A2%98/

3.dubbo:分布式服务框架

   *.系统与系统之间优先考虑mq,系统内部之间交互考虑rpc(dubbo)

1.rpc的分布式集群支持：负载均衡是对外提供一个公共地址，请求过来时通过轮询、随机的形式来分摊压力，挂一台补一台

2.结合zookeeper解藕：(提供者注册和消费者订阅)客户端和服务端启动的时候都会把自己的机器IP注册到zookeeper上。客户端会把zk上的服务端ip拉到磁盘上，并记录哪些ip提供哪些服务（服务端启动的时候暴露给zk）。然后调用的时候客户端会根据ip调用服务端的服务，这时候即使zk挂掉也没关系

可用场景：

1.商城做活动流量暴涨：防止系统崩掉 可以通过dubbo来控制访问量

2.分布式服务器rpc过程调用压力分担

mq的2个好处是:
1.消息不丢失：服务端之间掉消息会保存到mq中间件中，当消费者服务器恢复后就会重新发过去，消息不会丢失

2.异步处理：比如一个商城用户购买产品后后台会去更新数据库然后响应给客户端，如果在高并发的情况下，这样更新数据库响应客户端会变慢，可以使用mq消息队列的消费者进程中获取数据来进行异步写数据，由于消息对垒的服务处理速度远快于数据库，
因此响应延迟能得到有效改善

来源： http://www.cnblogs.com/webster1/p/6641430.html

3.dubbo(默认集群模式)使用场景:项目之间相互调用的复杂,由dubbo辅助管理controller与service调用的关系(soa),dubbox是当当网扩展

   

4.Dubbo是一个分布式服务框架,提供高性能和透明化的RPC远程服务调用方案,SOA服务治理方案

   在分布式的时候才需要dubbo框架,本质上是远程服务调用的分布式框架(告别WebService模式中的WSdf,

   以服务者与消费者的方式在dubbo上注册,通过xml)

   核心:

          1.远程通讯:提供多种基于长连接的NIO框架抽象封装(netty)，包括多种线程模型序列化,以及"请求-响应"模式

   的信息交换方式

           2.集群容错:提供基于接口方法的透明远程过程调用,包括若协议支持,软负载均衡,失败容错，地址路由,动态

   配置等集群支持

           3.自动发现:基于注册中心(zookeeper)目录服务，使得服务消费方能动态的查找服务提供方，使地址透明，

   使服务提供方可以平滑增加或减少机器。

5.Dubbo功能:

    1.只需简单配置(xml配置service)即可完成透明化的远程方法调用(即像调用本地方法一样调用远程方法),无API侵入

    2.具有软负载均衡及容错机制的特点,可在内网替代F5等硬件负载均衡器,降低成本,减少单点资源浪费

    3.服务基于自动注册与发现(搭配zookeeper),无需写死服务提供方地址,注册中心基于接口名查询服务提供者ip，并且

       能够平滑添加或删除服务提供者

    4.dubbo采用全Spring配置方式，透明化接入应用,只需配置Dubbo基于Spring的Schema扩展即可,

6.dubbo官网：http://dubbo.io/ 

   

  节点角色说明:

   1.Provider：暴露服务的服务提供方 (jar)

   2.Consumer：调用远程服务的服务消费方 (war)

   3.Registry：服务注册与发现的注册中心(zookeeper)

   4.Monitor：统计服务的调用次和调用时间的监控中心

7.调用形式(xml):

   <bean id="xxxService" class="com.xxx.XxxServiceImpl">  //和本地服务一样的远程服务实现

   <dubbo:service interface="com.xxx.xxxService" ref="xxxService"/>  //增加暴露远程服务配置

  <dubbo:reference id="xxxService"  interface="com.xxx.XxxService"/>  //增加引用远程服务的配置

  <bean id="XxxAction"  class="com.xxx.XxxAction">

       <property name="xxxService" ref="xxxService">

 </bean>  

 8.启动dubbo一般使用dubbo的container包下的main方法来启动

9.解决dubbo关联的xsd问题:http://blog.csdn.net/wabiaozia/article/details/50491700 

10.eclipse安装zookeeper查看插件：http://blog.csdn.net/majinggogogo/article/details/51810698 

11.遇到xsd不能用,在配置已经下载好的xsd时,需要在最后加上dubbo.xsd    http://blog.csdn.net/gjldwz/article/details/50555922 

     

12.管控台版本最好与所使用的dubbo包版本一致,减少不必要的版本问题

    http://192.168.50.12:8080/dubbo-admin/ 

    

   1.上传dubbo-admin-2.5.4.war到linux下tomcat的webapp目录下

   2.unzip dubbo-admin-2.5.4.war -d dubbo-admin(没有unzip,yum install -y unzip zip下载即可)

   3.进入dubbo-admin的WEB-INF目录编辑dubbo.properties,修改zk集群配置

      

   4.担心tomcat启动内存不够,可在catalina.sh中修改启动内存配置,JAVA_OPTS=‘-Xms256m -Xmx512m’

   5.[root@node02 ~]# /root/soft/apache-tomcat-8.0.38/bin/startup.sh  启动tomcat，查看tomcat控制台输出 tail -f -n 300 catalina.out

13.注册中心写法:使用zookeeper注册中心暴露所提供服务的地址,也可用redis作为注册中心

 1.<dubbo:registry protocol="zookeeper" address="192.168.50.12:2181,192.168.50.13:2181,192.168.50.14:2181" />

 2.<dubbo:registry address="zookeeper://192.168.50.12:2181?backup=192.168.50.13:2181,192.168.50.14:2181" />  

14.服务禁用时报错：     

15.服务之间的依赖尽量不要太多(两层以下为宜)

     依赖时配置check=true(默认true)，启动时居然不检查依赖，直接Spring启动完成，怎么回事？

16.负载均衡(默认random机制):一般在管控台配置比较方便

    http://dubbo.io/books/dubbo-user-book/demos/fault-tolerent-strategy.html 

    a.random loadBalance：

       

     b.roundRobin loadBalance:

        

      c.leastActive loadBalance:

         

       d.consistentHash loadBalance:

          

17.线程模型:

   

  <dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100"/>

18.绕过zk,服务直连:在消费端引用进行url配置

   

来自为知笔记(Wiz)