用户文档 on Apache Dubbo

快速开始

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo 的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。

如果不想使用 Spring 配置，可以通过 API 的方式进行调用。

服务提供者

完整安装步骤，请参见：示例提供者安装

定义服务接口

DemoService.java ¹：

package org.apache.dubbo.demo;

public interface DemoService {
 String sayHello(String name);
}

在服务提供方实现接口

DemoServiceImpl.java ²：


package org.apache.dubbo.demo.provider;
 
import org.apache.dubbo.demo.DemoService;
 
public class DemoServiceImpl implements DemoService {
 public String sayHello(String name) {
 return "Hello " + name;
 }
}

用 Spring 配置声明暴露服务

provider.xml：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
 
 <!-- 提供方应用信息，用于计算依赖关系 -->
 <dubbo:application name="hello-world-app" />
 
 <!-- 使用multicast广播注册中心暴露服务地址 -->
 <dubbo:registry address="multicast://224.5.6.7:1234" />
 
 <!-- 用dubbo协议在20880端口暴露服务 -->
 <dubbo:protocol name="dubbo" port="20880" />
 
 <!-- 声明需要暴露的服务接口 -->
 <dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" />
 
 <!-- 和本地bean一样实现服务 -->
 <bean id="demoService" class="org.apache.dubbo.demo.provider.DemoServiceImpl" />
</beans>

加载 Spring 配置

Provider.java：

基本依赖

Mon, 01 Jan 0001 00:00:00 +0000

必须依赖

JDK 1.6+ ¹

缺省依赖

通过 mvn dependency:tree > dep.log 命令分析，Dubbo 缺省依赖以下三方库：

[INFO] +- com.alibaba:dubbo:jar:2.5.9-SNAPSHOT:compile
[INFO] | +- org.springframework:spring-context:jar:4.3.10.RELEASE:compile
[INFO] | +- org.javassist:javassist:jar:3.21.0-GA:compile
[INFO] | \- org.jboss.netty:netty:jar:3.2.5.Final:compile

这里所有依赖都是按照 Dubbo 缺省配置选的，这些缺省值是基于稳定性和性能考虑的。

javassist.jar ²: 如果 <dubbo:provider proxy="jdk" /> 或 <dubbo:consumer proxy="jdk" />，以及 <dubbo:application compiler="jdk" />，则不需要。
spring-context.jar ³: 如果用 ServiceConfig 和 ReferenceConfig 的 API 调用，则不需要。
netty.jar ⁴: 如果 <dubbo:protocol server="mina"/> 或 <dubbo:protocol server="grizzly"/>，则换成 mina.jar 或 grizzly.jar。如果 <protocol name="rmi"/>，则不需要。

可选依赖

以下依赖，在主动配置使用相应实现策略时用到，需自行加入依赖。

netty-all 4.0.35.Final
mina: 1.1.7
grizzly: 2.1.4
httpclient: 4.5.3
hessian_lite: 3.2.1-fixed
fastjson: 1.2.31
zookeeper: 3.4.9
jedis: 2.9.0
xmemcached: 1.3.6
hessian: 4.0.38
jetty: 6.1.26
hibernate-validator: 5.4.1.Final
zkclient: 0.2
curator: 2.12.0
cxf: 3.0.14
thrift: 0.8.0
servlet: 3.0 ⁵
validation-api: 1.1.0.GA ⁵
jcache: 1.0.0 ⁵
javax.el: 3.0.1-b08 ⁵
kryo: 4.0.1
kryo-serializers: 0.42
fst: 2.48-jdk-6
resteasy: 3.0.19.Final
tomcat-embed-core: 8.0.11
slf4j: 1.7.25
log4j: 1.2.16

理论上 Dubbo 可以只依赖 JDK，不依赖于任何三方库运行，只需配置使用 JDK 相关实现策略 ↩︎

成熟度

Mon, 01 Jan 0001 00:00:00 +0000

功能成熟度

