架构实战项目心得（八）：dubbo知识的整理
1 Dubbo启动时检查、集群容错、负载均衡、线程模型的设置以及选项：
启动时检查：
(1)Dubbo默认会在启动的时候检查依赖的服务是否可用，不可用时会抛出异常。阻止Spring初始化完成。以便上线时能及早发现问题。
(2)默认check="true"dubbo.properties可以直接配置:dubbo.reference.check=false,强制改变所有reference的check值，就算配置中有声明，也会被覆盖。
(1)Failover Cluster: 失败自动切换，当出现失败，重试其他服务器。通常用于读操作，但重试会带来更长延迟。可通过retries="2" 来设置重试次数（不包含第一次）
(2)Failfast Cluster: 快速失败，只发起一次调用，失败立即报错。通常用于非幂等写的操作，比如新增记录。
(3)Failsafe Cluster: 失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作。
(4)Failback Cluster: 失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作。
(5)Forking Cluster: 并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作，但是要浪费更多的服务资源。可通过forks="2" 来设置最大并行数。
(6)Broadcast Cluster: 广播调用所有提供者，这个调用，任意一台报错即报错，通常用于通知所有提供者更新缓存日志等本地资源信息。
负载均衡：
在集群负载均衡时，Dubbo提供了多种均衡策略，默认为random随机调用。
(1)Random Loadbalance：随机，按权重设置随机概率，在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重
(2)RoundRobin Loadbalance：轮询，按公约后的权重设置轮询比例。存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡那，久而久之，所有请求都会卡在调到第二台上。
(3)LeastActive Loadbalance：最少活跃调用数，相同活跃数的随机，活跃数是指调用前后计数差，慢的提供者收到更少请求，因为越慢的提供者调用前后计数差会越大
(4)ConsistentHash Loadbalance: 一致性Hash，相同参数的请求总是发到同一提供者，当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动。
线程模型：
如果事件处理的逻辑能迅速完成，并且不会发起新的IO请求，比如只是在内存中记一个标识，则直接在IO线程上处理更快，因为减少了线程池调度。
但如果事件处理逻辑较慢，或者需要发起新的IO请求，比如需要查询数据库，则必须派发到线程池，否则IO线程阻塞，将导致不能接收其它请求。
Dispatcher
(1)all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
(2)direct 所有消息都不派发到线程池，全部在IO线程上直接执行。
(3)message 只有请求响应消息派发到线程池，其它连接断开事件、心跳等消息，直接在IO线程上执行。
(4)execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件、心跳等消息，直接在IO线程上执行。
(5)connection 在IO线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
ThreadPool
(1)fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。（默认）
(2)cached 缓存线程池，空闲一分钟自动删除，需要时重连。
(3)limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。 配置方式如下：
直连：
在开发及测试环境下，经常需要绕过注册中心，只测试指定的服务提供者，这时候可能需要点对点直连，点对点直连方式，将以服务接口为单位，忽略注册中心的提供者列表，A接口配置点对点，不影响B接口从注册中心获取列表。
如果是线上需求需要点对点，可在<dubbo:reference>中配置url指向提供者，将绕过注册中心，多个地址用分号隔开，配置如下：
如果有两个镜像环境，两个注册中心，有一个服务只在其中一个注册中心有部署，另一个注册中心还没来得及部署，而两个注册中心的其他应用都需要依赖此服务。这个时候，可以让服务提供方只注册服务到另一个注册中心，而不从另一注册中心订阅服务。
采用Spring的HttpInvoker实现
2.3.0以上版本支持，基于CXF的frontend-simple和transports-http实现。
memcached说明：memcached是一个高效的KV缓存服务器
redis://
redis说明：redis是一个高效的KV存储服务器。
启动时检查：
(1)Dubbo默认会在启动的时候检查依赖的服务是否可用，不可用时会抛出异常。阻止Spring初始化完成。以便上线时能及早发现问题。
(2)默认check="true"dubbo.properties可以直接配置:dubbo.reference.check=false,强制改变所有reference的check值，就算配置中有声明，也会被覆盖。
集群容错：
在集群调用失败时，Dubbo提供了多钟容错方案，默认为failover重试。(1)Failover Cluster: 失败自动切换，当出现失败，重试其他服务器。通常用于读操作，但重试会带来更长延迟。可通过retries="2" 来设置重试次数（不包含第一次）
(2)Failfast Cluster: 快速失败，只发起一次调用，失败立即报错。通常用于非幂等写的操作，比如新增记录。
(3)Failsafe Cluster: 失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作。
(4)Failback Cluster: 失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作。
(5)Forking Cluster: 并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作，但是要浪费更多的服务资源。可通过forks="2" 来设置最大并行数。
(6)Broadcast Cluster: 广播调用所有提供者，这个调用，任意一台报错即报错，通常用于通知所有提供者更新缓存日志等本地资源信息。
负载均衡：
在集群负载均衡时，Dubbo提供了多种均衡策略，默认为random随机调用。
(1)Random Loadbalance：随机，按权重设置随机概率，在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重
(2)RoundRobin Loadbalance：轮询，按公约后的权重设置轮询比例。存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡那，久而久之，所有请求都会卡在调到第二台上。
(3)LeastActive Loadbalance：最少活跃调用数，相同活跃数的随机，活跃数是指调用前后计数差，慢的提供者收到更少请求，因为越慢的提供者调用前后计数差会越大
(4)ConsistentHash Loadbalance: 一致性Hash，相同参数的请求总是发到同一提供者，当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动。
线程模型：
如果事件处理的逻辑能迅速完成，并且不会发起新的IO请求，比如只是在内存中记一个标识，则直接在IO线程上处理更快，因为减少了线程池调度。
但如果事件处理逻辑较慢，或者需要发起新的IO请求，比如需要查询数据库，则必须派发到线程池，否则IO线程阻塞，将导致不能接收其它请求。
Dispatcher
(1)all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
(2)direct 所有消息都不派发到线程池，全部在IO线程上直接执行。
(3)message 只有请求响应消息派发到线程池，其它连接断开事件、心跳等消息，直接在IO线程上执行。
(4)execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件、心跳等消息，直接在IO线程上执行。
(5)connection 在IO线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
ThreadPool
(1)fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。（默认）
(2)cached 缓存线程池，空闲一分钟自动删除，需要时重连。
(3)limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。 配置方式如下：
<dubbo:protocol name="test" contextpath="xxx-web-service" port="8080" server="servlet" dispatcher="all" threads="100" />2 Dubbo直连、只订阅、只注册：
直连：
在开发及测试环境下，经常需要绕过注册中心，只测试指定的服务提供者，这时候可能需要点对点直连，点对点直连方式，将以服务接口为单位，忽略注册中心的提供者列表，A接口配置点对点，不影响B接口从注册中心获取列表。
如果是线上需求需要点对点，可在<dubbo:reference>中配置url指向提供者，将绕过注册中心，多个地址用分号隔开，配置如下：
<dubbo:reference interface="com.laowang.service.IUserService" id="userService" timeout="10000" check="false" url="dubbo://localhost:2181" />只订阅：
<dubbo:registry address="zookeeper://localhost:2181" registry="false" />只注册：
如果有两个镜像环境，两个注册中心，有一个服务只在其中一个注册中心有部署，另一个注册中心还没来得及部署，而两个注册中心的其他应用都需要依赖此服务。这个时候，可以让服务提供方只注册服务到另一个注册中心，而不从另一注册中心订阅服务。
<dubbo:registry id="hzRegistry" address="zookeeper://192.168.1.131:2181" /> <dubbo:registry id="qdRegistry" address="zookeeper://192.168.1.130:2181" subscribe="false" />3 协议选择：
dubbo://
默认协议采用单一长连和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费机器数远大于服务提供者机器数的情况。 dubbo 默认协议不适合传大数据量的服务，比如传文件，传视频等，除非请求量很低。
<dubbo:protocol name="dubbo" port="20884" />
连接个数：单连接 连接方式：长连接 传输协议：TCP 传输方式：NIO异步传输 序列化：Hessian二进制序列化 适用范围：传入传出参数数据包较小（建议小于100k），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符。 适用场景：常规远程服务方法调用
rmi://
RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式。<dubbo:protocol name="rmi" port="1099" />
连接个数：多连接 连接方式：短连接 传输协议：TCP 传输方式：同步传输 序列化：JAVA标准二进制序列化 适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。 适用场景：常规远程服务方法调用，与原生RMI服务互操作Hessian://
Hessian协议用于集成Hessian服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo默认内嵌Jetty作为服务器实现。
<dubbo:protocol name="Hessian" port="8080" server="jetty" />
连接个数：多连接 连接方式：短连接 传输协议：HTTP 传输方式：同步传输 序列化：Hessian二进制序列化 适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。 适用场景：页面传输，文件传输，或与原生Hessian服务互操作。依赖：
<dependency> <groupId>com.caucho</groupId> <artifactId>hessian</artifactId> <version>4.0.7</version> </dependency>传统SpringMVC项目中的web.xml配置：
<servlet> <servlet-name>dubbo</servlet-name> <servlet-class>com.alibaba.dubbo.remoting.http.servlet.DispatcherServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dubbo</servlet-name> <url-pattern>/*<url-pattern> </servlet-mapping>http://
采用Spring的HttpInvoker实现
<dubbo:protocol name="http" port="8080"/>
连接个数：多连接 连接方式：短连接 传输协议：HTTP 传输方式：同步传输 序列化：表单序列化 适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用表单或URL传入参数，暂不支持传文件。 适用场景：需同时给应用程序和浏览器JS使用的服务。webservice://
2.3.0以上版本支持，基于CXF的frontend-simple和transports-http实现。
<dubbo:protocol name="webservice" port="8080" server="jetty" />依赖：
<dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-frontend-simple</artifactId> <version>2.6.1</version> </dependency> <dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-rt-transports-http</artifactId> <version>2.6.1</version> </dependency>
连接个数：多连接 连接方式：短连接 传输协议：HTTP 传输方式：同步传输 序列化：SOAP文本序列化 适用场景：系统集成，跨语言调用。thrift://
thrift说明：thrift是Facebook捐给Apache的一个RPC框架
依赖：
<dependency> <groupId>org.apache.thrift</groupId> <artifactId>libthrift</artifactId> <version>0.8.0</version> </dependency>
<dubbo:protocol name="thrift" port="3030" />memcached://
memcached说明：memcached是一个高效的KV缓存服务器
redis://
redis说明：redis是一个高效的KV存储服务器。
