Dubbo

尾翼稳定脱壳穿甲弹
119 阅读9分钟

前言

互联网项目特点：

  • 用户多
  • 流量大，并发高
  • 海量数据
  • 易受攻击
  • 功能繁琐
  • 变更快

衡量网站的性能指标：

  • 响应时间：指执行一个请求从开始到最后收到响应数据所花费的总体时间。
  • 并发数：指系统同时能处理的请求数量。
    • 并发连接数：指的是客户端向服务器发起请求，并建立了TCP连接。每秒钟服务器连接的总TCP数量
    • 请求数：也称为QPS(Query Per Second)指每秒多少请求
    • 并发用户数：单位时间内有多少用户
  • 吞吐量：指单位时间内系统能处理的请求数量。
    • QPS：Query Per Second每秒查询数。
    • TPS：Transactions Per Second每秒事务数。
    • 一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

大型互联网项目架构目标

  • 高性能：提供快速的访问体验
  • 高可用：网站服务一直可以正常访问
  • 可伸缩：通过硬件增加/减少，提高/降低处理能力
  • 高可扩展：系统间耦合低，方便的过新增/移除方式，增加/减少新的功能/模块
  • 安全性：提供网站安全访问和数据加密，安全存储等策略
  • 敏捷性：随需应变，快速响应

集群和分布式

  • 集群：很多“人”一起，干一样的事。一个业务模块，部署在多台服务器上。
  • 分布式：很多“人”一起，干不一样的事。这些不一样的事，合起来是一件大事。一个大的业务系统，拆分为小的业务模块，分别部署在不同的机器

他俩一般是并存的

系统架构的演化

单体架构 ==> 垂直架构 ==> 分布式架构 ==> SOA架构 ==> 微服务架构

单体架构

优点：

  • 简单：开发部署都很方便，小型项目首选

缺点：

  • 项目启动慢
  • 可靠性差
  • 可伸缩性差
  • 扩展性和可维护性差
  • 性能低

垂直架构

有多个独立的单体架构，没有交集

缺点：

  • 项目启动慢
  • 可靠性差
  • 可伸缩性差
  • 扩展性和可维护性差
  • 性能低
  • 重复功能太多

分布式架构

分布式架构是指在垂直架构的基础上，将公共业务模块抽取出来，作为独立的服务供其他调用者消费，以实现服务的共享和重用。

RPC：Remote Procedure Call远程过程调用。有非常多的协议和技术来都实现了RPC的过程。比如：HTTP REST风格，Java RMI规范、WebService SOAP协议、Hession等等。（这些过程由Dubbo自动完成）

分布式架构存在的问题：

  • 服务提供方一旦产生变更，所有消费方都需要变更

SOA架构

SOA：(Service-Oriented Architecture，面向服务的架构)是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。

ESB：(Enterparise Service Bus)企业服务总线，是个服务中介。主要是提供了一个服务于服务之间的交互。ESB包含的功能如：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。

微服务架构

微服务架构是在SOA架构上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

特点：

  • 服务实现组件化：开发者可以自由选择开发技术。也不需要协调其他团队
  • 服务之间交互一般使用REST API
  • 去中心化：每个微服务有自己私有的数据库特久化业务数据
  • 自动化部署：把应用拆分成为一个一个独立的单个服务，方便自动化部署、测试、运维

总结

Dubbo是SOA时代的产物，而SpringCloud是微服务时代的产物

Dubbo

Dubbo是阿里巴巴公司开源的一个高性能、轻量级的Java RPC（远程过程调用）框架。 致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务（面向服务的架构）治理方案。

节点角色说明：

  • Provider：暴露服务的服务提供方
  • Container：服务运行容器
  • Consumer：调用远程服务的服务消费方
  • Registry：服务注册与发现的注册中心
  • Monitor：统计服务的调用次数和调用时间的监控中心

简单上手

  1. 注册中心使用Zookeeper，先安装Zookeeper

    Zookeeper是Apache Hadoop的子项目，是一个树型的目录服务，支持变更推送，适合作为Dubbo服务的注册中心，工业强度较高，可用于生产环境

    1. linux上必须有jdk环境，因为Zookeeper需要运行在java环境上

    2. 下载zookeeper安装包downloads.apache.org/zookeeper/z…

    3. linux进入到/opt目录，然后新建一个zooKeeper目录

      cd /opt
