1. Dubbo
Dubbo是一个分布式服务框架，提供了高性能和透明化的RPC（Remote Procedure Call Protocol）远程服务调用方案和服务治理方案。
SOA：面向服务的架构
Dubbo协议特点：
- 远程调用：提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。一旦发布这个服务，客户端不需关心内部细节和如何实现，Dubbo已封装好，直接调用接口即可
- 集群管理：内置多种负载均衡策略，提高系统吞吐量，并支持灵活扩展。
- 自动发现：支持多种注册中心服务，服务实力上下线实施感知。对于SOA的系统，其服务都需要自动的去发现，不然会有一个问题：服务提供者很多，服务的地址是没有办法进行管理的，它需要有一个注册中心，去进行管理这些服务。当服务发布之后，自动去注册中心注册；对服务的上下线也能自动的感知。当服务下线，自动从注册中心踢掉。
2. Dubbo基本原理
架构
节点角色说明
| 节点 | 角色说明 |
| Provider | 暴露服务的服务提供方 |
| Consumer | 调用远程服务的服务消费方 |
| Registry | 服务注册与发现的注册中心 |
| Monitor | 统计服务的调用次数和调用时间的监控中心 |
| Container | 服务运行容器 |
2.1 Dubbo与整体的服务有什么不同？
假设tomcat有一个服务（包含A、B2部分），通过http去调用。
引发的问题：发布的时候，其实是一整套，各个服务是拆分不开的。假设修改了A，但发布时要把B一起带上去，因为他是一个整体。
而对于SOA来说，改A就是改A
2.2 Dubbo provider管理
Consumer调用的时候先去注册中心，不需要给一个明确的地址。假设有100个服务，就需要100个URL。对于Dubbo来说，只需告诉Consumer服务名字，它自己回去注册中心找可用的provider，不要URL地址。
2.3 Dubbo负载均衡
我们去银行办理业务，大厅工作人员会给我们号码，分散到不同的柜台。
Dubbo也是一样的，不过它是通过注册中心实现的。
我们去消费的时候，一个消费者有非常多的provider提供者。当有大量的请求进来的时候，它会均匀的分配到不同的provider，避免只调一台，否则那台压力会非常大。