Dubbo是一个分布式服务框架，以及SOA治理方案。其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。 它有5个节点，分别是Provider, Consumer, Registry, Monitor, Container。其中Provider是服务提供者， Consumer是服务消费者，Registry是服务进行注册和被发现的注册中心，Monitor是统计服务的调用次数和调用时间的监控中心，Container是服务运行容器。他们之间调用的关系是：Container负责启动，加载然后运行Provider。Provider在启动时会向注册中心注册自己提供的服务，Consumer在启动时会向Registry订阅自己所需服务，此时Registry会返回Provider地址列表给Consumer。如果地址有变更，Registry会基于长连接推送变更数据给Consumer。Consumer会基于软负载均衡算法选一台提供者进行调用，如果调用失败，则再选一台。Provider和Consumer在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到Monitor。 Dubbo具有4个特点，分别是连通性、jian壮性、伸缩性、以及向未来架构的升级性。连通性说明他们之间都存在着关系，比如说Provider,Consumer和Registry三者之间都是长连接，而Provider，Consumer向Registry注册服务以及订阅服务的时间都得向Monitor汇报。而jian壮性说明具有稳定性，比如说注册中心对等集群中的任意一台宕掉后，将自动切换到另一台。就算注册中心全部宕掉，服务者和消费者仍可以通过本地缓存进行通讯。而伸缩性就是可以通过增加机器部署实例进行添加新的注册中心和服务提供者。而升级性是文档中提到的对未来架构的设想，比起目前框架它的特点是可以实现自动部署服务的本地代理以及可以通过访问压力来自动增减服务提供者。
Zookeeper作为Dubbo的注册中心时：服务提供者在初始化启动时，会在Zookeeper下的Dubbo节点下的服务节点下的providers节点下的节点创建一个子节点并写入URL，路径为 /dubbo/servicename/providers/ ，该路径下的所有子节点均为服务提供者。此时这些子节点都为临时节点，因为临时节点的生命周期与客户端会话相关，所以一旦提供者所在的机器出现故障导致提供者无法提供服务，该临时节点就会自动从Zookeeper删除。此时因为服务者，注册中心，消费者之间是长连接，注册中心能感知服务者宕机，会告知消费者。而监控中心是Dubbo服务治理体系中重要的一部分，它需要知道所有的服务提供者和消费者的变化情况 。所以它在启动时会在服务节点上注册一个watcher来监听子节点变化，路径为 /dubbo/servicename/ ，所以它也能感知服务提供者的宕机。服务消费者的节点创建过程和提供者是一样的，而且也是临时结点。还有一个特性就是Zookeeper的节点结构设计，它以服务名和类型，也就是 /dubbo/servicename/类型 作为节点路径，符合Dubbo订阅和通知的需求，保证了以服务为粒度的变更通知，通知范围易于控制。所以即使服务提供者和消费者频繁变更，对Zookeeper的性能也不会造成多大影响。