版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
Dubbo背景介绍
随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，需一个治理系统确保架构有条不紊的演进。
上面引用了官方文档的一段说辞，介绍了dubbo的由来，它是一个由阿里巴巴开源的RPC(远程过程调用)框架，是一个分布式的微服务解决方案。
框架角色
一个消费者，一个提供者，一个注册中心，一个监控中心，一个运行容器
在一个运行容器中，提供者将服务注册在注册中心消费者去注册中心调用，监控中心对他们的操作记录进行监控记录，这就是dubble的这些角色以及他们要干的事。
框架特性
1，连通性
- 注册中心在服务消费者和服务提供者启动时向注册中心注册信息，就像是打开文档就能将文档内容标题在左侧给你生成的目录一样，你阅读哪部分内容就找标题就行。他不转发请求，压力较小
- 监控中心会在你每次调用服务注册服务时，将操作的次数时间等统计起来，先在内存中统一整理，然后每分钟将记录发送到监控中心，并以报表的形式展示
- 服务提供者者每次在注册中心将提供的服务进行注册时，会将注册时间汇报给监控中心，此时间不包含网络开销的
- 服务消费者每次去注册中心调用服务时，会根据负载均衡算法调用对应的服务并将时间汇报给注册中心，此时间不包含网络开销
- 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心不是
- 注册中心通过长连接感知服务提供者是否宕机，如果服务提供者宕机注册中心会推送事件通知服务消费者
- 注册中心和监控中心在运行一段时间后宕机，不影响服务消费者调用服务提供者，因为服务消费者已经在本地缓存服务提供者列表
- 注册中心和监控中心时可选的，不要他俩服务消费者和服务提供者也可以连通
2，健壮性
- 监控中心宕掉不影响使用，只是丢失部分采样数据
- 数据库宕机后，注册中心仍能提供服务，如果你用了缓存中间件的话，但是只能做一些查询操作。
- 注册中心对等集群，如果其中某台服务宕机后，注册中心自动连接另一台
- 服务提供者时无状态的，宕机其中一台不影响使用
- 服务提供者全部宕机，服务消费者将无法使用，消费者会无限此的发送请求知道服务提供者恢复
3，伸缩性
- 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
- 服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者
4，升级性
当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力