《dubbo应用场景示例一》中我们介绍了3种dubbo应用场景，今天我们接着聊聊dubbo几种应用场景。
1、线程模型
如果事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识，则直接在 IO 线程上处理更快，因为减少了线程池调度。
但如果事件处理逻辑较慢，或者需要发起新的 IO 请求，比如需要查询数据库，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接收其它请求。
如果用 IO 线程处理事件，又在事件处理过程中发起新的 IO 请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。
因此，需要通过不同的派发策略和不同的线程池配置的组合来应对不同的场景:
<dubbo:protocolname="dubbo" dispatcher="all" threadpool="fixed"threads="100" />
Dispatcher
all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
execution 只请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
ThreadPool
l fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
l cached 缓存线程池，空闲一分钟自动删除，需要时重建。
l limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
2、直连提供者
在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直联方式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表。
通过 XML 配置
如果是线上需求需要点对点，可在中配置 url 指向提供者，将绕过注册中心，多个地址用分号隔开，配置如下（1.0.6 及以上版本支持）：
<dubbo:referenceid="xxxService" interface="com.alibaba.xxx.XxxService"url="dubbo://l ocalhost:20890"/>
通过 -D 参数指定
在 JVM 启动参数中加入-D参数映射服务地址（key 为服务名，value 为服务提供者 url，此配置优先级最高， 1.0.15 及以上版本支持） ，如：
java-Dcom.alibaba.xxx.XxxService=dubbo://localhost:20890
通过文件映射
如果服务比较多，也可以用文件映射，用 -Ddubbo.resolve.file 指定映射文件路径，此配置优先级高于 中的配置（1.0.15 及以上版本支持， 2.0 以上版本自动加载${user.home}/dubboresolve.properties文件，不需要配置） ，如：
java-Ddubbo.resolve.file=xxx.properties
然后在映射文件 xxx.properties 中加入配置，其中 key 为服务名，value 为服务提供者 URL：
com.alibaba.xxx.XxxService=dubbo://localhost:20890
注意为了避免复杂化线上环境，不要在线上使用这个功能，只应在测试阶段使用。
3、只订阅
为方便开发测试，经常会在线下共用一个所有服务可用的注册中心，这时，如果一个正在开发中的服务提供者注册，可能会影响消费者不能正常运行。
可以让服务提供者开发方，只订阅服务(开发的服务可能依赖其它服务)，而不注册正在开发的服务，通过直连测试正在开发的服务。
禁用注册配置
<dubbo:registryaddress="10.20.153.10:9090" register="false" />
或者
<dubbo:registryaddress="10.20.153.10:9090?register=false" />
