一 为什么需要dubbo
很多时候，其实我们使用这个技术的时候，可能都是因为项目的需要，所以就用了，但是，至于为什么我们需要使用到这个技术，可能自身不是很了解。
在互联网的发展过程中，在以前，我们只需要一个服务器，将程序全部打包好就可以，但是，随着流量的增大，常规的垂直应用架构已无法应对，所以架构就发生了演变。
1，单一应用架构
2，应用和数据库单独部署
3，应用和数据库集群部署
4，数据库压力变大，读写分离
5，使用缓存及时加快分离；
6，数据库分库分表
7，应用分为不同的类型拆分
发展到这个阶段的时候，我们发现，应用与应用之间的关系已经十分的复杂了，就会出现以下的问题（以下摘录于官网）
1，当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大
2，当进一步发展，服务间依赖关系变得错综复杂，甚至分不清那个应用要在那个应用之前启动，架构师也不能完整的描述应用的架构关系.
3,接着，服务的调用越来越大，服务的容量问题就暴露出来了，这个服务需要多少机器支撑，什么时候该加载机器？
为了解决这由于架构的演变所产生的问题，于是dubbo产生了。当然，解决这个问题的技术不止dubbo.
从上面Dubbo的服务治理图我们可以看到，Dubbo很好的解决了上面所出现的一些问题。
所以，当你的系统架构发展到这种阶段的时候，就需要考虑使用Dubbo了。
二 Dubbo技术架构
我们已经很清楚的知道为什么在我们的系统里需要dubbo这个技术了。
首先，上一张图。
看到图以后，可能你对上面的几个概念还是一脸懵逼，无从下手，下面，带你看看这几个角色到底是什么意思？
节点角色说明：
看了这几个概念以后似乎发现，其实Dubbo的架构也是很简单的（其实现细节是复杂的），为什么这么说呢，有没有发现，其实很像生产者-消费者模型。只是在这种模型上，加上了注册中心和监控中心，用于管理提供方便的url以及管理整个过程。
那么整个发布-订阅的过程就非常简单了。
启动容器，加载，运行服务提供者，
服务提供者在启动时，在注册中心发布注册自己提供的服务。
服务消费者在启动时，在注册中心订阅自己所需要的服务。
