从永远到永远-Dubbo+Zookeeper的微服务框架

1. 关于Dubbo

1、是什么

Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。简单的说,dubbo就是个服务框架,如果没有分布式的需求,其实是不需要用的。只有在分布式的时候,才有dubbo这样的分布式服务框架的需求,并且本质上做服务调用,说白了就是个远程服务调用的分布式框架(告别Web Service模式中的WSdl,以服务者与消费者的方式在dubbo上注册)。
Dubbo采用全spring配置方式,透明化接入应用,对应用没有任何API侵入,只需用Spring加载Dubbo的配置即可,Dubbo基于Spring的Schema扩展进行加载。
参考该播主内容

2、Dubbo架构图及调用过程

在这里插入图片描述
调用关系说明:

0 服务容器负责启动,加载,运行服务提供者。

  1. 服务提供者在启动时,向注册中心注册自己提供的服务。

  2. 服务消费者在启动时,向注册中心订阅自己所需的服务。

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

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

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

3、拓展

这里,针对容易产生疑问的地方做一下解释。

1、微服务和分布式系统开发

微服务架构是一种架构思想,其实开发方式本质是分布式系统开发。

2、HTTP与RPC

很多人可能有疑问,那么我们为什么不直接使用HTTP方式调用服务接口呢。
参考该播主

3、HTTP与TCP

参考该播主

这其中会遇到几个问题,其实就是面试会遇到的几个问题:
在这里插入图片描述

2、Zookeeper

1、是什么?

分布式协调技术框架,分布式协调技术:主要解决分布式环境中多个进程之间的同步控制,使其有序访问某临界资源,防止“脏数据”产生。

在这里插入图片描述
zookeeper本质是 分布式锁的实现框架

PS:此图同时有助于理解分布式锁及多线程。

2、分布式锁

在这里插入图片描述
在这里插入图片描述
这里redis等分布式锁与zookeeper虽然都可以实现分布式锁,但是本质是不同的。redis分布式锁的实现只不过是他的一些特性适合做分布式锁。而zookeeper设计初衷就是为了实现分布式锁。
上边那句话可能说复杂了,redis能做分布式锁是因为什么,并不是说他的功能里边就有加锁功能。本质其实就是当操作某数据时,我往redis中存储一个键值对的标志,表明这个玩意被锁住(说是被锁住而已)。其他的线程来操作该数据之前会先根据此键值对的key判断redis中有没有存储一个这样的标志。如果返回值有那么,我就先不操作,如果没有我就加锁操作。就操作上而言跟redis缓存的实现没有区别。

分布式锁实现的三个核心:加锁,解锁,锁超时。
具体实现,自己看redis分布式锁吧,理解了概念代码没啥难的地方。
在这里插入图片描述

当然redis实现分布式锁要注意几个问题:
1)原子性操作,设置锁时同时设置超时时间。
2)避免误删锁,如果超时时间内,业务代码没处理完,删除锁时要通过线程id判断是否是自己的锁。
3)在2的基础上,没处理完业务,就应该继续延长超时时间,通过守护线程处理该部分内容。
通过上边巴拉巴拉扯一顿的目的就是为了说明虽然有些技术也可以实现zookeeper作为服务注册中心的功能,但是很多代码需要我们自己实现,但是zookeeper就不一样了,内部实现了。

3.zookeeper是怎样实现服务的注册和通知的呢?

在这里插入图片描述
显然他也需要存储数据(服务相关信息等),他的结构类似于二叉树。二叉树基于树节点存储数据,zookeeper依靠Znode存储数据。虽然他有存储数据功能,但是不能用作数据库,其规定每个节点存储量不能超过1MB。
在这里插入图片描述
Znode结构:
在这里插入图片描述

如何实现服务的注册与发现:
在这里插入图片描述

4.Zookeeper如何进行集群崩溃恢复-master选举机制

由以上我们能看出,zookeeper服务器如果挂了,大家就都玩完了。所以,zookeeper需要做集群部署。集群部署牵扯到一个问题,就是各个机器间进行数据一致性,一个服务注册到一台zookeeper主机,其他的怎样得到这个注册信息。简单说更新数据时,先更新主节点,再同步到从节点
在这里插入图片描述
1)ZAB实现数据写入

在这里插入图片描述
说到两阶段提交,其实涉及分布式事务,结合分布式事务理解。
在这里插入图片描述
2)ZAB如何实现集群崩溃(服务器时候也是类似的)。
在这里插入图片描述
ZAB崩溃恢复分为三个阶段:
1>选举阶段,任意一台zookeeper服务器带着自己的服务器id和最大ZXID(本地事务ID)向另外某一台发请求。两个ZXID比大小。比自己大,就投票给他。反之,不投票。一轮投票下来统计票数,没票的落选。剩下的接着按此模式投票,知道某节点获取到半数以上票数,他变成准leader,状态变为leading,其他的状态就切换成following。
2>发现阶段,防止网络问题,出现多主节点的问题。相当于再次做一个验证。
3>同步阶段在这里插入图片描述
ZXID:
在这里插入图片描述

5\Zookeeper能用来做什么?

在这里插入图片描述

6.zookeeper实现分布式锁,简单看下就好,一般不用。

基于Znode的几个状态(准确说是基于其中的临时有序节点)实现,观察者模式的存在导致他可以同时创建n个,然后根据锁编号依次获取资源。
在这里插入图片描述

至此理论部分基本结束,应付面试差不多了,以后需要学习再继续12节及以后的部分。
感谢公开课视频:https://www.bilibili.com/video/av34187179/?spm_id_from=333.788.videocard.0

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值