dubbo的核心是RPC框架，RPC的核心是"socket+代理"！
dubbo运行架构如下图示：
节点角色说明：
1、Provider:暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。 2、Registry:服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。 3、Container: 服务运行容器。
调用关系说明：
1、服务容器负责启动，加载，运行服务提供者。
2、服务提供者在启动时，向注册中心注册自己提供的服务。
3、服务消费者在启动时，向注册中心订阅自己所需的服务。
4、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
5、服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
6、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心
注： 从dubbo的架构图，我们可以看到这与web service的架构图基本一致 ，但是dubbo为了增加访问 速度，没有异构平台调用的需求，无需使用XML。
在企业内网，增加了软负载均衡算法，可以替换F5的负载作用。
dubbo支持REST风格的调用，这使它可以对当今特别流行的“微服务”架构提供基础性支持。
支持基于Kryo和FST的Java高效序列化实现，显著的提高了Dubbo RPC的性能。
dubbo与zookeeper的 关系是： zookeeper是dubbo的注册中心的实现方案之一；
参考： http://blog.csdn.net/xlgen157387/article/details/51865289
欢迎访问肖海鹏老师的课程中心 http://edu.51cto.com/center/course/lecturer/course
欢迎加入肖海鹏老师技术交流群：2641394058(QQ)
原文地址：http://xiaogong1688.blog.51cto.com/10053053/1945949
