Dubbo

最新推荐文章于 2024-04-21 10:15:00 发布

Limitless*

最新推荐文章于 2024-04-21 10:15:00 发布

阅读量137

点赞数

分类专栏： Java

本文链接：https://blog.csdn.net/shihuahao0353/article/details/82380362

版权

Java 专栏收录该内容

17 篇文章 0 订阅

订阅专栏

一、Dubbo背景和简介

背景
　　随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
　　dubbo开始于电商系统，因此在这里先从电商系统的演变讲起。

1.1单一应用框架（ORM）
　　当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
　　
　　此时，用于简化增删改查工作量的数据访问框架（ORM）是关键。
　　缺点：单一的系统架构，使得在开发过程中，占用的资源越来越多，而且随着流量的增加越来越难以维护。
　　
1.2垂直应用框架（MVC）
　　当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
　　
　　此时，用于加速前端页面开发的Web框架（MVC）是关键。
　　缺点：但是在垂直架构中相同逻辑代码需要不断的复制，不能复用。
　　
1.3分布式应用架构（RPC）
　　当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
　　
　　此时，用于提高业务复用及整合的分布式服务框架（RPC）是关键。
　　已经大致满足了高并发的市场需求。
　　
1.4流动计算架构（SOA）
　　当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
　　此时，用于提高机器利用率的资源调度和治理中心（SOA）是关键。
　　目的：分担服务器压力，提高项目的并发能力。
简介

2.1什么是Dubbo
　　dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东西，说白了就是个远程服务调用的分布式框架。
　　dubbo就是资源调度和治理中心的管理工具。
　　
2.2默认协议
　　Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。Dubbo缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
　　
2.3dubbo和rmi
　　最大的区别就是：RMI本身并没有集群的功能，就是同一个业务部署了多台服务器，他只会根据你配置的ip地址，端口去调用其中一台，不会去调用另外的。所以，怎么去有规则的调用另外的服务器就是负载均衡的工作了，这需要另外实现。
　　总结：RMI能实现分布式服务，但单凭他自己不支持集群。
　　当你的系统需要集群时，远程服务调用就不能用RMI了，他已经不在满足需求，除非你自己在他的基础上继续完善，使之起码可以完成负载均衡的工作，才能开始适应集群环境。
　　但这是比较麻烦的事情，有没有现有的框架可以代替呢？dubbo就是一个很好的选择，给高可用的架构设计带来了巨大的便利。
　　
2.4Dubbo作用及优点
　　1.透明化的异步远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
　　
　　2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
　　
　　3.服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
　　
　　4.服务接口监控与治理， dubbo-admin与dubbo-monitor提供了完善的服务接口管理与监控功能，针对不同应用的不同接口，可以进行多版本，多协议，多注册中心管理。
　　
2.5官方下载地址
　　https://github.com/alibaba/dubbo

二、Dubbo结构

图解dubbo

节点角色说明：
Provider：暴露服务的服务提供方（服务层）。
Consumer：调用远程服务的服务消费方（表现层）。
Registry：服务注册与发现的注册中心（Zookeeper，redis等）。
Monitor：统计服务的调用次调和调用时间的监控中心。
Container：服务运行容器（tomcat 容器，spring容器）。
调用原理说明
0.服务容器启动，加载，运行服务提供者。
1.服务提供者在启动时，向注册中心注册自己提供的服务。
2.服务消费者在启动时，向注册中心订阅自己所需的服务。
3.注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5.服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

三、使用方法

注册中心的选用
　　dubbo注册中心一般采用的是Zookeeper。dubbo发布服务到Zookeeper注册中心，用户获取服务从Zookeeper注册中心获取。把服务消费者和服务提供者解耦合，实现异步调用。
　　1.1什么是Zookeeper？
　　　　Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
　　　　Zookeeper 是一个高可用的分布式数据管理与协调框架。能够很好地保证分布式环境中数据的一致性。也是基于这样的特性，使得 Zookeeper 成为了解决分布式一致性问题的利器。
　　1.2为什么选用Zookeeper？
　　　　因为Zookeeper是一个分布式的服务框架，是树型的目录服务的数据存储，能做到集群管理数据，所以能很好的作为dubbo服务的注册中心。
　　　　dubbo能与Zookeeper做到集群部署，当提供者出现断电等异常停机时，Zookeeper注册中心能自动删除提供者信息，当提供者重启时，能自动恢复注册数据，以及订阅请求。
　　1.3注册原理
　　　　
　　　　（需要先启动Zookeeper后，才能使用Zookeeper注册中心功能）
　　　　根据dubbo发布服务和引用服务：发布和引用服务中心在Zookeeper里面。
　　　　dubbo发布服务到Zookeeper注册中心，用户获取服务从Zookeeper注册中心获取。
　　1.4流程说明
　　　　服务提供者启动时：
　　　　　　向/dubbo/com.foo.BarService/providers目录下写入自己的URL地址。
　　　　服务消费者启动时：
　　　　　　订阅/dubbo/com.foo.BarService/providers目录下的提供者URL地址。
　　　　　　并向/dubbo/com.foo.BarService/consumers目录下写入自己的URL地址。
　　　　监控中心启动时：
　　　　　　订阅/dubbo/com.foo.BarService目录下的所有提供者和消费者URL地址。
　　1.5官方下载地址
　　　　http://mirror.bit.edu.cn/apache/zookeeper
xml配置
　　
　　2.1服务提供者发布服务配置