Feature	Maturity	Strength	Problem	Advise	User
并发控制	Tested	并发控制		试用
连接控制	Tested	连接数控制		试用
直连提供者	Tested	点对点直连服务提供方，用于测试		测试环境使用	Alibaba
分组聚合	Tested	分组聚合返回值，用于菜单聚合等服务	特殊场景使用	可用于生产环境
参数验证	Tested	参数验证，JSR303验证框架集成	对性能有影响	试用	LaiWang
结果缓存	Tested	结果缓存，用于加速请求		试用
泛化引用	Stable	泛化调用，无需业务接口类进行远程调用，用于测试平台，开放网关桥接等		可用于生产环境	Alibaba
泛化实现	Stable	泛化实现，无需业务接口类实现任意接口，用于Mock平台		可用于生产环境	Alibaba
回声测试	Tested	回声测试		试用
隐式传参	Stable	附加参数		可用于生产环境
异步调用	Tested	不可靠异步调用		试用
本地调用	Tested	本地调用		试用
参数回调	Tested	参数回调	特殊场景使用	试用	Registry
事件通知	Tested	事件通知，在远程调用执行前后触发		试用
本地存根	Stable	在客户端执行部分逻辑		可用于生产环境	Alibaba
本地伪装	Stable	伪造返回结果，可在失败时执行，或直接执行，用于服务降级	需注册中心支持	可用于生产环境	Alibaba
延迟暴露	Stable	延迟暴露服务，用于等待应用加载warmup数据，或等待spring加载完成		可用于生产环境	Alibaba
延迟连接	Tested	延迟建立连接，调用时建立		试用	Registry
粘滞连接	Tested	粘滞连接，总是向同一个提供方发起请求，除非此提供方挂掉，再切换到另一台		试用	Registry
令牌验证	Tested	令牌验证，用于服务授权	需注册中心支持	试用
路由规则	Tested	动态决定调用关系	需注册中心支持	试用
配置规则	Tested	动态下发配置，实现功能的开关	需注册中心支持	试用
访问日志	Tested	访问日志，用于记录调用信息	本地存储，影响性能，受磁盘大小限制	试用
分布式事务	Research	JTA/XA三阶段提交事务	不稳定	不可用

策略成熟度

Feature	Maturity	Strength	Problem	Advise
Zookeeper注册中心	Stable	支持基于网络的集群方式，有广泛周边开源产品，建议使用dubbo-2.3.3以上版本（推荐使用）	依赖于Zookeeper的稳定性	可用于生产环境
Redis注册中心	Stable	支持基于客户端双写的集群方式，性能高	要求服务器时间同步，用于检查心跳过期脏数据	可用于生产环境
Multicast注册中心	Tested	去中心化，不需要安装注册中心	依赖于网络拓扑和路由，跨机房有风险	小规模应用或开发测试环境
Simple注册中心	Tested	Dogfooding，注册中心本身也是一个标准的RPC服务	没有集群支持，可能单点故障	试用

Feature	Maturity	Strength	Problem	Advise	User
Simple监控中心	Stable	支持JFreeChart统计报表	没有集群支持，可能单点故障，但故障后不影响RPC运行	可用于生产环境

Feature	Maturity	Strength	Problem	Advise	User
Dubbo协议	Stable	采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用）	在大文件传输时，单一连接会成为瓶颈	可用于生产环境	Alibaba
Rmi协议	Stable	可与原生RMI互操作，基于TCP协议	偶尔会连接失败，需重建Stub	可用于生产环境	Alibaba
Hessian协议	Stable	可与原生Hessian互操作，基于HTTP协议	需hessian.jar支持，http短连接的开销大	可用于生产环境

Feature	Maturity	Strength	Problem	Advise	User
Netty Transporter	Stable	JBoss的NIO框架，性能较好（推荐使用）	一次请求派发两种事件，需屏蔽无用事件	可用于生产环境	Alibaba
Mina Transporter	Stable	老牌NIO框架，稳定	待发送消息队列派发不及时，大压力下，会出现FullGC	可用于生产环境	Alibaba
Grizzly Transporter	Tested	Sun的NIO框架，应用于GlassFish服务器中	线程池不可扩展，Filter不能拦截下一Filter	试用

Feature	Maturity	Strength	Problem	Advise	User
Hessian Serialization	Stable	性能较好，多语言支持（推荐使用）	Hessian的各版本兼容性不好，可能和应用使用的Hessian冲突，Dubbo内嵌了hessian3.2.1的源码	可用于生产环境	Alibaba
Dubbo Serialization	Tested	通过不传送POJO的类元信息，在大量POJO传输时，性能较好	当参数对象增加字段时，需外部文件声明	试用
Json Serialization	Tested	纯文本，可跨语言解析，缺省采用FastJson解析	性能较差	试用
Java Serialization	Stable	Java原生支持	性能较差	可用于生产环境

