dubbo架构
Provider： 暴露服务的提供方，可以通过jar或者容器的方式启动服务
Consumer：调用远程服务的服务消费方。
Registry： 服务注册中心和发现中心。
Monitor： 统计服务的调用次数、调用时间
Container：服务运行的容器。
Dubbo的网络传输协议
RPC通讯协议
Dubbo提供的序列化方式
- dubbo：Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
- rmi：RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式
- Hessian:Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现
- http:采用Spring的HttpInvoker实现
- Webservice:基于CXF的frontend-simple和transports-http实现
Dubbo的注册中心
默认是zk，其他还有Redis、Multicast、Simple 注册中心，但不推荐。
Dubbo有哪几种配置方式？
Spring 配置方式（XML文件）
Java API 配置方式（注解方式）
Dubbo的核心配置
- dubbo:service 服务配置（作为服务的提供者，暴露服务的配置）
- dubbo:reference 引用配置（需要调用外部服务）
- dubbo:protocol 协议配置（服务支持的协议配置，若需要支持多个协议，可以声明多个<dubbo:protocol>标签）
- dubbo:application 应用配置（应用信息配置，包括当前应用名、应用负责人、应用版本、应用环境等）
- dubbo:module 模块配置（模块信息配置，包括当前模块名、模块负责人、模块版本等）
- dubbo:registry 注册中心配置（同时如果有多个不同的注册中心，可以声明多个 <dubbo:registry> 标签，并在 <dubbo:service> 或 <dubbo:reference> 的 registry 属性指定使用的注册中心。）
- dubbo:monitor 监控中心配置（有protocol、address两个属性，当protocol="registry"，表示从注册中心发现监控中心地址，当address="10.20.130.230:12080"表示直连监控中心地址）
- dubbo:provider 提供方配置（服务提供者缺省值配置，该标签为 <dubbo:service> 和 <dubbo:protocol> 标签的缺省值设置。）
- dubbo:consumer 消费方配置（服务消费者缺省值配置，该标签为 <dubbo:reference> 标签的缺省值设置。）
- dubbo:method 方法配置（该标签为 <dubbo:service> 或 <dubbo:reference> 的子标签，用于控制到方法级。）
- dubbo:argument 参数配置（该标签为 <dubbo:method> 的子标签，用于方法参数的特征描述）
在Provider上尽量多配置Consumer端属性
在dubbo的provider和consumer的配置文件中，如果都配置了timeout的超时时间，dubbo默认以consumer中配置的时间为准。
如下例子：
在provider.xml的配置：
<dubbo:service timeout="4000" retries="0" interface="com.dingding.tms.bms.service.BillingZfbCodOrderService" ref="billingZfbCodOrderService" registry="globalRegistry"/>conusmer中的配置：
<dubbo:reference id="billingInterService" interface="com.dingding.tms.bms.service.BillingInterService" protocol="dubbo" check="false" registry="globalRegistry" timeout="3000"/>最后这个service在调用时的超时时间就是3秒。
另外:
1.consumer会在超过3秒时得到一个调用超时的异常。
2.provider中代码的执行不会因为超时而中断，在执行完毕后，会得到一个dubbo的警告。
在dubbo的用户手册中，对配置有这样的推荐用法：在Provider上尽量多配置Consumer端属性
原因如下：
作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等
在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的
PS: 配置的覆盖规则：
1) 方法级配置级别优于接口级别，即小Scope优先
2) Consumer端配置 优于 Provider配置 优于 全局配置，最后是Dubbo Hard Code的配置值（见配置文档）
在Provider可以配置的Consumer端属性有：
timeout，方法调用超时
retries，失败重试次数，缺省是2（表示加上第一次调用，会调用3次）
loadbalance，负载均衡算法（有多个Provider时，如何挑选Provider调用），缺省是随机（random）。还可以有轮训(roundrobin)、最不活跃优先（leastactive，指从Consumer端并发调用最好的Provider，可以减少的反应慢的Provider的调用，因为反应更容易累积并发的调用）
actives，消费者端，最大并发调用限制，即当Consumer对一个服务的并发调用到上限后，新调用会Wait直到超时。在方法上配置（dubbo:method ）则并发限制针对方法，在接口上配置（dubbo:service），则并发限制针对服务。