<!-- 发布服务：把接口service发布Zookeeper注册中心 -->
<!-- 定义dubbo服务名称，此名称可以自定义 -->
<dubbo:application name="provider"/>
<!-- 使用dubbo通过Zookeeper协议注册服务 -->
<dubbo:registry address="Zookeeper://localhost:2181"/>
<!-- 用dubbo协议在20880端口暴露服务 -->
<dubbo:protocol name="dubbo" port="20880" />
<!-- 声明需要暴露的服务接口 -->
<dubbo:service interface="com.alibaba.dubbo.demo.DemoService" 
    ref="demoService" />
<!-- 具体实现该接口的bean -->
<bean id="demoService"
    class="com.alibaba.dubbo.demo.provider.DemoServiceImpl"/>

　　2.2服务消费者消费服务配置
　　

<!-- 消费方应用名，用于计算依赖关系，不是匹配条件，不要与提供方一样 -->
<dubbo:application name="consumer" />
<!-- 向zookeeper订阅provider的地址 -->    
<dubbo:registry address="Zookeeper://localhost:2181" />
<!-- 生成远程服务代理，调用定义好的接口，可以和本地bean一样使用demoService。  Timeout：设置超时时间   retries：允许重连服务的次数 -->
<dubbo:reference id="demoService"
    interface="com.alibaba.dubbo.demo.DemoService" 
    timeout="1000000" retries="2" />

yml配置
　　3.1服务提供者发布服务配置

spring:
  dubbo:
    application:
      name: provider
    registry:
      address: zookeeper://127.0.0.1:2181
    protocol:
        name: dubbo
        prot: 20880
#这是要发布到dubbo的接口所在包位置
    scan: com.alibaba.dubbo.demo

　　3.2服务消费者消费服务配置
　　

spring:
  dubbo:
    application:
      name: consumer
    registry:
      address: zookeeper://127.0.0.1:2181
   scan: com.alibaba.dubbo.demo

四、Dubbo超时重试机制

timeout="1000000" retries="2"

超时设置
　　dubbo消费端设置超时时间需要根据业务实际情况来设定，如果设置的时间太短，一些复杂业务需要很长时间完成，导致在设定的超时时间内无法完成正常的业务处理。这样消费端达到超时时间，那么dubbo会进行重试机制，不合理的重试在一些特殊的业务场景下可能会引发很多问题，合理设置接口超时时间。比如发送邮件，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据。
　　所以需要拥有合理的配置超时和重连的思路。
　　1.对于核心的服务中心，去除dubbo超时重试机制，谨慎评估超时时间。
　　2.业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不要涉及业务流程处理。
重连机制
　　dubbo在调用服务不成功时，默认会重试2次。
　　dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以dubbo的重试机器也能一定程度的保证服务的质量。
　　但是如果不合理的配置重试次数，当失败时会进行重试多次，这样在某个时间点出现性能问题，调用方再连续重复调用，系统请求变为正常值的retries倍，系统压力会大增，容易引起服务雪崩，所以需要根据业务情况合理规划好如何进行异常处理，何时进行重试。

五、Dubbo管理控制台——dubbo-admin

这里写图片描述

dubbo-admin介绍
　　dubbo的使用，其实只需要有注册中心，消费者，提供者这三个就可以使用了，但是并不能看到有哪些消费者和提供者。为了更好的调试，发现问题，解决问题，因此引入dubbo-admin。通过dubbo-admin可以对消费者和提供者进行管理。
使用方法
　　1.官网下载dubbo源码
　　2.编译dubbo-admin工程，打成war包
　　3.进入WEB-INF目录修改文件 dubbo.properties
　　　dubbo.registry.address=zookeeper://127.0.0.1:2181
　　　dubbo.admin.root.password=root
　　　dubbo.admin.guest.password=guest
　　　dubbo-admin 默认两个登陆账号，一个是root，一个是guest
　　　第一行是填写dubbo注册的zookeeper地址。
　　　第二行是填写root的密码。
　　　第三行是填写guest的密码。
　　4.在tomcat中部署war包
　　5.用户名/密码：root/root
dubbo-admin图示

　　服务提供者：
　　
　　服务消费者：

Limitless*

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Dubbo

一、Dubbo背景和简介背景　　随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。　　dubbo开始于电商系统，因此在这里先从电商系统的演变讲起。 1.1单一应用框架（ORM）　　当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。　　　...
复制链接

扫一扫

专栏目录