Feature	Maturity	Strength	Problem	Advise	User
Javassist ProxyFactory	Stable	通过字节码生成代替反射，性能比较好（推荐使用）	依赖于javassist.jar包，占用JVM的Perm内存，Perm可能要设大一些：java -XX:PermSize=128m	可用于生产环境	Alibaba
Jdk ProxyFactory	Stable	JDK原生支持	性能较差	可用于生产环境

Feature	Maturity	Strength	Problem	Advise	User
Failover Cluster	Stable	失败自动切换，当出现失败，重试其它服务器，通常用于读操作（推荐使用）	重试会带来更长延迟	可用于生产环境	Alibaba
Failfast Cluster	Stable	快速失败，只发起一次调用，失败立即报错,通常用于非幂等性的写操作	如果有机器正在重启，可能会出现调用失败	可用于生产环境	Alibaba
Failsafe Cluster	Stable	失败安全，出现异常时，直接忽略，通常用于写入审计日志等操作	调用信息丢失	可用于生产环境	Monitor
Failback Cluster	Tested	失败自动恢复，后台记录失败请求，定时重发，通常用于消息通知操作	不可靠，重启丢失	可用于生产环境	Registry
Forking Cluster	Tested	并行调用多个服务器，只要一个成功即返回，通常用于实时性要求较高的读操作	需要浪费更多服务资源	可用于生产环境
Broadcast Cluster	Tested	广播调用所有提供者，逐个调用，任意一台报错则报错，通常用于更新提供方本地状态	速度慢，任意一台报错则报错	可用于生产环境

Feature	Maturity	Strength	Problem	Advise	User
Random LoadBalance	Stable	随机，按权重设置随机概率（推荐使用）	在一个截面上碰撞的概率高，重试时，可能出现瞬间压力不均	可用于生产环境	Alibaba
RoundRobin LoadBalance	Stable	轮询，按公约后的权重设置轮询比率	存在慢的机器累积请求问题，极端情况可能产生雪崩	可用于生产环境
LeastActive LoadBalance	Stable	最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差，使慢的机器收到更少请求	不支持权重，在容量规划时，不能通过权重把压力导向一台机器压测容量	可用于生产环境
ConsistentHash LoadBalance	Stable	一致性Hash，相同参数的请求总是发到同一提供者，当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动	压力分摊不均	可用于生产环境

Feature	Maturity	Strength	Problem	Advise	User
条件路由规则	Stable	基于条件表达式的路由规则，功能简单易用	有些复杂多分支条件情况，规则很难描述	可用于生产环境	Alibaba
脚本路由规则	Tested	基于脚本引擎的路由规则，功能强大	没有运行沙箱，脚本能力过于强大，可能成为后门	试用

Feature	Maturity	Strength	Problem	Advise	User
Spring Container	Stable	自动加载META-INF/spring目录下的所有Spring配置		可用于生产环境	Alibaba
Jetty Container	Stable	启动一个内嵌Jetty，用于汇报状态	大量访问页面时，会影响服务器的线程和内存	可用于生产环境	Alibaba
Log4j Container	Stable	自动配置log4j的配置，在多进程启动时，自动给日志文件按进程分目录	用户不能控制log4j的配置，不灵活	可用于生产环境	Alibaba

服务化最佳实践

Mon, 01 Jan 0001 00:00:00 +0000

分包

建议将服务接口、服务模型、服务异常等均放在 API 包中，因为服务模型和异常也是 API 的一部分，这样做也符合分包原则：重用发布等价原则(REP)，共同重用原则(CRP)。

如果需要，也可以考虑在 API 包中放置一份 Spring 的引用配置，这样使用方只需在 Spring 加载过程中引用此配置即可。配置建议放在模块的包目录下，以免冲突，如：com/alibaba/china/xxx/dubbo-reference.xml。

粒度

服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo 暂未提供分布式事务支持。

服务接口建议以业务场景为单位划分，并对相近业务做抽象，防止接口数量爆炸。

不建议使用过于抽象的通用接口，如：Map query(Map)，这样的接口没有明确语义，会给后期维护带来不便。

版本

每个接口都应定义版本号，为后续不兼容升级提供可能，如： <dubbo:service interface="com.xxx.XxxService" version="1.0" />。

建议使用两位版本号，因为第三位版本号通常表示兼容升级，只有不兼容时才需要变更服务版本。

