引言
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）
Dubbo是什么？
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。
Dubbo能做什么？
- 1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，配置简单，无API侵入
- 2.软负载均衡以及容错机制，可在内网替代F5等硬件负载均衡器，降低成本
- 3.服务的自动注册与发现，不需要写死服务提供方的地址，注册中心基于接口名查询服务提供着的IP地址，并且可以平滑的添加或者删除服务提供者。
- 4.Dubbo采用Spring配置的方式，透明化接入应用，只需要Spring加载Dubbo的配置即可 Dubbo基于Spring的Schema扩展进行加载。
Dubbo架构
节点角色说明：
- Provider: 暴露服务的服务提供方。
- Consumer: 调用远程服务的服务消费方。
- Registry: 服务注册与发现的注册中心。
- Monitor: 统计服务的调用次调和调用时间的监控中心。
- Container: 服务运行容器。
调用流程
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
传统架构和分布式系统架构的优缺点
传统架构
1:模块之间耦合度太高,其中一个功能升级,其他的模块都得一起升级部署。
2:开发困难,各个团队开发最后都要整合在一起.
3:系统扩展性差
4:不能灵活进行分布式部署
分布式系统架构
1:把模块拆分,使用接口通信,降低模块之间的耦合度.
2:把项目拆分成若干个子项目,不同的团队负责不同的子项目.
3:增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。
4:可以灵活的进行分布式部署.
5:提高代码的复用性,比如service层,如果不采用分布式rest服务方式架构就会在手机wap商城,微信商城,pc,android，ios每个端都要写一个service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。
缺点:
系统之间的交互要使用远程通信,接口开发增大工作量,但是利大于弊,哈哈。
