架构:第七章:基于Dubbo+Zookeeper项目架构

605 阅读7分钟

Dubbo:

简单的介绍一下Dubbo?(Dubbo是什么)

dubbo就是个服务调用的东东。

为什么怎么说呢?

因为Dubbo是由阿里开源的一个RPC分布式框架

那么RPC是什么呢?

就是不同的应用部署到不同的服务器上,应用之间想要调用没有办法直接调用,因为不在一个内存空间,需要通过网络通讯来调用,或者传达调用的数据。而且RPC会将远程调用的细节隐藏起来,让调用远程服务像调用本地服务一样简单。

 

dubbo的 架构 有哪些?

主要有五个角色/核心组件,分为是Container(容器)、Provider(服务的提供方)、Registry(注册中心)、Consumer(服务的消费方)、Monitor(监控中心)。

            

容器

主要负责启动、加载、运行服务提供者

1.服务提供者在启动时:向注册中心注册自己提供的服务;服务消费者向注册中心订阅自己的服务;

2.注册中心返回服务提供者列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者;

3.对于服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另外一台调用;

4.服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心;

 

注册中心:

注册中心 只负责地址的注册和查找,相当于我们的目录服务,只有在容器启动时,服务提供者和调用者与注册中心交互,整个过程,注册中心不参与数据传输,不转发请求,压力较小 (“两不一小”);

注册中心宕机问题:

    注册中心会部署集群

1.如果集群中的任意一台宕机之后,将自动切换到另外一台,不会影响已运行的提供者和消费者;

2.如果集群中所有注册中心全部宕机之后,服务提供者和服务消费者仍能通过本地缓存通讯;   

3.数据库宕机后,注册中心仍能通过缓存提供服务列表查询,但不能注册新服务;

 

监控中心:

监控中心负责统计各服务调用次数、调用时间等,统计先在内存汇总后每分钟一次发送到监控中心服务器,并以报表展示

监控中心宕机不影响使用,只是丢失部分的采样数据;

dubbo-admin可以通过监控中心的可视化界面,进行禁止服务和截止消费者(大量恶意访问的ip);

 

服务提供者:

1.服务提供者出现宕机,如果任意一台宕机,由于服务提供者没有状态,不影响使用;

2.如果所有的服务提供者全部宕机之后,服务消费者应用将无法使用,并无限次重连等待服务提供者恢复;

3.服务提供者出现变更,比如增加新的机器部署,注册中心基于长连接将推送服务提供者信息给消费者;

 

Dubbo在项目中怎么用的?

1.dubbo在项目中主要用来实现不同系统之间的服务调用。

2.由于项目是按照不同的功能分了不同的系统,按照三层架构又分了不同的服务,其中

3.三层架构中的控制层作为服务的消费方,业务层和持久层共同作为服务的发布方。

这样的架构实现了系统的服务化,提高了开发效率,实现了业务的解耦。

 

 

3.Dubbo都支持什么协议?这些协议有什么不同点?项目使用的是什么协议?

Dubbo支持Dubbo协议、RMI协议、hessian协议、Http协议等

    Dubbo协议:缺省协议、采用了单一长连接和NIO 异步通讯、使用线程池并发处理请求,能减少握手和加大并发效率、采用的是Hession二进制序列化、性能较好,推荐使用。  

主要应用于传入传出参数数据包较小(建议小于100K),消费者比提供者个数多,由于是单一连接,因为尽量不要传输大文件。

    RMI协议:采用****JDK标准的RMI协议(基于TCP协议)** **、堵塞式短连接、JDK标准序列化方式、同步通讯。适用于消费者和提供者个数差不多的,可传文件。测试发现偶尔会连接失败,需要重建Stub。

    Hessian协议采用http通讯,采用Servlet暴露服务,多连接短连接的同步传输方式,采用hessian的二进制序列化,适合提供者比消费者多。

    项目中使用的是默认Dubbo协议(其他两种简单的知道就行),因为项目的特点主要是并发大、消费者要比提供者多。

Zookeeper:

简单介绍一下zookeeper?

1.Zookeeper是Apache Hadoop的一个子项目,作为分布式协调作用(类似于我们的大脑),树形的目录结构,支持变更操作,同时也是Dubbo官方推荐的注册中心。

2.Zookeeper之所以能用来作为dubbo的注册中心来使用,主要是应用到dubbo的命名功能。3.在SOA架构、集群和分布式环境下,子项目之间的调用关系会变得越来越复杂,因为需要一个服务器专门给我们管理服务的信息和调节、管理这些服务,让我们的侧重点放在项目中的业务上,因为zookeeper的命名功能就可以充当这样一个服务器。

项目中主要用zookeeper作为Dubbo的注册中心,集中管理所有服务的URL;同时集中的管理集群的配置。

 

Zookeeper的实现原理?(工作原理)

Zookeeper会维护一个类似于标准的文件系统的具有层次关系的数据结构。这个文件系统中每个子目录项都被称为znode节点,这个znode节点也可以有子节点,每个节点都可以存储数据,客户端也可以对这些node节点进行getChildren,getData,exists方法,同时也可以在znode tree路径上设置watch(类似于监听),当watch路径上发生节点create、delete、update的时候,会通知到client。client可以得到通知后,再获取数据,执行业务逻辑操作。Zookeeper 的作用主要是用来维护和监控存储的node节点上这些数据的状态变化,通过监控这些数据状态的变化,从而达到基于数据的集群管理。

 

为什么要用zookeeper作为dubbo的注册中心?能选择其他的吗?

Zookeeper的数据模型是由一系列的Znode数据节点组成,和文件系统类似。

zookeeper的数据全部存储在内存中,性能高

zookeeper也支持集群,实现了高可用;

同时基于zookeeper的特性,也支持事件监听(服务的暴露方发生变化,可以进行推送),所以zookeeper适合作为dubbo的注册中心区使用。

redis、Simple也可以作为dubbo的注册中心来使用。

 

Redis:

用key-value(Hash)来存储数据

主key:服务器名和类型

Map中的key:url地址

Map中的value:过期时间,判断脏数据,脏数据由监控中心删除(要求服务器时间必须相同)

利用redis中的Publish/Subscribe事件通知数据变更

总之,redis作为注册中心来使用的话,支持集群,性能高,但是要求所有服务器的时间必须同步,要求较高。(redis作为注册中心来使用,有的公司也在采用)

Simple

本身就是一个普通的dubbo服务,能减少第三方依赖,不支持集群,不适合生产环境。

 

项目中主要用zookeeper做了什么?(作用)

作为注册中心用;

主要是在服务器上搭建zookeeper,其次在spring管理的dubbo的配置文件中配置(暴露方和消费方都需要配置)