当不兼容时，先升级一半提供者为新版本，再将消费者全部升为新版本，然后将剩下的一半提供者升为新版本。

兼容性

服务接口增加方法，或服务模型增加字段，可向后兼容，删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需通过变更版本号升级。

各协议的兼容性不同，参见：服务协议

枚举值

如果是完备集，可以用 Enum，比如：ENABLE, DISABLE。

如果是业务种类，以后明显会有类型增加，不建议用 Enum，可以用 String 代替。

如果是在返回值中用了 Enum，并新增了 Enum 值，建议先升级服务消费方，这样服务提供方不会返回新值。

如果是在传入参数中用了 Enum，并新增了 Enum 值，建议先升级服务提供方，这样服务消费方不会传入新值。

序列化

服务参数及返回值建议使用 POJO 对象，即通过 setter, getter 方法表示属性的对象。

服务参数及返回值不建议使用接口，因为数据模型抽象的意义不大，并且序列化需要接口实现类的元信息，并不能起到隐藏实现的意图。

服务参数及返回值都必须是传值调用，而不能是传引用调用，消费方和提供方的参数或返回值引用并不是同一个，只是值相同，Dubbo 不支持引用远程对象。

异常

建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，并且语义更友好。

如果担心性能问题，在必要时，可以通过 override 掉异常类的 fillInStackTrace() 方法为空方法，使其不拷贝栈信息。

查询方法不建议抛出 checked 异常，否则调用方在查询时将过多的 try...catch，并且不能进行有效处理。

服务提供方不应将 DAO 或 SQL 等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常。

容量规划

Mon, 01 Jan 0001 00:00:00 +0000

以下数据供参考：

使用 Dubbo 的会员服务项目

每天接收 4 亿次远程调用
使用 12 台网站标配机器提供服务（8 核 CPU，8G 内存）
平均负载在 1 以下（对于 8 核 CPU 负载很低）
平均响应时间 2.3 到 2.5 毫秒，网络开销约占 1.5 到 1.6 毫秒（和数据包大小有关）

使用 Dubbo 的产品授权服务项目

每天接收 3 亿次远程调用
使用 8 台网站标配机器提供服务（8 核CPU，8G 内存）
平均负载在 1 以下（对于 8 核 CPU 负载很低）
平均响应时间 1.4 到 2.8 毫秒，网络开销约占 1.0 到 1.1 毫秒（和数据包大小有关）

性能测试报告

Mon, 01 Jan 0001 00:00:00 +0000

测试说明

本次性能测试，测试了 dubbo 2.0 所有支持的协议在不同大小和数据类型下的表现，并与 dubbo 1.0 进行了对比。
整体性能相比 1.0 有了提升，平均提升 10%，使用 dubbo 2.0 新增的 dubbo 序列化还能获得 10%~50% 的性能提升，详见下面的性能数据。
稳定性测试中由于将底层通信框架从 mina 换成 netty，old 区对象的增长大大减少，50 小时运行，增长不到 200m，无 fullgc。
存在的问题：在 50k 数据的时候 2.0 性能不如 1.0，怀疑可能是缓冲区设置的问题，下版本会进一步确认。

测试环境

硬件部署与参数调整

机型	CPU	内存	网络	磁盘	内核
Tecal BH620	model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz cache size : 8192 KB processor_count : 16	Total System Memory: 6G Hardware Memory Info: Size: 4096MB	eth0: Link is up at 1000 Mbps, full duplex. peth0: Link is up at 1000 Mbps, full duplex.	/dev/sda: 597.9 GB	2.6.18-128.el5xen x86_64

软件架构

软件名称及版本	关键参数
java version “1.6.0_18” Java(TM) SE Runtime Environment (build 1.6.0_18-b07) Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode)	-server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70
jboss-4.0.5.GA
httpd-2.0.61	KeepAlive On MaxKeepAliveRequests 100000 KeepAliveTimeout 180 MaxRequestsPerChild 1000000 StartServers 5 MaxClients 1024 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 64 ThreadLimit 128 ServerLimit 16

测试目的

期望性能指标(量化)

场景名称	对应指标名称	期望值范围	实际值	是否满足期望(是/否)
1k数据	响应时间	0.9ms	0.79ms	是
1k数据	TPS	10000	11994	是

期望运行状况(非量化，可选)