mkdir zooKeeper

    4. 用xftp将下载好的安装包拖到Linux刚才创建的 /opt/zooKeeper 目录下

    5. 进到zooKeeper目录下，解压安装包

      tar -zxvf apache-zookeeper-3.8.0-bin.tar.gz

    6. 删除安装包

      rm apache-zookeeper-3.8.0-bin.tar.gz

    7. 进入到解压后的安装目录，然后进入配置文件目录

      cd apache-zookeeper-3.8.0-bin/
cd conf/

    8. 将配置文件目录里的zoo_sample.cfg原地拷贝一份，并改名为zoo.cfg，这样配置文件才会生效

      cp zoo_sample.cfg zoo.cfg

    9. 编辑zoo.cfg文件

      vim zoo.cfg

    10. 进入vim编辑器后，将dataDir改成自定义的目录，这里zkdata是自己在安装目录下创建的

      dataDir=/opt/zooKeeper/apache-zookeeper-3.8.0-bin/zkdata

    11. 进入到zookeeper的安装目录下的bin目录，运行zookeeper服务，想停止换成后面跟stop即可

      ./zkServer.sh start

    12. 可以查看运行状态

      ./zkServer.sh status

  2. Consumer服务消费者和Provider服务提供者将来是两个项目，但现在写小案例，就在IDEA中用两个模块代替了

    1. 创建服务提供者Provider模块
    2. 创建服务消费者Consumer模块
    3. 在服务提供者模块编写UserServicelmpl提供服务（将@service注解换成dubbo里的），得在spring中配置dubbo
    4. 在服务消费者中的UserController里远程调用UserServicelmpl提供的服务，注入service对象时用不用@Autowired，改用dubbo的@Reference注解
    5. 将接口提出来，让Controller和Service都去依赖公共的接口
    6. 分别启动两个服务，测试

www.bilibili.com/video/BV1VE… p8

序列化

dubbo内部已经将序列化和反序列化的过程内部封装了，我们只需要在定义pojo类时实现serializable接口即可，一般会定义一个公共的pojo模块，让生产者和消费者都依赖该模块。

地址缓存

注册中心挂了，服务是否可以正常访问？

可以，因为dubbo服务消费者在第一次调用时，会将服务提供方地址缓存到本地，以后在调用则不会访问注册中心。当服务提供者地址发生变化时，注册中心会通知服务消费者。

超时

服务消费者在调用服务提供者的时候发生了阻塞、等待的情形，这个时候，服务消费者会一直等待下去。在某个峰值时刻，大量的请求都在同时请求服务消费者，会造成线程的大量堆积，势必会造成雪崩。dubbo利用超时机制来解决这个问题，设置一个超时时间，在这个时间段内，无法完成服务访问，则自动断开连接。

在@Reference或@service注解里可以设置属性timeout，默认1000毫秒，建议将超时时间配置到服务的提供者身上

重试

如果出现网络抖动，则这一次请求就会失败。Dubbo提供重试机制来避免类似问题的发生，通过retries属性来设置重试次数。默认为2（一共发3次）。

多版本

灰度发布：当出现新功能时，会让部分用户先使用新功能，用户反馈没问题时，再将所有用户迁移到新功能。

dubbo中使用version属性来设置和调用同一个接口的不同版本

负载均衡

这种需要集群，有好多服务提供者，消费者请求服务提供者时具体访问哪个不确定

负载均衡策略(4种)：

  • Random：按权重随机，默认值。按权重设置随机概率。服务提供者给service注解设置height属性，消费者给Reference设置loadbalance="random"
  • RoundRobin：按权重轮询
  • LeastActive：最少活跃调用数，相同活跃数如的随机。
  • ConsistentHash：一致性Hash，相同参数的请求总是发到同一提供者。

集群容错

假如消费者调用失败，会怎样？

在消费者的@Reference注解里指定容错模式，如cluster="failover"

集群容错模式：

  • Failover Cluster：失败重试。默认值。当出现失败，重试其它服务器，默认重试2次，使用retries配置。一般用于读操作
  • Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于写操作。
  • Failsafe Cluster：失败安全，出现异常时，直接忽略。返回一个空结果。
  • Failback Cluster：失败自动恢复，后台记录失败请求，定时重发。
  • Forking Cluster：并行调用多个服务器，只要一个成功即返回。
  • Broadcast Cluster：广播调用所有提供者，逐个调用，任意台报错则报错。

服务降级

即服务提供者上有如广告服务、日志服务、支付服务，当该服务器快被挤爆时，将一些不重要的服务关闭

服务降级方式：(在消费者的Reference注解里添加属性)

  • mock=force:sreturn null表示消费方对该服务的方法调用都直接返回null值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
  • mock=fail:return null表示消费方对该服务的方法调用在失败后，再返回null值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
avatar
文章
阅读
粉丝