Category Archives: dubbo

dubbo输入参数的校验

dubbo的rest支持采用Java标准的bean validation annotation（JSR 303)来做输入校验http://beanvalidation.org/ 为了和其他dubbo远程调用协议保持一致，在rest中作校验的annotation必须放在服务的接口上，例如： 当然，在很多其他的bean validation的应用场景都是将annotation放到实现类而不是接口上。把annotation放在接口上至少有一个好处是，dubbo的客户端可以共享这个接口的信息，dubbo甚至不需要做远程调用，在本地就可以完成输入校验。 然后按照dubbo的标准方式在XML配置中打开验证：

不要使用 dubbo.properties 文件配置，推荐使用对应 XML 配置

Dubbo 中所有的配置项都可以配置在 Spring 配置文件中，并且可以针对单个服务配置。 如完全不配置则使用 Dubbo 缺省值，详情请参考 Dubbo配置参考手册 中的说明。 dubbo.properties 中属性名与 XML 的对应关系 应用名 dubbo.application.name<dubbo:application name=”myalibaba” > 注册中心地址 dubbo.registry.address<dubbo:registry address=”11.22.33.44:9090″ > 调用超时 dubbo.service.*.timeout可以在多个配置项设置超时 timeout，由上至下覆盖（即上面的优先）5，其它的参数（retries、loadbalance、actives等）的覆盖策略与 timeout 相同。示例如下：提供者端特定方法的配置<dubbo:service interface=”com.alibaba.xxx.XxxService” > <dubbo:method name=”findPerson” timeout=”1000″ /> </dubbo:service> 提供者端特定接口的配置<dubbo:service interface=”com.alibaba.xxx.XxxService” timeout=”200″ /> 服务提供者协议 dubbo.service.protocol、服务的监听端口 dubbo.service.server.port<dubbo:protocol name=”dubbo” port=”20880″ /> 服务线程池大小 dubbo.service.max.thread.threads.size<dubbo:protocol threads=”100″ /> 消费者启动时，没有提供者是否抛异常 alibaba.intl.commons.dubbo.service.allow.no.provider<dubbo:reference interface=”com.alibaba.xxx.XxxService” check=”false” />

dubbo监控配置推荐

使用固定端口暴露服务，而不要使用随机端口这样在注册中心推送有延迟的情况下，消费者通过缓存列表也能调用到原地址，保证调用成功。 使用 Dubbo Admin 监控注册中心上的服务提供方使用 Dubbo Admin 监控服务在注册中心上的状态，确保注册中心上有该服务的存在。 服务提供方可使用 Dubbo Qos 的 telnet 或 shell 监控项监控服务提供者端口状态：echo status | nc -i 1 20880 | grep OK | wc -l，其中的 20880 为服务端口 服务消费方可通过将服务强制转型为 EchoService，并调用 $echo() 测试该服务的提供者是可用如 assertEqauls(“OK”, ((EchoService)memberService).$echo(“OK”));

dubbo序列化选择建议

其中，Kryo是一种非常成熟的序列化实现，已经在Twitter、Groupon、Yahoo以及多个著名开源项目（如Hive、Storm）中广泛的使用。而FST是一种较新的序列化实现，目前还缺乏足够多的成熟使用案例，但我认为它还是非常有前途的。 在面向生产环境的应用中，我建议目前更优先选择Kryo。 启用Kryo 使用Kryo非常简单，只需要在dubbo RPC的XML配置中添加一个属性即可：

Dubbo的服务容器

如果dubbo只是提供dubbo协议服务，不用加载tomcat，jetty等好用资源 服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。 服务容器的加载内容可以扩展，内置了 spring, jetty, log4j 等加载，可通过容器扩展点进行扩展。配置配在 java 命令的 -D 参数或者 dubbo.properties 中。 容器类型 Spring Container 自动加载 META-INF/spring 目录下的所有 Spring 配置。 配置 spring 配置加载位置：dubbo.spring.config=classpath*:META-INF/spring/*.xml Jetty Container 启动一个内嵌 Jetty，用于汇报状态。 配置： dubbo.jetty.port=8080：配置 jetty 启动端口 dubbo.jetty.directory=/foo/bar：配置可通过 jetty 直接访问的目录，用于存放静态文件 dubbo.jetty.page=log,status,system：配置显示的页面，缺省加载所有页面 Log4j Container 自动配置 log4j 的配置，在多进程启动时，自动给日志文件按进程分目录。 配置： dubbo.log4j.file=/foo/bar.log：配置日志文件路径 dubbo.log4j.level=WARN：配置日志级别 dubbo.log4j.subdirectory=20880：配置日志子目录，用于多进程启动，避免冲突 容器启动 缺省只加载 spring 通过 main 函数参数传入要加载的容器 通过 JVM 启动参数传入要加载的容器 通过 […]

dubbo多版本

在 Dubbo 中为同一个服务配置多个版本 当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。 可以按照以下的步骤进行版本迁移： 在低压力时间段，先升级一半提供者为新版本 再将所有消费者升级为新版本 然后将剩下的一半提供者升级为新版本 老版本服务提供者配置： 新版本服务提供者配置： 老版本服务消费者配置： 新版本服务消费者配置： 如果不需要区分版本，可以按照以下的方式配置 [^1]：