标签：通知 res 手动 统计 启动 不能 属性 缓存 而且
1.分布式服务架构关键在于：用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
注册中心是关键，提供业务复用和整合。
2、dubbo在消费方，获取服务列表后提供软负载均衡。dubbo在消费方提供软负载均衡。
消费方在调用的时候，dubbo提供了软负载均衡。
3.dubbo监控中心:监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示.
服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销.
4.怎么证明消费者和提供者只在启动的时候与zookeeper交互一次，且只一次？
答：注册中心宕机了并不影响消费者和提供者的运行，即使zookeeper服务器宕机了，消费者和提供者依然正常运行。
因为消费者在启动的时候从zookeeper获取了服务提供者列表。
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表。
注册中心宕掉后，但不能注册新服务。不能再注册新服务了，旧的服务不影响运行。
5.注册中心也不能单点部署，要集群部署。防止单台宕机。叫注册中心对等集群。
5.dubbo配置时，注册中心是可选的，消费者可以和服务者直连。直接调用。
6.服务提供者的bean的方法，都是无状态的，所以即使一台service宕机后，不影响状态。
7.zookeeper有消息推送通知功能，当动态增加服务时候，消费者可以动态被通知，就可以调用。
服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者。
8.注意：服务提供者通过dubbo向zookeeper暴露服务时，向外面暴露的bean，必须首先自己bean依赖注入已经完毕，因为dubbo service标签有个必填的ref属性，指向本地ioc种
已经存在的bean。已经bean注入到ioc容器里了。
而且这时候最好手动注入，如下面方式：
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl”/> <!-- 和本地服务一样实现远程服务 -->
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” /> <!-- 增加暴露远程服务配置 -->
9.服务提供者是通过dubbo暴露服务的，通过dubbo向zookeeper。zookeeper只起到中介作用，会传输很多东西，包括服务提供者的ip地址，bean描述，方法描述等。
10.dubbo service标签，向zookeeper暴露服务。
11.服务消费方，注意，是与服务提供者沟通的，商量好消费方所写的，dubbo:reference标签，其中的id名字就是bean名字，提供者的bean名字，interface依旧是类全名。
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” /> <!-- 增加引用远程服务配置 -->
dubbo service标签有interface属性，其值是整个接口名，类路径全名。ref属性，指向ioc容器中已经存在的bean。
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” /> <!-- 增加暴露远程服务配置 -->
12.dubbo是没有单独配置文件的，dubbo的配置全在spring的配置文件里。不论是提供方还是消费方，dubbo都是没有配置文件的，都是在spring里。
dubbo是没有单独的配置文件的。dubbo是没有配置文件的。不论是提供方还是消费方，dubbo都是没有配置文件的，都是在spring里。
13.dubbo的配置，主要以下几条：
1）<dubbo:application 没多大意义，只是用来与消费方匹配，消费者必须不能是这个名字，消费者的application名字不能喝提供者一样。
2）<dubbo:registry address
3）<dubbo:protocol
4）<dubbo:service
就四个，就四个配置标签。
14.消费者在spring配置dubbo时候，只需要配置三个标签。
1）<!-- 消费方应用名，用于计算依赖关系，不是匹配条件，不要与提供方一样 -->
<dubbo:application name="consumer-of-helloworld-app" />
2）<dubbo:registry
3）<dubbo:reference
只需要三个标签，比提供者配置少了dubbo protocol标签的配置。
15.再次理解服务提供者，服务提供者是对外提供直接调用的，zookeeper不对外提供调用，而是由真正的服务提供提供服务。所以服务提供者必须向外暴露协议和端口。
就如dubbo protocol标签，这个标签的作用就是这个。如下：暴露20880端口，通过dubbo调用。
<!-- 用dubbo协议在20880端口暴露服务 -->
<dubbo:protocol name="dubbo" port="20880" />
16.<dubbo:protocol/> 协议配置问题，用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受。
服务方设置的dubbo protocol，消费方要调用的话，消费方就得被动接受提供方协议。
消费方被动接受。
消费方被动接受服务方提供和设置的协议。
16.选择合适的dubbo调用协议：
Dubbo协议 Stable 采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用） 在大文件传输时，单一连接会成为瓶颈
可用于生产环境 Alibaba
Rmi协议 Stable 可与原生RMI互操作，基于TCP协议 偶尔会连接失败，需重建Stub 可用于生产环境 Alibaba
Hessian协议 Stable 可与原生Hessian互操作，基于HTTP协议 需hessian.jar支持，http短连接的开销大 可用于生产环境
20.<dubbo:method/> 方法配置，用于ServiceConfig和ReferenceConfig指定方法级的配置信息。
21.其中，服务提供方配置，通过URL经由注册中心传递给消费方。
建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。
标签：通知 res 手动 统计 启动 不能 属性 缓存 而且
原文地址：http://www.cnblogs.com/panxuejun/p/6544254.html
