用dubbo是想利用分布式集群的形式来提高服务的并发量,适用与大型项目.如果不用它还想提高并发另一个解决方案是springCloud+微服务.适合大中小型项目.当前对并发要求的项目还是很多的,所以dubbo用的也相对较多.建议如果是初学者可以跳过dubbo直接学习第二个方案，使用场景更多.至于核心原理不建议现在就去掌握.循序渐进,慢慢来真的使用了再研究.不要上来就去学原理。毕竟相对枯燥.简单说一点基本就分4中角色.提供者,消费者注册到注册中心dubbo下的zk.然后消费者通过服务rpc调用即可.第四个是监控中心可以服务的注册情况.暂时了解这么多即可，后续有需要可以再提

用的多

dubbo原理和机制：应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。  注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。  监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。  服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。  服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

节点角色说明：

Provider: 暴露服务的服务提供方。

Consumer: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心。

Monitor: 统计服务的调用次调和调用时间的监控中心。

Container: 服务运行容器

调用关系说明：

0：服务容器负责启动、加载、运行服务提供者。

1：服务提供者在启动的时候，向注册中心注册自己提供的服务。

2：服务消费者在启动的时候，向注册中心订阅自己所需的服务。

3：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4：服务消费者，从提供者地址列表中，基于负载均衡的算法，选一台服务提供者进行调用，如果调用失败，则在重新调用一次。

5：服务消费者和服务提供者在内存中累计调用次数和调用时间，定时发送数据到监控中心。

如果要使用dubbo，那就离不开注册中心。dubbo依赖第三方软件来提供注册中心服务。ZooKeeper是一个不错的选择。

用的多

dubbo原理和机制：应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。  注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。  监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。  服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。  服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

用dubbo是想利用分布式集群的形式来提高服务的并发量,适用与大型项目.如果不用它还想提高并发另一个解决方案是springCloud+微服务.适合大中小型项目.当前对并发要求的项目还是很多的,所以dubbo用的也相对较多.建议如果是初学者可以跳过dubbo直接学习第二个方案，使用场景更多.至于核心原理不建议现在就去掌握.循序渐进,慢慢来真的使用了再研究.不要上来就去学原理。毕竟相对枯燥.简单说一点基本就分4中角色.提供者,消费者注册到注册中心dubbo下的zk.然后消费者通过服务rpc调用即可.第四个是监控中心可以服务的注册情况.暂时了解这么多即可，后续有需要可以再提

Dubbo 是一个分布式服务框架，是阿里巴巴开源项目 ，被国内电商及互联网项目中使用，Dubbo 致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有 Dubbo 这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架。

节点角色说明：

Provider: 暴露服务的服务提供方。

Consumer: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心。

Monitor: 统计服务的调用次调和调用时间的监控中心。

Container: 服务运行容器

调用关系说明：

0：服务容器负责启动、加载、运行服务提供者。

1：服务提供者在启动的时候，向注册中心注册自己提供的服务。

2：服务消费者在启动的时候，向注册中心订阅自己所需的服务。

3：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4：服务消费者，从提供者地址列表中，基于负载均衡的算法，选一台服务提供者进行调用，如果调用失败，则在重新调用一次。

5：服务消费者和服务提供者在内存中累计调用次数和调用时间，定时发送数据到监控中心。

如果要使用dubbo，那就离不开注册中心。dubbo依赖第三方软件来提供注册中心服务。ZooKeeper是一个不错的选择。

服务提供者配置常用名称如下：

注意：dubbo:annotation 用于包扫描

服务消费者配置常用名称如下：

消费者需要调用远程服务：

dubbo现在使用比较普遍的哦，核心原理就是远程调用服务。

dubbo的组成分为，容器、服务提供者、服务消费者、监控中心、注册中心五个部分，执行原理是：

1. 加载容器，启动服务提供者

2. 服务提供者向注册中心（官方推荐使用zookeeper作为注册中心）注册服务

3. 消费者向注册中心订阅服务

4. 注册中心将服务地址告诉消费者

5. 消费者根据服务地址采用负载均衡的算法去找到服务

6. 管理中心定期监控服务调用的频率

如果你还不理解，我可以举个例子：

假如我要去吃海底捞，我要在美团上先搜索附近的海底捞门店。

美团就相当于容器，海底捞就相当于服务提供者，我相当于消费者。

海底捞在美团上入驻了，向美团这个平台注册了门店地址，我在美团搜索了海底捞发现了很多海底捞门店，美团会智能的推送最近的门店给我，我就获取了海底捞门店的地址，就可以去海底捞吃火锅了，去到海底捞发现人满了，我还可以选择其他的海底捞门店（负载均衡），当海底捞门店的地址发生变化，美团还好动态地把最新的海底捞门店地址告诉我。

Dubbo是一种服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和  Spring框架无缝集成。

主要的核心部件：

Remoting: 网络通信框架，实现了 sync-over-async 和

request-response 消息机制.

RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能

Registry: 服务目录框架用于服务的注册和服务事件发布和订阅