浅析Dubbo架构和实现细节（基本原理）

概述

Dubbo这个框架实在是太屌了！本文是我初学Dubbo的体会，用口水话阐述，如有不对，欢迎指正，一起学习共同探讨。

Dubbo是RPC框架的一种，在说起RPC之前，先讲一个故事：

在参军之前，小C需要骏马和长鞭。假设小C家有养马的人和做鞭子的人，那就只需要在自己家的仓库中取用养好的马和做好的鞭子。问题就是小C很穷，家里根本没有帮她做鞭子的人，更不要提养马，即便是小C家有钱，万一仓库被洪水冲走怎么办？于是小C不如去东市买骏马、北市买长鞭。东市卖马的老板手下专门有员工养马；北市的卖鞭的老板手下专门有员工做鞭，马是怎么养成的，鞭是怎么做出来的，小C根本不用关心，只需要跑到两个老板那里取马和鞭。

回归正题，RPC服务就类似于小C买马和买鞭子。如果没有RPC，那么小C需要自己请人造马和鞭，所以他要承担相应的风险，比如洪水来了，仓库down掉了，这时候，小C就GG了。如果选择分别从其他地方得到，这就很方便，不需要担心洪水，不用担心马没了，甚至还能你看这个鞭它又长又宽，更不需要知道马具体是怎么养出来的，鞭具体是怎么造出来的。

这里出现了几个问题：① 为什么要从其他地方得到呢？因为风险小，不会受到自家仓库洪水的影响；② 为什么要分别从不同的商店得到马和鞭呢？因为万一马店倒闭了，卖鞭的商店不受任何影响；③ 那有很多个小C都要参军，如果只有一家马店和一家鞭店怎么办呢？集群！看到这家排队的多，就去另外一家；④ 有很多家专门卖马的店，也有很多卖鞭的店，那小C们到底哪一家买，排队的时间或等待的时间少呢？这就需要负载均衡……RPC问题就是这样一步步得出来的，当然这只是个非常大概的思路。

于是开始对应：造马和鞭的人是接口；马和鞭是接口的实现；卖马和鞭的老板，统称为老板，就是整个商店的(马店和鞭店统称为商店)管理员；众多个马店称为一个集群(众多个鞭店也是，众多个小C也是)；一个马店称为一个节点(鞭店和小C类似)；一个马店或者一个鞭店称为一个服务提供者；一个小C称为一个消费者。

有了这个故事为前提，就可以开始Dubbo初识。Dubbo是RPC框架的一种，旨在提供高性能，可伸缩的服务架构，尤其是提供了API和SPI，开发人员可以对框架扩展(抽象可忽略)。

---

基本架构</