示例
启动时检查
Dubbo缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止Spring初始化完成,以便上线时,能及早发现问题,默认check=true。 |
如果你的Spring容器是懒加载的,或者通过API编程延迟引用服务,请关闭check,否则服务临时不可用时,会抛出异常,拿到null引用,如果check=false,总是会返回引用,当服务恢复时,能自动连上。 |
可以通过check="false"关闭检查,比如,测试时,有些服务不关心,或者出现了循环依赖,必须有一方先启动。
关闭某个服务的启动时检查:(没有提供者时报错)
关闭所有服务的启动时检查:(没有提供者时报错)
关闭注册中心启动时检查:(注册订阅失败时报错)
也可以用dubbo.properties配置:
也可以用-D参数:
注意区别
|
引用缺省是延迟初始化的,只有引用被注入到其它Bean,或被getBean()获取,才会初始化。
如果需要饥饿加载,即没有人引用也立即生成动态代理,可以配置:
集群容错
在集群调用失败时,Dubbo提供了多种容错方案,缺省为failover重试。 |
各节点关系:
- 这里的Invoker是Provider的一个可调用Service的抽象,Invoker封装了Provider地址及Service接口信息。
- Directory代表多个Invoker,可以把它看成List<Invoker>,但与List不同的是,它的值可能是动态变化的,比如注册中心推送变更。
- Cluster将Directory中的多个Invoker伪装成一个Invoker,对上层透明,伪装过程包含了容错逻辑,调用失败后,重试另一个。
- Router负责从多个Invoker中按路由规则选出子集,比如读写分离,应用隔离等。
- LoadBalance负责从多个Invoker中选出具体的一个用于本次调用,选的过程包含了负载均衡算法,调用失败后,需要重选。
集群容错模式:
可以自行扩展集群容错策略,参见:集群扩展
Failover Cluster
- 失败自动切换,当出现失败,重试其它服务器。(缺省)
- 通常用于读操作,但重试会带来更长延迟。
- 可通过retries="2"来设置重试次数(不含第一次)。
Failfast Cluster
- 快速失败,只发起一次调用,失败立即报错。
- 通常用于非幂等性的写操作,比如新增记录。
Failsafe Cluster
- 失败安全,出现异常时,直接忽略。
- 通常用于写入审计日志等操作。
Failback Cluster
- 失败自动恢复,后台记录失败请求,定时重发。
- 通常用于消息通知操作。
Forking Cluster
- 并行调用多个服务器,只要一个成功即返回。
- 通常用于实时性要求较高的读操作,但需要浪费更多服务资源。
- 可通过forks="2"来设置最大并行数。
Broadcast Cluster
- 广播调用所有提供者,逐个调用,任意一台报错则报错。(2.1.0开始支持)
- 通常用于通知所有提供者更新缓存或日志等本地资源信息。
重试次数配置如:(failover集群模式生效)
或:
或:
集群模式配置如:
或:
负载均衡
在集群负载均衡时,Dubbo提供了多种均衡策略,缺省为random随机调用。 |
可以自行扩展负载均衡策略,参见:负载均衡扩展
Random LoadBalance
- 随机,按权重设置随机概率。
- 在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。
RoundRobin LoadBalance
- 轮循,按公约后的权重设置轮循比率。
- 存在慢的提供者累积请求问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。
LeastActive LoadBalance
- 最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
- 使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance
- 一致性Hash,相同参数的请求总是发到同一提供者。
- 当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。
- 算法参见:http://en.wikipedia.org/wiki/Consistent_hashing。
- 缺省只对第一个参数Hash,如果要修改,请配置<dubbo:parameter key="hash.arguments" value="0,1" />
- 缺省用160份虚拟节点,如果要修改,请配置<dubbo:parameter key="hash.nodes" value="320" />
配置如:
或:
或:
或:
线程模型
事件处理线程说明
|
- Dispatcher
- all 所有消息都派发到线程池,包括请求,响应,连接事件,断开事件,心跳等。
- direct 所有消息都不派发到线程池,全部在IO线程上直接执行。
- message 只有请求响应消息派发到线程池,其它连接断开事件,心跳等消息,直接在IO线程上执行。
- execution 只请求消息派发到线程池,不含响应,响应和其它连接断开事件,心跳等消息,直接在IO线程上执行。
- connection 在IO线程上,将连接断开事件放入队列,有序逐个执行,其它消息派发到线程池。
- ThreadPool
- fixed 固定大小线程池,启动时建立线程,不关闭,一直持有。(缺省)
- cached 缓存线程池,空闲一分钟自动删除,需要时重建。
- limited 可伸缩线程池,但池中的线程数只会增长不会收缩。(为避免收缩时突然来了大流量引起的性能问题)。
配置如:
直连提供者
在开发及测试环境下,经常需要绕过注册中心,只测试指定服务提供者,这时候可能需要点对点直连,
点对点直联方式,将以服务接口为单位,忽略注册中心的提供者列表,
A接口配置点对点,不影响B接口从注册中心获取列表。
(1) 如果是线上需求需要点对点,可在<dubbo:reference>中配置url指向提供者,将绕过注册中心,多个地址用分号隔开,配置如下:(1.0.6及以上版本支持)
(2) 在JVM启动参数中加入-D参数映射服务地址,如:
(key为服务名,value为服务提供者url,此配置优先级最高,1.0.15及以上版本支持)
注意 为了避免复杂化线上环境,不要在线上使用这个功能,只应在测试阶段使用。 |
(3) 如果服务比较多,也可以用文件映射,如:
(用-Ddubbo.resolve.file指定映射文件路径,此配置优先级高于<dubbo:reference>中的配置,1.0.15及以上版本支持)
(2.0以上版本自动加载${user.home}/dubbo-resolve.properties文件,不需要配置)
然后在映射文件xxx.properties中加入:
(key为服务名,value为服务提供者url)
注意 为了避免复杂化线上环境,不要在线上使用这个功能,只应在测试阶段使用。 |
只订阅
问题 为方便开发测试,经常会在线下共用一个所有服务可用的注册中心,这时,如果一个正在开发中的服务提供者注册,可能会影响消费者不能正常运行。 |
解决方案 可以让服务提供者开发方,只订阅服务(开发的服务可能依赖其它服务),而不注册正在开发的服务,通过直连测试正在开发的服务。 |
禁用注册配置:
或者:
只注册
问题 如果有两个镜像环境,两个注册中心,有一个服务只在其中一个注册中心有部署,另一个注册中心还没来得及部署,而两个注册中心的其它应用都需要依赖此服务,所以需要将服务同时注册到两个注册中心,但却不能让此服务同时依赖两个注册中心的其它服务。 |
解决方案 可以让服务提供者方,只注册服务到另一注册中心,而不从另一注册中心订阅服务。 |
禁用订阅配置:
或者:
静态服务
有时候希望人工管理服务提供者的上线和下线,此时需将注册中心标识为非动态管理模式。 |
或者:
服务提供者初次注册时为禁用状态,需人工启用,断线时,将不会被自动删除,需人工禁用。
如果是一个第三方独立提供者,比如memcached等,可以直接向注册中心写入提供者地址信息,消费者正常使用:
(通常由脚本监控中心页面等调用)
多协议
可以自行扩展协议,参见:协议扩展
(1) 不同服务不同协议
比如:不同服务在性能上适用不同协议进行传输,比如大数据用短连接协议,小数据大并发用长连接协议。
(2) 多协议暴露服务
比如:需要与http客户端互操作
多注册中心
可以自行扩展注册中心,参见:注册中心扩展
(1) 多注册中心注册
比如:中文站有些服务来不及在青岛部署,只在杭州部署,而青岛的其它应用需要引用此服务,就可以将服务同时注册到两个注册中心。
(2) 不同服务使用不同注册中心
比如:CRM有些服务是专门为国际站设计的,有些服务是专门为中文站设计的。
(3) 多注册中心引用
比如:CRM需同时调用中文站和国际站的PC2服务,PC2在中文站和国际站均有部署,接口及版本号都一样,但连的数据库不一样。
如果只是测试环境临时需要连接两个不同注册中心,使用竖号分隔多个不同注册中心地址:
服务分组
当一个接口有多种实现时,可以用group区分。 |
任意组:(2.2.0以上版本支持,总是只调一个可用组的实现)
多版本
当一个接口实现,出现不兼容升级时,可以用版本号过渡,版本号不同的服务相互间不引用。 |
- 在低压力时间段,先升级一半提供者为新版本
- 再将所有消费者升级为新版本
- 然后将剩下的一半提供者升级为新版本
不区分版本:(2.2.0以上版本支持)
分组聚合
按组合并返回结果,比如菜单服务,接口一样,但有多种实现,用group区分,现在消费方需从每种group中调用一次返回结果,合并结果返回,这样就可以实现聚合菜单项。 |
从2.1.0版本开始支持 |
配置如:(搜索所有分组)
或:(合并指定分组)
或:(指定方法合并结果,其它未指定的方法,将只调用一个Group)
或:(某个方法不合并结果,其它都合并结果)
或:(指定合并策略,缺省根据返回值类型自动匹配,如果同一类型有两个合并器时,需指定合并器的名称)
参见:[合并结果扩展]
或:(指定合并方法,将调用返回结果的指定方法进行合并,合并方法的参数类型必须是返回结果类型本身)
参数验证
参数验证功能是基于JSR303实现的,用户只需标识JSR303标准的验证Annotation,并通过声明filter来实现验证。 |
2.1.0以上版本支持 |
验证方式可扩展,参见:Validation扩展点
参数标注示例:
分组验证示例:
关联验证示例:
参数验证示例:
在客户端验证参数:
在服务器端验证参数:
验证异常信息:
需要加入依赖:
结果缓存
结果缓存,用于加速热门数据的访问速度,Dubbo提供声明式缓存,以减少用户加缓存的工作量。 |
2.1.0以上版本支持 |
- lru 基于最近最少使用原则删除多余缓存,保持最热的数据被缓存。
- threadlocal 当前线程缓存,比如一个页面渲染,用到很多portal,每个portal都要去查用户信息,通过线程缓存,可以减少这种多余访问。
- jcache 与JSR107集成,可以桥接各种缓存实现。
缓存类型可扩展,参见:CacheFactory扩展点
配置如:
或:
泛化引用
泛接口调用方式主要用于客户端没有API接口及模型类元的情况,参数及返回值中的所有POJO均用Map表示,通常用于框架集成,比如:实现一个通用的服务测试框架,可通过GenericService调用所有服务实现。 |
假设存在POJO如:
则POJO数据:
可用下面Map表示:
泛化实现
泛接口实现方式主要用于服务器端没有API接口及模型类元的情况,参数及返回值中的所有POJO均用Map表示,通常用于框架集成,比如:实现一个通用的远程服务Mock框架,可通过实现GenericService接口处理所有服务请求。 |
回声测试
回声测试用于检测服务是否可用,回声测试按照正常请求流程执行,能够测试整个调用是否通畅,可用于监控。 |
所有服务自动实现EchoService接口,只需将任意服务引用强制转型为EchoService,即可使用。 |
上下文信息
上下文中存放的是当前调用过程中所需的环境信息。 |
所有配置信息都将转换为URL的参数,参见《配置项一览表》中的“对应URL参数”一列。 |
注意 RpcContext是一个ThreadLocal的临时状态记录器,当接收到RPC请求,或发起RPC请求时,RpcContext的状态都会变化。 比如:A调B,B再调C,则B机器上,在B调C之前,RpcContext记录的是A调B的信息,在B调C之后,RpcContext记录的是B调C的信息。 |
(1) 服务消费方
(2) 服务提供方
隐式传参
注:path,group,version,dubbo,token,timeout几个key有特殊处理,请使用其它key值。 |
(1) 服务消费方
【注】 setAttachment设置的KV,在完成下面一次远程调用会被清空。即多次远程调用要多次设置。
(2) 服务提供方
异步调用
基于NIO的非阻塞实现并行调用,客户端不需要启动多线程即可完成并行调用多个远程服务,相对多线程开销较小。 |
2.0.6及其以上版本支持 |
配置声明:
调用代码:
你也可以设置是否等待消息发出:(异步总是不等待返回)
- sent="true" 等待消息发出,消息发送失败将抛出异常。
- sent="false" 不等待消息发出,将消息放入IO队列,即刻返回。
如果你只是想异步,完全忽略返回值,可以配置return="false",以减少Future对象的创建和管理成本:
本地调用
本地调用,使用了Injvm协议,是一个伪协议,它不开启端口,不发起远程调用,只在JVM内直接关联,但执行Dubbo的Filter链。 |
Define injvm protocol:
Set default protocol:
Set service protocol:
Use injvm first:
或
注意:服务暴露与服务引用都需要声明injvm="true" |
从 dubbo 2.2.0 开始,每个服务默认都会在本地暴露;在引用服务的时候,默认优先引用本地服务;如果希望引用远程服务可以使用一下配置强制引用远程服务。
参数回调
参数回调方式与调用本地callback或listener相同,只需要在Spring的配置文件中声明哪个参数是callback类型即可,Dubbo将基于长连接生成反向代理,这样就可以从服务器端调用客户端逻辑。 |
2.0.6及其以上版本支持 |
(1) 共享服务接口:
服务接口示例:
(2) 服务提供者:
服务提供者接口实现示例:
服务提供者配置示例:
(2) 服务消费者:
服务消费者配置示例:
服务消费者调用示例:
事件通知
在调用之前,调用之后,出现异常时,会触发oninvoke, onreturn, onthrow三个事件,可以配置当事件发生时,通知哪个类的哪个方法。 |
支持版本:2.0.7之后 |
(1) 服务提供者与消费者共享服务接口:
(2) 服务提供者实现:
(3) 服务提供者配置:
(4) 服务消费者Callback接口及实现:
(5) 服务消费者Callback接口及实现:
注: callback与async功能正交分解: async=true,表示结果是否马上返回. onreturn 表示是否需要回调. 组合情况:(async=false 默认) |
(6) TEST CASE:
本地存根
远程服务后,客户端通常只剩下接口,而实现全在服务器端,但提供方有些时候想在客户端也执行部分逻辑,比如:做ThreadLocal缓存,提前验证参数,调用失败后伪造容错数据等等,此时就需要在API中带上Stub,客户端生成Proxy实,会把Proxy通过构造函数传给Stub,然后把Stub暴露组给用户,Stub可以决定要不要去调Proxy。 |
Stub必须有可传入Proxy的构造函数。 |
Or:
api.jar:
本地伪装
Mock通常用于服务降级,比如某验权服务,当服务提供方全部挂掉后,客户端不抛出异常,而是通过Mock数据返回授权失败。 |
Mock是Stub的一个子集,便于服务提供方在客户端执行容错逻辑,因经常需要在出现RpcException(比如网络失败,超时等)时进行容错,而在出现业务异常(比如登录用户名密码错误)时不需要容错,如果用Stub,可能就需要捕获并依赖RpcException类,而用Mock就可以不依赖RpcException,因为它的约定就是只有出现RpcException时才执行。 |
Or:
api.jar:
如果服务的消费方经常需要try-catch捕获异常,如:
请考虑改为Mock实现,并在Mock中return null。
如果只是想简单的忽略异常,在2.0.11以上版本可用:
延迟暴露
如果你的服务需要Warmup时间,比如初始化缓存,等待相关资源就位等,可以使用delay进行延迟暴露。 |
延迟5秒暴露服务:
延迟到Spring初始化完成后,再暴露服务:(基于Spring的ContextRefreshedEvent事件触发暴露)
Spring2.x初始化死锁问题 在Spring解析到<dubbo:service />时,就已经向外暴露了服务,而Spring还在接着初始化其它Bean。 如果这时有请求进来,并且服务的实现类里有调用applicationContext.getBean()的用法。 1. 请求线程的applicationContext.getBean()调用,先同步singletonObjects判断Bean是否存在,不存在就同步beanDefinitionMap进行初始化,并再次同步singletonObjects写入Bean实例缓存。 这样就导致getBean线程,先锁singletonObjects,再锁beanDefinitionMap,再次锁singletonObjects。 |
规避办法 1. 强烈建议不要在服务的实现类中有applicationContext.getBean()的调用,全部采用IoC注入的方式使用Spring的Bean。 2. 如果实在要调getBean(),可以将Dubbo的配置放在Spring的最后加载。 3. 如果不想依赖配置顺序,可以使用<dubbo:provider deplay=”-1” />,使Dubbo在Spring容器初始化完后,再暴露服务。 4. 如果大量使用getBean(),相当于已经把Spring退化为工厂模式在用,可以将Dubbo的服务隔离单独的Spring容器。 |
并发控制
限制com.foo.BarService的每个方法,服务器端并发执行(或占用线程池线程数)不能超过10个:
限制com.foo.BarService的sayHello方法,服务器端并发执行(或占用线程池线程数)不能超过10个:
限制com.foo.BarService的每个方法,每客户端并发执行(或占用连接的请求数)不能超过10个:
Or:
限制com.foo.BarService的sayHello方法,每客户端并发执行(或占用连接的请求数)不能超过10个:
Or:
如果<dubbo:service>和<dubbo:reference>都配了actives,<dubbo:reference>优先,参见:配置的覆盖策略。
Load Balance均衡:
配置服务的客户端的loadbalance属性为leastactive,此Loadbalance会调用并发数最小的Provider(Consumer端并发数)。
Or:
连接控制
限制服务器端接受的连接不能超过10个:(以连接在Server上,所以配置在Provider上)
限制客户端服务使用连接连接数:(如果是长连接,比如Dubbo协议,connections表示该服务对每个提供者建立的长连接数)
Or:
如果<dubbo:service>和<dubbo:reference>都配了connections,<dubbo:reference>优先,参见:配置的覆盖策略。
延迟连接
延迟连接,用于减少长连接数,当有调用发起时,再创建长连接。 |
只对使用长连接的dubbo协议生效。 |
粘滞连接
粘滞连接用于有状态服务,尽可能让客户端总是向同一提供者发起调用,除非该提供者挂了,再连另一台。 |
令牌验证
- 防止消费者绕过注册中心访问提供者
- 在注册中心控制权限,以决定要不要下发令牌给消费者
- 注册中心可灵活改变授权方式,而不需修改或升级提供者
可以全局设置开启令牌验证:
也可在服务级别设置:
还可在协议级别设置:
路由规则
2.2.0以上版本支持 |
路由规则扩展点:路由扩展 |
向注册中心写入路由规则:(通常由监控中心或治理中心的页面完成)
其中:
- condition://
- 0.0.0.0
- 表示对所有IP地址生效,如果只想对某个IP的生效,请填入具体IP,必填。
- com.foo.BarService
- 表示只对指定服务生效,必填。
- category=routers
- 表示该数据为动态配置类型,必填。
- dynamic=false
- 表示该数据为持久数据,当注册方退出时,数据依然保存在注册中心,必填。
- enabled=true
- 覆盖规则是否生效,可不填,缺省生效。
- force=false
- 当路由结果为空时,是否强制执行,如果不强制执行,路由结果为空的路由规则将自动失效,可不填,缺省为flase。
- runtime=false
- 是否在每次调用时执行路由规则,否则只在提供者地址列表变更时预先执行并缓存结果,调用时直接从缓存中获取路由结果。
- 如果用了参数路由,必须设为true,需要注意设置会影响调用的性能,可不填,缺省为flase。
- priority=1
- 路由规则的优先级,用于排序,优先级越大越靠前执行,可不填,缺省为0。
- rule=URL.encode("host = 10.20.153.10 => host = 10.20.153.11")
- 表示路由规则的内容,必填。
条件路由规则
(#)
基于条件表达式的路由规则,如:
规则:
- "=>"之前的为消费者匹配条件,所有参数和消费者的URL进行对比,当消费者满足匹配条件时,对该消费者执行后面的过滤规则。
- "=>"之后为提供者地址列表的过滤条件,所有参数和提供者的URL进行对比,消费者最终只拿到过滤后的地址列表。
- 如果匹配条件为空,表示对所有消费方应用,如:=> host != 10.20.153.11
- 如果过滤条件为空,表示禁止访问,如:host = 10.20.153.10 =>
表达式:
- 参数支持:
- 服务调用信息,如:method,
argument等(暂不支持参数路由) - URL本身的字段,如:protocol, host, port 等
- 以及URL上的所有参数,如:application, organization 等
- 服务调用信息,如:method,
- 条件支持:
- 等号"="表示"匹配",如:host = 10.20.153.10
- 不等号"!="表示"不匹配",如:host != 10.20.153.10
- 值支持:
- 以逗号","分隔多个值,如:host != 10.20.153.10,10.20.153.11
- 以星号"*"结尾,表示通配,如:host != 10.20.*
- 以美元符"$"开头,表示引用消费者参数,如:host = $host
示例:
1. 排除预发布机:
2. 白名单:(注意:一个服务只能有一条白名单规则,否则两条规则交叉,就都被筛选掉了)
3. 黑名单:
4. 服务寄宿在应用上,只暴露一部分的机器,防止整个集群挂掉:
5. 为重要应用提供额外的机器:
6. 读写分离:
7. 前后台分离:
8. 隔离不同机房网段:
9. 提供者与消费者部署在同集群内,本机只访问本机的服务:
脚本路由规则
(#)
支持JDK脚本引擎的所有脚本,比如:javascript,jruby,groovy等,通过type=javascript参数设置脚本类型,缺省为javascript。 |
脚本没有沙箱约束,可执行任意代码,存在后门风险 |
基于脚本引擎的路由规则,如:
配置规则
2.2.0以上版本支持 |
向注册中心写入动态配置覆盖规则:(通常由监控中心或治理中心的页面完成)
其中:
- override://
- 表示数据采用覆盖方式,支持override和absent,可扩展,必填。
- 0.0.0.0
- 表示对所有IP地址生效,如果只想覆盖某个IP的数据,请填入具体IP,必填。
- com.foo.BarService
- 表示只对指定服务生效,必填。
- category=configurators
- 表示该数据为动态配置类型,必填。
- dynamic=false
- 表示该数据为持久数据,当注册方退出时,数据依然保存在注册中心,必填。
- enabled=true
- 覆盖规则是否生效,可不填,缺省生效。
- application=foo
- 表示只对指定应用生效,可不填,表示对所有应用生效。
- timeout=1000
- 表示将满足以上条件的timeout参数的值覆盖为1000。
- 如果想覆盖其它参数,直接加在override的URL参数上。
示例:
1. 禁用提供者:(通常用于临时踢除某台提供者机器,相似的,禁止消费者访问请使用路由规则)
2. 调整权重:(通常用于容量评估,缺省权重为100)
3. 调整负载均衡策略:(缺省负载均衡策略为random)
4. 服务降级:(通常用于临时屏蔽某个出错的非关键服务)
服务降级
2.2.0以上版本支持 |
参见:配置规则 |
向注册中心写入动态配置覆盖规则:(通过由监控中心或治理中心的页面完成)
其中:
- 表示消费方对该服务的方法调用都直接返回null值,不发起远程调用。
- 屏蔽不重要服务不可用时对调用方的影响。
还可以改为:
- 表示消费方对该服务的方法调用在失败后,再返回null值,不抛异常。
- 容忍不重要服务不稳定时对调用方的影响。
优雅停机
Dubbo是通过JDK的ShutdownHook来完成优雅停机的,所以如果用户使用"kill -9 PID"等强制关闭指令,是不会执行优雅停机的,只有通过"kill PID"时,才会执行。 |
原理:
- 服务提供方
- 停止时,先标记为不接收新请求,新请求过来时直接报错,让客户端重试其它机器。
- 然后,检测线程池中的线程是否正在运行,如果有,等待所有线程执行完成,除非超时,则强制关闭。
- 服务消费方
- 停止时,不再发起新的调用请求,所有新的调用在客户端即报错。
- 然后,检测有没有请求的响应还没有返回,等待响应返回,除非超时,则强制关闭。
设置优雅停机超时时间,缺省超时时间是10秒:(超时则强制关闭)
如果ShutdownHook不能生效,可以自行调用:
主机绑定
缺省主机IP查找顺序:
- 通过LocalHost.getLocalHost()获取本机地址。
- 如果是127.*等loopback地址,则扫描各网卡,获取网卡IP。
注册的地址如果获取不正确,比如需要注册公网地址,可以:
1. 可以在/etc/hosts中加入:机器名 公网IP,比如:
2. 在dubbo.xml中加入主机地址的配置:
3. 或在dubbo.properties中加入主机地址的配置:
缺省主机端口与协议相关:
- dubbo: 20880
- rmi: 1099
- http: 80
- hessian: 80
- webservice: 80
- memcached: 11211
- redis: 6379
主机端口配置:
1. 在dubbo.xml中加入主机地址的配置:
3. 或在dubbo.properties中加入主机地址的配置:
日志适配
2.2.1以上版本支持 |
扩展点:日志适配扩展 |
缺省自动查找:
- log4j
- slf4j
- jcl
- jdk
可以通过以下方式配置日志输出策略:
访问日志
如果你想记录每一次请求信息,可开启访问日志,类似于apache的访问日志。 |
此日志量比较大,请注意磁盘容量。 |
将访问日志输出到当前应用的log4j日志:
将访问日志输出到指定文件:
服务容器
服务容器是一个standalone的启动程序,因为后台服务不需要Tomcat或JBoss等Web容器的功能,如果硬要用Web容器去加载服务提供方,增加复杂性,也浪费资源。 |
服务容器只是一个简单的Main方法,并加载一个简单的Spring容器,用于暴露服务。 |
服务容器的加载内容可以扩展,内置了spring, jetty, log4j等加载,可通过Container扩展点进行扩展,参见:Container |
Spring Container
- 自动加载META-INF/spring目录下的所有Spring配置。
- 配置:(配在java命令-D参数或者dubbo.properties中)
- dubbo.spring.config=classpath*:META-INF/spring/*.xml ----配置spring配置加载位置
Jetty Container
- 启动一个内嵌Jetty,用于汇报状态。
- 配置:(配在java命令-D参数或者dubbo.properties中)
- dubbo.jetty.port=8080 ----配置jetty启动端口
- dubbo.jetty.directory=/foo/bar ----配置可通过jetty直接访问的目录,用于存放静态文件
- dubbo.jetty.page=log,status,system ----配置显示的页面,缺省加载所有页面
Log4j Container
- 自动配置log4j的配置,在多进程启动时,自动给日志文件按进程分目录。
- 配置:(配在java命令-D参数或者dubbo.properties中)
- dubbo.log4j.file=/foo/bar.log ----配置日志文件路径
- dubbo.log4j.level=WARN ----配置日志级别
- dubbo.log4j.subdirectory=20880 ----配置日志子目录,用于多进程启动,避免冲突
容器启动
如:(缺省只加载spring)
或:(通过main函数参数传入要加载的容器)
或:(通过JVM启动参数传入要加载的容器)
或:(通过classpath下的dubbo.properties配置传入要加载的容器)
Reference Config缓存
ReferenceConfig实例很重,封装了与注册中心的连接以及与提供者的连接,需要缓存,否则重复生成ReferenceConfig可能造成性能问题并且会有内存和连接泄漏。API方式编程时,容易忽略此问题。
Dubbo 2.4.0+版本,提供了简单的工具类ReferenceConfigCache用于缓存ReferenceConfig实例。
使用方式如下:
消除Cache中的ReferenceConfig,销毁ReferenceConfig并释放对应的资源。
缺省ReferenceConfigCache把相同服务Group、接口、版本的ReferenceConfig认为是相同,缓存一份。即以服务Group、接口、版本为缓存的Key。
可以修改这个策略,在ReferenceConfigCache.getCache时,传一个KeyGenerator。详见ReferenceConfigCache类的方法。
分布式事务
基于JTA/XA规范实现。 |
暂未实现。 |
两阶段提交:
3 Comments
comments.show.hide六月 16, 2012
Anonymous
CKLYbQ , [url=http://xbihszonlvjv.com/]xbihszonlvjv[/url], [link=http://amggqmhiazqr.com/]amggqmhiazqr[/link], http://vdnsxkmlbkky.com/
六月 16, 2012
Anonymous
T3Zpst <a href="http://ubawagrzuvox.com/">ubawagrzuvox</a>
六月 17, 2012
Anonymous
7bk6Jr , [url=http://cqiywofafcsf.com/]cqiywofafcsf[/url], [link=http://ycifsmttwnvp.com/]ycifsmttwnvp[/link], http://wmuudfswqdgb.com/
Anonymous replies:
Help Tips
*bold*
bold_italic_
italich1.
Large headingh5.
Small heading*
Bulleted point#
Numbered point