记录1:Dubbo入门

记录1:Dubbo入门

刚刚接触dubbo，记录几个dubbo的学习网站，以供以后更深入的学习，

Dubbo发展背景

(All in one整体架构)

当流量非常低时，只有一个应用程序，所有功能都一​​起部署以减少部署节点和成本

(Vertical Application垂直架构）

当流量增加时，添加整体应用程序实例不能很好地加速访问，提高效率的一种方法是将整体结构拆分为离散的应用程序。在这一点上，用于加速前端页面开发的Web框架（MVC）是关键。

(Distributed Service分布式服务架构)

当垂直应用程序越来越多时，应用程序之间的交互是不可避免的，一些核心业务被提取并作为独立的服务，以此来提供服务，逐渐形成一个稳定的服务中心。很快。此时，用于业务重用和集成的分布式服务框架（RPC）是关键。

(Elastic Computing 流计算架构)

这个就是，我们这些微服务还没搞懂，就又来的流服务

当服务越来越多时，容量评估变得困难，而且小规模的服务也经常造成资源浪费。为了解决这些问题，应添加调度中心，以根据流量管理集群容量并提高集群利用率。目前，用于提高机器利用率的资源调度和治理中心（SOA）是关键。

加个插曲。这时候就有人会考虑了，Dubbo到底是啥？我来加个问题springcloud和Dubbo的区别

1、通信方式不同：Dubbo 使用的是 RPC 通信，而Spring Cloud 使用的是HTTP RESTFul 方式。
2、组成不一样：
dubbo的服务注册中心为Zookeerper，服务监控中心为dubbo-monitor,无消息总线，服务跟踪、批量任务等组件；
spring-cloud的服务注册中心为spring-cloud netflix enruka，服务监控中心为spring-boot admin,有消息总线，数据流、服务跟踪、批量任务等组件；

这时候你就知道Dubbo定义在哪个区间内了吧！没错他是定义在微服务一类中的。。(个人理解)

dubbo服务注册与消费的流程图

节点	角色解释
Provider	提供者公开远程服务
Consumer	消费者致电远程服务
Registry	注册表负责服务发现和配置
Monitor	监视器计算服务调用的数量和耗时
Container	容器管理服务的生命周期i

服务关系

0. Container负责启动，加载和运行服务Provider。
1. ProviderRegister在启动时,向注册中心注册自己提供的服务。
2. Consumer从Register启动时,向注册中心订阅自己所需的服务。
3. Register将Providers列表返回Consumer，当它更改时，Register将Consumer通过长连接将更改的数据推送给使用者。
4. ConsumerProvider从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果失败，它将选择另一个Provider。
5. Consumer和Provider都会计算内存中调用服务的次数和耗时，定时每分钟发送一次统计数据到Monitor。

dubbo架构具有以下几个特点

连通性

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
:监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销

服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销

注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外

注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者

注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
:注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

健壮性

监控中心宕掉不影响使用，只是丢失部分采样数据

数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务

注册中心对等集群，任意一台宕掉后，将自动切换到另一台

注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯

服务提供者无状态，任意一台宕掉后，不影响使用

服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

还有一个升级性,建议有兴趣可以去官网看一下…

用法

本地服务 Spring 配置

<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” />
<bean id=“xxxAction” class=“com.xxx.XxxAction”>
    <property name=“xxxService” ref=“xxxService” />
</bean>

远程服务 Spring 配置

在本地服务的基础上，只需做简单配置，即可完成远程化：

将上面的 local.xml 配置拆分成两份，将服务定义部分放在服务提供方 remote-provider.xml，将服务引用部分放在服务消费方 remote-consumer.xml。

并在提供方增加暴露服务配置 dubbo:service，在消费方增加引用服务配置 dubbo:reference。

remote-provider.xml:

<!-- 和本地服务一样实现远程服务 -->
<bean id=“xxxService” class=“com.xxx.XxxServiceImpl” /> 
<!-- 增加暴露远程服务配置 -->
<dubbo:service interface=“com.xxx.XxxService” ref=“xxxService” /> 

remote-consumer.xml:

<!-- 增加引用远程服务配置 -->
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” />
<!-- 和本地服务一样使用远程服务 -->
<bean id=“xxxAction” class=“com.xxx.XxxAction”> 
    <property name=“xxxService” ref=“xxxService” />
</bean>

Dubbo-简书
Dubbo 一篇文章就够了：从入门到实战
知道了这些内容，闭着眼面试Dubbo！