2.0 性能不低于 1.0, 2.0 和 1.0 互调用的性能无明显下降。除了 50k string 其余皆通过
JVM 内存运行稳定，无 OOM，堆内存中无不合理的大对象的占用。通过
CPU、内存、网络、磁盘、文件句柄占用平稳。通过
无频繁线程锁，线程数平稳。通过
业务线程负载均衡。通过

测试脚本

性能测试场景（10 并发）

测试覆盖率报告

Mon, 01 Jan 0001 00:00:00 +0000

v2.0 Codecov报表 , 从 2017-12-29 后开始统计测试覆盖率为 : , 可以从 https://codecov.io/gh/apache/dubbo 页面得到覆盖率报表
v1.0 基于 2.0.12 版本，统计于 2012-02-03

基准测试工具包

Mon, 01 Jan 0001 00:00:00 +0000

下载源码： git clone https://github.com/apache/dubbo.git
编译benchmark: cd dubbo/dubbo-test/dubbo-test-benchmark; mvn clean install
解压 benchmark压缩包： dubbo/dubbo-test/dubbo-test-benchmark/target/dubbo-test-benchmark-2.6.2-SNAPSHOT.tar.gz

阅读ReadMe.txt（内容如下，请以压缩包内的为准）

新建一个benchmark工程，如demo.benchmark
导入自己服务的接口api包和dubbo.benchmark.jar(解压dubbo.benchmark.tar.gz，在lib目录下)

新建一个类，实现AbstractClientRunnable

实现父类的构造函数
实现invoke方法，通过serviceFactory创建本地接口代理，并实现自己的业务逻辑，如下

public Object invoke(ServiceFactory serviceFactory) {
 DemoService demoService = (DemoService) serviceFactory.get(DemoService.class);
 return demoService.sendRequest("hello");
}

将自己的benchmark工程打成jar包,如demo.benchmark.jar
将demo.benchmark.jar 和服务的api包放到dubbo.benchmark/lib目录下
配置dubbo.properties
运行run.bat(windows)或run.sh(linux)

如想测试dubbo的不同版本，直接替换lib下的dubbo的jar包即可。

开发 REST 应用

Mon, 01 Jan 0001 00:00:00 +0000

作者：沈理

文档版权：Apache 2.0许可证署名-禁止演绎

本文篇幅较长，因为REST本身涉及面较多。另外，本文参照 Spring 等的文档风格，不仅仅局限于框架用法的阐述，同时也努力呈现框架的设计理念和优良应用的架构思想。对于想粗略了解 dubbo 和 REST 的人，只需浏览概述至标准Java REST API：JAX-RS简介几节即可。

概述
REST的优点
应用场景
快速入门
标准Java REST API：JAX-RS简介
REST服务提供端详解
- HTTP POST/GET的实现
- Annotation放在接口类还是实现类
- JSON、XML等多数据格式的支持
- 中文字符支持
- XML数据格式的额外要求
- 定制序列化
- 配置REST Server的实现
- 获取上下文（Context）信息
- 配置端口号和Context Path
- 配置线程数和IO线程数
- 配置长连接
- 配置最大的HTTP连接数
- 配置每个消费端的超时时间和HTTP连接数
- GZIP数据压缩
- 用Annotation取代部分Spring XML配置
- 添加自定义的Filter、Interceptor等
- 添加自定义的Exception处理
- 配置HTTP日志输出
- 输入参数的校验
- 是否应该透明发布REST服务
- Dubbo的REST提供端在被调用时使用header
REST服务消费端详解
- 场景1：非dubbo的消费端调用dubbo的REST服务
- 场景2：dubbo消费端调用dubbo的REST服务
- 场景3：dubbo的消费端调用非dubbo的REST服务
- Dubbo的消费端在调用REST服务时配置自定义header
Dubbo中JAX-RS的限制
REST常见问题解答（REST FAQ）
- Dubbo REST的服务能和Dubbo注册中心、监控中心集成吗？
- Dubbo REST中如何实现负载均衡和容错（failover）？
- JAX-RS中重载的方法能够映射到同一URL地址吗？
- JAX-RS中作POST的方法能够接收多个参数吗？
Dubbo当前体系可能的不足之处（与REST相关的）
- RpcContext的侵入性
- Protocol配置的局限性
- XML命名不符合spring规范
REST最佳实践
性能基准测试
- 测试环境
- 测试脚本
- 测试结果
扩展讨论
- REST与Thrift、Protobuf等的对比
- REST与传统WebServices的对比
- JAX-RS与Spring MVC的对比
未来

