- 知识总结。
- Dubbo是什么？
Dubbo 是阿里出的。为什么 Dubbo 成名了呢？阿里内部使用了它好长时间,一直木有对外公开，后来阿里面的工程师离职了，就把 Dubbo 给带出来了，后来阿里也就把 Dubbo 公开了。
官方说法，Dubbo 是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案。RPC 指的是远程调用协议，也就是说两个服务器交互数据。
注释：
高性能：
为什么 Dubbo 说自己性能高？
高性能要从底层的原理说起，既然是一个 RPC 框架，主要干的就是远程过程（方法）调用， 那么提升性能就要从最关键、最耗时的两个方面入手：序列化和网络通信。
序列化：我们学习 Java 网络开发的时候知道，本地的对象要在网络上传输，必须要实现Serializable 接口，也就是必须序列化。我们序列化的方案很多：xml、json、二进制流…其中效率最高的就是二进制流（因为计算机就是二进制的）。然而 Dubbo 采用的就是效率最高的二进制。
网络通信：不同于 HTTP 需要进行 7 步走（三次握手和四次挥手），Dubbo 采用 Socket 通信机制，一步到位，提升了通信效率，并且可以建立长连接，不用反复连接，直接传输数据
2.Dubbo能做什么？
那么，我们究竟是在什么地方使用到的 Dubbo 呢？大家请看下面的流程图：
流程图
简单来说，用户发送的请求转交给 Nginx，然后 Nginx 决定将请求发送那个服务器（此处为 Tomcat），然后 Tomcat 将请求发送给 Dubbo，由它来决定继续调用哪个 service 层去数据库读取数据。
相信大家对于 Dubbo 作用于何处应该有个大体的了解了。
Dubbo 的使用原理解析
架构图
- Consumer：消费者【调用远程服务的服务消费方】
- Provider：生产者【暴露服务的服务提供方】
- Registry：注册中心【服务注册与发现的注册中心】
- Monitor：监控中心【统计服务的调用次调和调用时间的监控中心】
执行的顺序： - 0：先启动生产者；
- 1：生产者将自己启动的消息报告给注册中心；
- 2：消费者启动，通知注册中心；
- 3：注册中心通知消费者有生产者了；
- 4：消费者消费(调用方法)；
- 5：生产者和消费者将自己的调用信息和被调用信息发送监控中心；
要说明的是，必须要先启动生产者，就像咱们平常生活一样，只有生产了某样东西你才能去消费，对吧。
可能会有读者有疑问，这个生产者、消费者和上面的流程图有什么关系，或者说，生产者、消费者对应流程图中的哪个部分呢？
在这里我想用一些拟人化的手法解释一下，效果或许会更好点。
生产者相当于 service 层，拿上面的流程图来说，可以看成有三个生产者：service、service_2 和 service_3。
随便拿其中一个生产者举例子，比如说 service_2，它能够利用 dao 层去数据库取出数据，也就是说生产者可以拿到他人需要的数据，这也正符合「生产者」这个名词，service_2 可以 “生产” 出消费者需要的东西（数据）。
生产者在产生之后会先去 Registry 这个地方去「报到」，告诉Registry 它能生产哪些物品（即取出哪些数据）。
消费者相当于 controller 层，暂且把消费者叫做 c。如果 c 想要买某样东西（可以把这样东西看成数据库中的数据），但是不知道该去哪里买，那么这个时候，它就会去 Registry 这个地方，告诉 Registry 它需要这个东西。
由于生产者产生之后在这里「报到」过了，所以 Registry 会告诉消费者 c，生产者 service_2 可以给你你想要的东西（数据），然后消费者 c 就会去找生产者 service_2 而不去找其他两个生产者，这样一来 service 层的压力就会小很多。
不知道这么说大家有没有能够明白一点。
还有就是，不论是生产者还是消费者，产生之后都要去 Registry 报到，不然就是黑户哟~
另外，它俩都要受到 Monitor（监控中心）的监控，以监控它俩是否离奇失踪，哈哈。
Dubbo 的存在简单来说就是要减小 service 层的压力
1). 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
2). 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
3). 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
4).Dubbo采用全spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载
这点我觉得非常好，角色分明，可以根据每个节点角色的状态来确定该服务是否正常。
- .dubbo练习
Privoder:
- maven引入dubbo依赖,zookeeper注册中心依赖
<!--引入dubbo -->
<!-- https://mvnrepository.com/artifact/com.alibaba/dubbo -->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.6.2</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>2.12.0</version>
</dependency>
- services的编写
- 编写provider.xml配置文件
<!-- 和本地bean一样实现服务 -->
<bean id="userServicesimple" class="com.yanghuan.servicesimpl.UserServicesimple" />
<!-- 1.指定当前服务/应用的名字（同样的服务名字相同，不要和别的服务同名） -->
<dubbo:application name="user-service-provider" />
<!-- 2.指定注册中心的地址 -->
<dubbo:registry address="zookeeper://127.0.0.1:2181?client=curator" />
<!-- 3.用dubbo协议在20880端口 暴露服务-->
<dubbo:protocol name="dubbo" port="21880" />
<!-- 4.声明需要暴露的服务接口 -->
<dubbo:service interface="com.yanghuan.service.UserService" ref="userServicesimple" />
- 测试，注册到注册中心
Consumer:
I. <!--引入dubbo -->
<!-- https://mvnrepository.com/artifact/com.alibaba/dubbo -->
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>dubbo</artifactId>
<version>2.6.2</version>
</dependency>
<!--注册中心使用zookeeper，引入操作zookeeper的客户端 -->
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>2.12.0</version>
</dependency>
II.consumer.xml配置文件的编写
<context:component-scan base-package="com.yanghuan.serviceimpl" />
<dubbo:application name="order-service-consumer"/>
<!--指定注册中心的地址 -->
<dubbo:registry address="zookeeper://127.0.0.1:2181?client=curator"/>
<!--声明需要调用的远程服务接口，生成远程代理 -->
<dubbo:reference interface="com.yanghuan.service.UserService" id="userService" check="false"/>
III.serviceimple的编写，注意spring注入
- 测试调用提供者提供的接口
- 注意，运行前启动zookeeper
- 心得体会
感觉dubbo使多个不同地方服务器中间的代码联通更加便捷，同时也意识到每个人部分代码质量的重要性
dubbo派发原理：源码分析Dubbo网络通讯篇之NettyServer网络事件派发机制(Dispatch)_dubbo dispatch_中间件兴趣圈的博客-CSDN博客
1170
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
