从远程调用框架认识Zookeeper.doc

从远程调用框架认识Zookeeper Zookeeper架构设计Hadoop远程调用分布式 摘要：在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台服