什么是Dubbo?谈谈你对Dubbo的理解
Dubbo是阿里巴巴开源的,基于Java的高性能RPC远程调用分布式服务框架,提供了高性能和透明化的远程服务调用方案,以及SOA服务治理方案。
这也是为什么我们需要用到Dubbo的原因,随着服务化的进一步发展,服务越来越多,服务之间的调用和依赖关系也越来越负载。传统的单一应用架构、垂直应用框架满足不了要求,诞生了SOA。Dubbo也这样产生了。
核心部分包括:
- 远程通讯:提供多种基于长连接的NIO框架抽象封装,包括多种线程模型、序列化,以及“请求-相应”模式的信息交换方式。
- 集群容错:基于接口方法的透明远程调用,包括多协议支持、负载均衡、动态配置等集群支持。
- 自动发现:基于注册中心服务目录,使服务消费方能动态查找服务提供方,使地址透明。
-
什么是SOA服务治理方案?
SOA:面向服务的架构,是一种设计方法,包括多个服务,服务之间通过相互依赖关系提供一系列的功能。
特点:有序 高效 复用 -
SOA和微服务的区别?
SOA组件大块业务逻辑(粗粒度),微服务组件单独、小块业务逻辑(细粒度)。
SOA通常松耦合,微服务总是松耦合。
SOA着重*管理,微服务去中性化管理。
SOA轻量级通信,微服务企业服务总线充当服务之间通信的角色。
为什么使用Dubbo?
1.(从产业现状说)因为是阿里的开源项目,现在国内外有很多互联网公司都在使用,这已经经过了很多线上考验。内部使用了ZooKeeper、Netty,保证了高性能高可用性。
2.(从应用场景说)使用Dubbo可以将核心业务提取出来,作为独立的业务,逐渐形成稳定的服务中心,用于提高业务复用灵活扩展,应用就可以更好的相应多变的市场需求。
3.(从分布式说)分布式架构可以承受更大规模的并发流量。
除了Dubbo,你还用过哪些Rpc框架?
- Thrift:用来进行可扩展且跨语言的服务的开发。
- gRPC:Google开发。
- Spring Cloud:基于Spring Boot,提供搭建分布式系统以及微服务常用的工具。
分布式系统的CAP定理了解吧?
- C:一致性,所有节点访问同一份最新的数据副本。
- A:可用性,非故障的节点在合理的时间内返回合理的响应,不出现错误或者超时。
- P:分区容错性,分布式系统出现网络分区的时候仍然能对外提供服务。
- 在前提是系统发生了分区的情况下,CAP只能满足CP或者AP。但是没有发生分区情况,节点间网络通信正常,不存在P,可以同时保证C和A。
说说你这项目对CAP定理是如何实现的?
因为我这个RPC项目是使用了ZooKeeper作为其注册中心,所以保证了CP。ZooKeeper任何时刻对其访问请求都能得到一致性的数据结果,同时系统对网络分割具有容错性,但是它不能保证每次服务的可用性。
在实际情况下,使用ZooKeeper获取服务列表时候,如果zk正在选举或者zk集群中半数以上的机器不可用,那么将无法获取数据,因此,zk不能保证可用性,即只实现了CP。
那如果你想实现AP,该如何实现?/ 谈一谈CAP的实际案例?
使用Eureka作为注册中心,Eureka保证的是AP,它在设计的时候就是首先保证可用性,因为在Eureka中不存在什么Leader节点,每个节点都是一样平等的。因此不同于ZooKeeper,Eureka不会出现选举过程中或者半数以上的机器不可用就是不可用的情况。Eureka保证即使大多数节点挂掉也不会影响正常服务,只要一个节点是可用就可以。
Nacos不仅支持CP,也支持AP。(原理待扩充)
你的项目中用到了ZooKeeper,谈一谈你对这个的理解 / ZooKeeper相关问题
ZooKeeper是什么?
ZK是一个开源的分布式协调服务,设计目标是将那些复杂且容易出错的分布式一致性服务(C)封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用。
ZK为我们提供一系列高可用、高性能、稳定的分布式数据一致性解决方案。
ZooKeeper的特点?
- 顺序一致性:同一客户端发送的事务请求,按照严格的顺序被应用到ZK中。
- 原子性:所有的事务请求在整个集群上所有机器的处理结果都是一致的,要么都成功应用了某个事务,要么都没有应用。
- 单一系统映像:无论客户端连到哪一个ZK服务器上,其看到的服务端数据类型都是一致的(C)。
- 可靠性:一旦一次更改请求被应用,更改的结果就会被持久化,知道下一次更改所覆盖。
ZooKeeper的应用场景?/ 你知道哪些地方使用了ZooKeeper嘛?/ ZooKeeper都有哪些功能?
ZK经常被用来实现诸如:数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列、统一配置管理等功能。(加粗的必须记下,其它的尽量多记)
- 命名服务:可以通过ZK的顺序节点生成全局唯一ID。
- 数据发布/订阅:通过Watcher机制方便实现数据发布/订阅。当把数据发布到ZooKeeper被监听的节点上,其它机器可以通过监听ZK上节点的变化来实现配置的动态更新。
- 分布式锁:创建唯一节点获取分布式锁,获得锁的一方执行完相关代码或者挂掉后就释放锁。分布式锁的实现也需要用到Watcher机制。
- Master选举(主节点选举):主节点挂掉之后可以从备用的节点开始新一轮的选举选出主节点。ZK可以协助完成这个过程。
- 统一配置管理:在一个集群中,所有的节点配置信息是一致的,满足CP的ZK当然可以运用到分布式系统配置文件管理和同步中。
*的开源项目也用到了ZK,如Kafka、Hadoop、Hbase等。
ZooKeeper细节问题
(待扩充)