原文链接:http://blog.csdn.net/zhaozhenzuo/article/details/44781877
dubbo是一个服务治理框架。用于解决服务之间的依赖及调用问题，也是一种rpc实现。
dubbo中，有三个重要角色，一：注册中心，二：服务提供方，三：服务调用者。
一. 注册中心，可以是zookeeper，redis等，其实就是存放一个服务列表的地方。
推荐使用zookeeper，zookeeper用树状结构来进行存储。如图：
zookeeper存储的根结点是对应 <dubbo:register group="dubbo"/>中的group属性。
二.服务提供方
服务提供方连接上zookeeper并将服务注册到zookeeper上。
三.服务消费者
服务消费者会从zookeeper上拿到一份服务列表，并存储在本地文件中。这里如果一台机子部署多个服务的话，即多个jvm进程，这时有可能会发生这个本地文件发生竞争，而抛出异常。但dubbo对于这块异常是会重试的，所以不用担心。
dubbo的整个设计围绕着这三个角色进行。
对应这三个角色的配置标签分别有：<dubbo:register.../> ，<dubbo:provider.../>，<dubbbo:consumer.../>
在生产运用中，可以设置的参数有超时timeout，重试次数retries，负载均衡算法loadbanlance，容错方式failover等。
对于有些插入这种，非幂等操作，需要注意dubbo的超时重试机制。可以将其设置为0。
在protocal协议的选择上（即选择哪种协议用于实现远程调用）目前有dubbo，rmi，http等。
dubbo是默认推荐的方式，使用长连接，nio的形式。实现上就是服务消费方与服务提供方及注册中心之间使用长连接。
使用默认dubbo协议的话，序列化使用的是修改过的hessian协议，这是一种高效的二进制与具体语言无关的协议。而服务提供者端与服务消费者端使用的是mina nio框架。
而dubbo唯一确认一个服务的是：接口interface+版本号version+分组号group。
因此当业务升级接口时，如果服务调用方不兼容新的服务提供方接口时，这时可以采用version版本控制。
而在设计服务接口时，需要以一个功能为一个接口暴露给调用方。如果这个功能被分成三个接口给调用方，而这个功能必须是原子性的，即要么同时成功，要么同时失败，这里就比较麻烦了，需要引入分布式事务或其它方式解决。
对于性能优化上，如果某个业务需要同时查询多个服务，之后将根据这些服务的数据返回结果再做处理的话，可以用async来实现异步调用请求，加速业务处理。