说三道四技术文摘-感悟人生的经典句子
说三道四 > 文档快照

从远程调用框架认识Zookeeper

HTML文档下载 WORD文档下载 PDF文档下载
在Hadoop的学习过程中,Zookeeper是让很多初学者困惑的技术,夏俊认为远程调用服务是一个很适合Zookeeper应用的场景,他从自己设计的远程调用服务架构谈起,详细介绍了Zookeeper这一应用场景。

编者按:作为Hadoop的子项目,Zookeeper多数情况下是配合Hadoop的工作,但Zookeeper还有更广泛的应用场景。Zookeeper是Google Chubby的开源实现,主要用来解决分布式集群中应用系统的一致性问题,它能提供基于类似于文件系统的目录节点树方式的数据存储,维护和监控数据的状态变化,做到基于数据的集群管理。本文转载自夏俊的博客,作者从远程调用服务的架构来认识Zookeeper,相信读完本文,对Zookeeper也会有新的认识。以下为文章内容:

远程调用是系统或进程间的通信机制,是分布式系统开发的核心技术。远程调用技术可以将一组计算机系统形成一个网络系统,对外提供整体服务,那么这一群的计算机系统就构成了一个更大型、性能更高的计算机系统。

远程调用服务的架构设计总述

首先我们要深入理解以下几个问题:为什么应用软件服务里需要一个远程调用服务?远程调用服务解决了软件设计中的什么问题?

笔者曾写过一篇关于分布式网站架构设计的文章, 在文章开头就把这个新的网站架构方案和传统的企业软件的B/S架构作了对比,笔者将一个网站里提供业务服务的组件抽象为独立的服务系统,接收用户信息的逻辑部分抽象为前端系统,服务系统和前端系统使用netty这样的通讯组件进行通讯。而到了讲解远程调用服务的框架设计时候,将netty通讯组件进一步抽象为一个通讯独立系统及远程调用服务,这就是为什么要设计远程调用服务的缘起了,远程调用服务会带来了网站架构的升级,如果传统的企业B/S架构为1.0版,前端和业务服务端分离为独立系统则是2.0版,那么引入了远程调用服务网站就是3.0版了,3.0版的架构带来的好处就是可以将N多的前端系统和N多的业务服务端系统融为一个整体,网站的规模会越来越大,提供的服务也会越来越多,这既避免重复造轮子的问题还使得网站规模越来越大。


3.0版网站架构总图

有了远程调用服务,我们可以做到业务级别的集群,例如:一个制造企业,一般都会有采购业务,生产业务、销售业务以及财务业务,按照传统的思路我们都会给每个业务独立开发一个系统,如果引用了远程调用服务,我们可以将这些业务都做成独立的服务,这些服务组成业务集群,而这些服务都是用统一的远程调用服务作为操作的入口,这样前端的调用者可以做到应用的统一。所谓的应用的统一淘宝网站是最典型的代表,我们在一个同一的网站里可以操作各种不同的应用,而不会发生因为应用的不同我们就得重新访问新的地址或者重新登录到另外一个系统里做其他业务的操作。而服务端这边,完全可以摆脱传统的客户端和服务端耦合的开发,增强了整个服务端的专业性和稳定性,这样更易于服务端的扩展性和可维护性。如果服务端之间也需要相互调用也可以通过远程调用服务实现,由于远程调用服务的统一性,这样就避免了服务调用之间报文和调用方式的不统一,规范了整个开发的流程。如果远程调用服务还有负载均衡功能,整个服务集群就变成了一个私有的云,所以说远程调用服务是云计算的重要组成部分,这个说法一点都不为过。

远程调用服务技术原理


远程调用框架

传统的服务调用都是服务提供者和服务调用者的直接调用,从架构图里我们看到这里多了一个远程调用管理组件,远程调用管理组件是一个独立的服务系统,为了保证该系统的稳定性,它也一定是一个分布式的系统,但是这个分布式系统和Web的分布式系统是完全不同的分布式系统。传统Web应用集群是基于HTTP协议的无状态的特点设计的,因为每个HTTP请求都是一个独立的事务,不同请求之间是没有任何关系的,所以我们可以将Web应用部署到不同服务器上,请求不管到了那台服务器,都能正常的给用户提供相应的服务,但是Web应用的session机制是有状态的,所以传统Web集群都是要有session同步的操作,大型网站往往会把session功能抽象为独立的缓存系统,但是这里的远程调用管理组件的集群原理或者说分布式原理是有别于Web应用集群分布式原理的。远程调用管理组件可以当做一个注册中心,它会记录下服务提供者和服务调用者的相关信息,并将这些信息推送给服务提供者或者服务调用者,为了保证系统的执行效率,这些注册信息都是记录在内存里。我们试想下,如果这些注册信息丢失,整个系统将会不可用,因此远程调用管理组件的集群是一种保证数据可靠性和服务提供健壮性的集群,而不是建立在HTTP无状态特性基础上的集群。

我们这里假想下远程调用服务的集群运行场景,我们假如有5台服务器作为远程调用服务运行的服务器,那么每台服务器都必须有注册信息的冗余备份,当服务运行时候其中一台服务器发生了故障,这台故障的服务器上的数据不会丢失,此外集群应该还要有一个检查故障的机制,当发现有台服务器不可用的时候,能及时剔除该服务器,而Zookeeper就是解决这种问题的技术框架。此外除了保证系统的稳定性和可用性外,集群的数据存储方式也是很重要的,前面我讲到集群的数据存储要有一个冗余机制,除了冗余机制还要有一个很适合快速访问和读写的数据模型,而Zookeeper正好包含这种数据模型,所以我设计的远程调用服务是一个很适合Zookeeper应用的场景。

远程调用管理组件还有一个心跳机制,心跳机制的作用是检测服务提供者的健康性及服务提供者是否可用,服务提供者启动时候会将自己的注册信息发送给远程调用管理组件,这个注册信息里包含服务端的IP地址和端口号,远程调用管理组件会启动一个线程,根据定时对这个IP地址和端口号去ping这个IP和端口号对应的应用是否可用,如果不可用远程调用管理组件会反复尝试几次,这个次数和多久检测心跳都是可以配置的,如果反复几次还是不通,那么就认定该服务不可用了。有网友在QQ上问我,为什么不检测服务调用者的心跳,这个完全没必要,调用者是主动方,提供者是被动方,这就好比你访问网站,如果你生病了不去访问了,系统没有必要检查你是否已经生病了。

备案号:鲁ICP备13029499号-2 说三道四 www.s3d4.cn 说三道四技术文摘