一、入门
整体架构：单一架构
垂直架构：MVC
分布式服务架构：RPC
流计算架构：
当服务越来越多时，容量评估变得困难，而且小规模的服务也经常造成资源浪费。为了解决这些问题，应添加调度中心，以根据流量管理集群容量并提高集群利用率。目前，用于提高机器利用率的资源调度和治理中心（SOA）是关键。
在大型服务出现之前，应用程序可能只是通过使用RMI或Hessian公开或引用远程服务，调用是通过配置服务URL来完成的，而负载平衡是通过硬件（如F5）来完成的。当服务越来越多时，配置服务URL变得非常困难，F5硬件负载平衡器的单点压力也在增加。此时，需要一个服务注册表来动态注册和发现服务，以使服务的位置透明。通过获取服务提供商地址列表，可以实现软负载平衡和故障转移，从而减少了对F5硬件负载平衡器的依赖性以及某些成本。
当事情进一步发展时，服务依赖关系变得如此复杂，以至于甚至连架构师也无法完全描述应用程序架构之间的关系。这时，需要自动绘制应用程序的依赖关系图，以帮助架构师清除关系。
然后，流量变得更大，服务的容量问题暴露出来，需要多少台机器来支持该服务？何时应添加机器？
服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求
服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，如果失败，它将选择另一个Provider。
服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外。
注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心。
监控中心和注册中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表；注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。
Consumer和Provider都会计算内存中调用服务的次数和耗时，并将统计信息发送到Monitor每分钟。
二、快速启动
Dubbo 采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo 的配置即可，Dubbo 基于 Spring 的 Schema 扩展 进行加载。
Dubbo服务接口需单独打包，在服务提供方和消费方共享
三、成熟度
| 分布式事务 | Research | JTA/XA三阶段提交事务 | 不稳定 | 不可用 |
| Dubbo协议 | Stable | 采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用） | 在大文件传输时，单一连接会成为瓶颈 | 可用于生产环境 | Alibaba |