1、Dubbo由来
架构的演变：单体-垂直-SOA-分布式
dubbo是阿里提出的服务治理的解决方案/框架
Dubbo是由一个一个的架构演变而来的。
由统一的定制到-分布式架构的演变
①、如下图所示：下面的架构是当业务量很小的情况，并且在数据量很小的情况下，就不涉及到分布式，下面的架构就是单体的架构。所有的模块在一个系统，由UI界面去操作下面所有的模块。然后模块下面对应的是DB。所有的功能的界面都柔和在一起，所有的模块在一个项目中。
②、如下图所示：当业务量越来越大的时候，当平台越做越大的时候，当数据量越来越大的时候，就不能单表的形式这样存储数据了。这时的架构是为了容纳更多的数据，可以进行横向的扩展，可以去启动多个数据库服务，每一个模块对应一个数据库服务器，然后每一个模块调用自己的数据库服务器就可以了。这就是垂直拆分，一台数据库无法存储这么大的数据量，所以要分成五个库进行存储。
③、如下图所示：如果数据库容量不够的情况下，也可以进行水平的扩展。随着系统的复杂度越来越复杂的话，整个系统的用户量越来越大。比如：每一个时刻，这个订单服务 要处理几万的订单的数量的话，所以这时的订单模块要进行扩展，为了性能的提升，将多个模块拆成多个子系统。多个子系统最终会有调用的关系的，这时就有垂直架构了，各个模块之间要起到协调的关系。这时需要企业数据总线(类似于通信的管道)，来协调各个模块之间的关系的，这时不用管调用的服务在哪里。
这5个子系统都是在基础系统之上构建起来的，基础系统是为子系统提供一些数据的服务。
④、如下图所示：随着业务的深入，不得不对子系统进行调整也会对业务的拆分。当订单的子系统已经无法承受住原有的订单量的时候，这时需要扩充。这时就有了SOA的架构:面向服务的架构，它不是一个成熟的产品，而是一种思想。把一个一个的系统做成一个一个的服务。通过服务的横向的扩展增加订单的处理量，从而提高订单子系统对整个业务的支撑。由于服务部署在不同的机器上，需要进行通信的。
SOA:在架构中称之为服务的治理。
比如：下完订单要减库存，而且也需要下物流，下物流的时候需要知道用户
用户和商品也有联系，商品和库存也有联系。他们的联系像蜘蛛网一样很乱很乱的。
⑤、如下图所示：在很乱的情况下就出现了一个新的框架：专门为整理服务的管理而诞生的
dubbo就是服务治理框架-可以把乱七八糟的服务进行整理，通过企业数据总线去制定统一的标准。然后让让各个服务注册到企业数据总线去，然后去调用就可以了，在企业数据总线中有统一的标准的对应的协议和交互方式。这样做的好处是降低了用户的成本。用户不用去关心各个服务用的语言，只需要遵循这个协议用统一的标准去调用就可以了。协议有dubbo,hession,rpc，这时就不需要知道服务在哪个位置，哪个机器上。
企业数据总线主要用来做协调的，调用的，不是用来做集成服务的。
微服务和dubbo的区别：
①、微服务是对子系统再一次的拆分。
②、dubbo是服务治理框架，远程调用的框架，rpc的框架。
③、在微服务中没有企业数据总线这一说，因为微服务中用的是rest风格的协议来通信的。
