dubbo和zookeeper实现微服务的内在原理

dubbo和zookeeper怎样实现session共享（在消费端）

我们的消费者只有一个模块，所有的请求首先都是进入这个模块里面，生产者有多个模块，session都在消费者这个action里面，所有的请求都是首先进入这个项目里面，我们的生产者有多个模块。如果有多个消费者的情况下，会存在session共享问题，我们可以将session的id作为key值，用户对象作为value值存储到redis里面。当每次发送的请求的时候，拿着浏览器的session的id去redis里面取，如果能取到，证明用户已经存在，如果不能取到，就重新登录。

选用dubbo+zeekeeper的理由

实现了分布式部署，如果不用的话，传统的项目就是action>servcie>dao,有三部分的请求，单个儿tomcat，用了dubbo+zookeerper后，分成了消费者和生产者，划分成不同的模块，有几个模块就有几个tomcat，大大降低了tomcat的压力，而且后期随着访问量的增加，我们可以不断的增加生产者，每个单个web服务节点者所受到的压力明显降低。

生产者和消费者之间的交互方式

dubbo首先向zookeerper暴露端口，消费者向它们这边订阅服务通过zookeerper，消费者发送请求，zookeerper用来调度，调度的方式有三种，轮循，随机，把这些请求都拿给生产者，如果其中一个生产者挂掉，如果有新的生产者，会把请求分发给新的生产者。

dubbo底层原理

生产者跟消费者之间相当于长连接长请求，传统的request请求，response响应，请求一次，响应一次，开关一次，dubbo是基于 tcp/ip协议的，其他的源码闲的时候，基本上通过maven来看过没有刻意的去了解，因为平时这个业务开发状况很繁琐。

zookeeper的主要作用

dubbo是把项目实现分离，分为消费端跟服务端，在消费者这边的配置文件中添上zookeeper地址，让它连上zookeeper，每个服务端都暴露一个端口给zookeeper，这样就实现服务端在zookeeper中注册，消费者发送请求给zookeeper，zookeeper接收请求，zookeeper再分发给这些服务端。