这几天自己在工作之余，再次在linux上搭建了dubbo+zookeeper架构，明显比第一次更加顺手，可是这次却栽在了版本问题上，浪费了一下午时间，最后发现是版本太高导致无法启动，相信是程序员都理解这是一种怎么样的心情！！！O(∩_∩)O~~~！！！
由来：
要说dubbo的兴起，咱们就不得不说架构的演变。从ORM到MVC到RPC到SOA再到现在的dubbo。下面就是常见的一张图：
每次架构的演变都是弥补上一次架构的缺点，让他更加符合我们现在的业务。那么dubbo的出现是为了啥呢？
我们知道RPC是解决了不同内存空间之间的请求调用，而SOA是解决了当RPC提供的服务越来越多，服务管理不善导致机器的非高效利用而出现。那么dubbo就是结合了两者的优点。
Dubbo是一种高性能和透明化的RPC远程服务调用方案，也是一种SOA服务治理方案，还是一个分布式服务框架。下面是从网上大神博客上搜到的一张图，感觉很可以说明问题：
从图上可以明显的看出，它利用了RPC的远程调用，也应用了SOA面向服务的思想（注册中心）。
介绍：
1、Dubbo架构有这么几个角色：
- Provider：暴露服务的服务提供方
- Consumer:调用远程服务的服务消费方
- Registry:服务注册于发现的注册中心
- Monitor:统计服务的调用次数和调用时间的监控中心
2、dubbo的注册中心
对于服务提供方和服务消费方，不仅需要关注服务的信息，还需要管理服务。根据单一职责原则，如何才能让提供方和消费方的负担减少一点呢？
于是，dubbo的注册中心就出来了，它可以通过特定协议来完成服务的对外统一，将服务统一管理起来，从而优化内部应用对发布/使用的流程和管理。
dubbo提供的注册中心有如下几种类型：
- Multicast注册中心
- Zookeeper注册中心
- Redis注册中心
- Simple注册中心
常用的是zookeeper注册中心，zookeeper在解决实际的分布式问题上面有很好的解决方法。
3、dubbo的核心
- 远程通信：
提供对多种基于长连接的NIO框架的抽象封装，包括多种线程模型、序列化，以及“请求--响应”模式的信息交换方式
- 集群容错
提供基于接口方法的远程过程透明调用，包括对多协议的支持，以及对软负载均衡、失败容错、地址路由和动态配置等集群特征的支持
- 自动发现：
提供基于注册中心的目录服务，使服务消费方能动态地查找服务提供方，使地址透明，使服务提供方可以平滑地增加或减少机器
