【详解Zookeeper一、】前提框架演变

前言

#最近公司在项目上使用了Duboo和zookeeper解决了分布式项目的远程调用问题，还有服务内的调用。在说zookeeper和dubbo之前必须有必要说一下什么是分布式项目。什么是集群？（简单的介绍一下）

传统的项目

#在最初的时候我们使用的是3层的项目，也是就是分为web、service 、dao。也就是下面的图形，如果你的框架是web项目，那么是打包到tomcat上的。初期的你的用户量可能是300 ，对于tomcat来说还是可以承受的，但如果访客量增加了10000，那么这个时候你如何做？

两个tomcat的情况

tomcat的并发量在500，你的解决方案可以使用500个并发，而这个时候的两个tomcat干的活相当于是集群的概念，也就是你一台服务器承受不住，那么使用两台服务器一起承担责任一起完成（首先针对于zookeeper和dubbo来说先不考虑单点登录session共享问题）

集群

#首先用大白话说明什么是集群：你可以把集群认为是干相同事情的一个东东，如果跟生活联系起来你可以理解为是一个碗，这个碗使用来承载我们的事物，例如你再吃饭的时候肯定不会用锅吃吧，你会把他放到碗里面，假如放到了4个碗里面，那么这4个碗做的工作是一样的，只是在减轻你们家锅的压力而已。他们干的活是一样的，都是用来承载你的饭菜

假如并发100000

假如并发到了10000我感觉你也不会再去扩充你的服务器了吧，及时你有钱也不能这么做，因为需要解决各种session共享问题，所以这个时候出来了一个新词叫做分布式，他的概念的意思就是把系统给拆分，最开始大家都在一起，假如A模块访问量特别大，但是我B模块根本没有访问量，但是由于AB是一体的所以都需要承受在一台服务器上，所以我们让A和B的模块进行分离，然后把A模块放到一个服务器上，把B模块放到一个服务器上，这个时候假如A模块承受量非常大，但是我们就放到两天服务上，用集群的概念完成。在这个架构里用到了分布式和集群两个概念

分布式

集群和分布式可以理解为是兄弟，只是各自干的事情正好相反而已，集群是干的相同的事情，而分布式干的是不同的事情，例如上图中的例子，我们把各个模块分开了，他们之间都是干的不同的事情，这样就减少了压力

冗余代码

前面的方案感觉挺好的，及用了分布式也用了集群感觉压力应该不会特别大了，但是出现了另一个问题，冗余代码，假如A系统需要写订单查询方法，B系统也要写订单方法，那么他们必须各自模块都写一遍，所以这个时候出现了冗余代码，解决方案是使用SOA框架，让service层在一起，web层在一起

服务之间如何调用

当看到这个图的时候你有没有相关服务之间应该如何去调用呢？你的service层如何调用web层？这个就使用到了Dubbo和zookeeper进行服务之间的注册和调用，简单的介绍就是Dubbo是调用，zookeeper是更好的让我们项目中接口的管理。所以他们两个搭配非常棒~

下一篇Zookeeper初始