概述

dubbo支持多种远程调用方式，例如dubbo RPC（二进制序列化 + tcp协议）、http invoker（二进制序列化 + http协议，至少在开源版本没发现对文本序列化的支持）、hessian（二进制序列化 + http协议）、WebServices （文本序列化 + http协议）等等，但缺乏对当今特别流行的REST风格远程调用（文本序列化 + http协议）的支持。

简单监控

Mon, 01 Jan 0001 00:00:00 +0000

Warning

监控中心也是一个标准的 Dubbo 服务，可以通过注册中心发现，也可以直连。

暴露一个简单监控中心服务到注册中心: (如果是用安装包，不需要自己写这个配置，如果是自己实现监控中心，则需要)

<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

 <!-- 当前应用信息配置 -->
 <dubbo:application name="simple-monitor" />

 <!-- 连接注册中心配置 -->
 <dubbo:registry address="127.0.0.1:9090" />

 <!-- 暴露服务协议配置 -->
 <dubbo:protocol port="7070" />

 <!-- 暴露服务配置 -->
 <dubbo:service interface="org.apache.dubbo.monitor.MonitorService" ref="monitorService" />

 <bean id="monitorService" class="org.apache.dubbo.monitor.simple.SimpleMonitorService" />
</beans>

通过注册中心发现监控中心服务:
```
<dubbo:monitor protocol="registry" />
```
或者在 dubbo.properties 配置：
```
dubbo.monitor.protocol=registry
```

暴露一个简单监控中心服务，但不注册到注册中心: (如果是用安装包，不需要自己写这个配置，如果是自己实现监控中心，则需要)

<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.3.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

 <!-- 当前应用信息配置 -->
 <dubbo:application name="simple-monitor" />

 <!-- 暴露服务协议配置 -->
 <dubbo:protocol port="7070" />

 <!-- 暴露服务配置 -->
 <dubbo:service interface="org.apache.dubbo.monitor.MonitorService" ref="monitorService" registry="N/A" />

 <bean id="monitorService" class="org.apache.dubbo.monitor.simple.SimpleMonitorService" /> 
</beans>

直连监控中心服务

Kryo 和 FST 序列化

Mon, 01 Jan 0001 00:00:00 +0000

序列化漫谈

dubbo RPC是dubbo体系中最核心的一种高性能、高吞吐量的远程调用方式，我喜欢称之为多路复用的TCP长连接调用，简单的说：

长连接：避免了每次调用新建TCP连接，提高了调用的响应速度
多路复用：单个TCP连接可交替传输多个请求和响应的消息，降低了连接的等待闲置时间，从而减少了同样并发数下的网络连接数，提高了系统吞吐量。

dubbo RPC主要用于两个dubbo系统之间作远程调用，特别适合高并发、小数据的互联网场景。

而序列化对于远程调用的响应速度、吞吐量、网络带宽消耗等同样也起着至关重要的作用，是我们提升分布式系统性能的最关键因素之一。

在dubbo RPC中，同时支持多种序列化方式，例如：

dubbo序列化：阿里尚未开发成熟的高效java序列化实现，阿里不建议在生产环境使用它
hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2序列化，而是阿里修改过的hessian lite，它是dubbo RPC默认启用的序列化方式
json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。
java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。

在通常情况下，这四种主要序列化方式的性能从上到下依次递减。对于dubbo RPC这种追求高性能的远程调用方式来说，实际上只有1、2两种高效序列化方式比较般配，而第1个dubbo序列化由于还不成熟，所以实际只剩下2可用，所以dubbo RPC默认采用hessian2序列化。

但hessian是一个比较老的序列化实现了，而且它是跨语言的，所以不是单独针对java进行优化的。而dubbo RPC实际上完全是一种Java to Java的远程调用，其实没有必要采用跨语言的序列化方式（当然肯定也不排斥跨语言的序列化）。

最近几年，各种新的高效序列化方式层出不穷，不断刷新序列化性能的上限，最典型的包括：

专门针对Java语言的：Kryo，FST等等
跨语言的：Protostuff，ProtoBuf，Thrift，Avro，MsgPack等等

这些序列化方式的性能多数都显著优于hessian2（甚至包括尚未成熟的dubbo序列化）。

有鉴于此，我们为dubbo引入Kryo和FST这两种高效Java序列化实现，来逐步取代hessian2。

其中，Kryo是一种非常成熟的序列化实现，已经在Twitter、Groupon、Yahoo以及多个著名开源项目（如Hive、Storm）中广泛的使用。而FST是一种较新的序列化实现，目前还缺乏足够多的成熟使用案例，但我认为它还是非常有前途的。

在面向生产环境的应用中，我建议目前更优先选择Kryo。

启用Kryo和FST

使用Kryo和FST非常简单，只需要在dubbo RPC的XML配置中添加一个属性即可：

<dubbo:protocol name="dubbo" serialization="kryo"/>

<dubbo:protocol name="dubbo" serialization="fst"/>

注册被序列化类

要让Kryo和FST完全发挥出高性能，最好将那些需要被序列化的类注册到dubbo系统中，例如，我们可以实现如下回调接口：

public class SerializationOptimizerImpl implements SerializationOptimizer {

 public Collection<Class> getSerializableClasses() {
 List<Class> classes = new LinkedList<Class>();
 classes.add(BidRequest.class);
 classes.add(BidResponse.class);
 classes.add(Device.class);
 classes.add(Geo.class);
 classes.add(Impression.class);
 classes.add(SeatBid.class);
 return classes;
 }
}

然后在XML配置中添加：

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 版本发布及新特性速览

版本速览

Dubbo 社区目前主力维护的有 2.6.x 和 2.7.x 两大版本，其中，

2.6.x 主要以 bugfix 和少量 enhancements 为主，因此能完全保证稳定性
2.7.x 作为社区的主要开发版本，得到持续更新并增加了大量新 feature 和优化，同时也带来了一些稳定性挑战

2.7.x 版本

	版本	重要功能	升级建议
1	2.7.6	bugfix of 2.7.5 服务鉴权	推荐生产使用
2	2.7.5	服务自省 HTTP/2（gRPC） Protobuf TLS 性能优化 https://github.com/apache/dubbo/releases/tag/dubbo-2.7.5	不建议大规模生产使用
3	2.7.4.1	bugfixes and enhancements of 2.7.3	推荐生产使用
4	2.7.3	bigfixes of and enhancements of 2.7.2	推荐生产使用
5	2.7.2	bigfixes of and enhancements of 2.7.1	不建议大规模生产使用
6	2.7.1	bigfixes of and enhancements of 2.7.0	不建议大规模生产使用
7	2.7.0	异步编程模型 - 消费端/提供端异步服务治理规则增强简化的注册模型配置中心、元数据中心 package 重构 https://github.com/apache/dubbo/releases/tag/dubbo-2.7.0	beta 版本，2.6.x 重构后首个版本

2.6.x 及之前版本

	版本	重要功能	升级建议
1	2.6.x	bugfix	建议持续升级最新版本，所有版本生产可用
2	2.5.x	停止维护	建议升级最新 2.6.x 版本
3	2.4.x 及之前	停止维护	建议升级最新 2.6.x 版本

值得关注的新特性

Dubbo 云原生计划（敬请期待…）
Kubernetes Native Service Discovery（敬请期待…）
gRPC (HTTP/2) 协议
使用 Protobuf 定义 Dubbo 服务
TLS 安全传输
实例级服务发现
服务鉴权
性能优化
- 调用链路提升 30%
- 消费端线程模型
- 地址推送链路

用户文档 on Apache Dubbo

快速开始

服务提供者

定义服务接口

在服务提供方实现接口

用 Spring 配置声明暴露服务

加载 Spring 配置

基本依赖

必须依赖

缺省依赖

可选依赖

成熟度

功能成熟度

策略成熟度

服务化最佳实践

分包

粒度

版本

兼容性

枚举值

序列化

异常

推荐用法

在 Provider 端尽量多配置 Consumer 端属性

容量规划

使用 Dubbo 的会员服务项目

使用 Dubbo 的产品授权服务项目

性能测试报告

测试说明

测试环境

硬件部署与参数调整

软件架构

测试目的

期望性能指标(量化)

期望运行状况(非量化，可选)

测试脚本

测试覆盖率报告

基准测试工具包

开发 REST 应用

目录

概述

简单监控

Warning

Kryo 和 FST 序列化

目录

序列化漫谈

启用Kryo和FST

注册被序列化类

Dubbo 版本发布及新特性速览

版本速览

2.7.x 版本

2.6.x 及之前版本

值得关注的新特性

热门文章列表