一、说下Dubbo在项目中的应用
在项目中是dubbo结合zookeeper实现了分布式部署。
dubbo是阿里巴巴开源项目，基于java的高性能rpc分布式服务框架，现已经是apache开源项目。dubbo把项目分为服务提供者和服务消费者，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，从而提高业务复用。
zookeeper是dubbo的提供者用于暴露服务的注册中心，起一个调度和协调的作用。
1、注册中心zookeeper
使用前，先搭建个注册中心，使用的是dubbo推荐的zookeeper。进入conf下，复制zoo_sample.cfg命名为zoo.cfg，修改相关配置（dataDir，dataLogDir以及server）。
2、provider.xml
新建dubbo-provider.xml配置服务提供者。通过dubbo:application配置提供方应用名，dubbo:registry配置注册中心地址，dubbo:protocol配置协议和端口号，以及dubbo:service声明需要暴露的服务接口。
3、consumer.xml
新建dubbo-consumer.xml配置服务消费者。通过dubbo:application配置消费方应用名，dubbo:registry配置注册中心地址，以及dubbo:reference生成远程服务代理。
4、provider.xml参数调优
考虑到dubbo的健壮性和性能，我们对它的参数进行调优。通过dubbo:protocol的threadpool="fixed" threads=200来启用线程池，以及dubbo:service的connections=5来指定长连接数量。
5、dubbo集群
配置dubbo集群来提高健壮性和可用性。dubbo默认的集群容错机制是失败自动切换failover，默认重试2次，可以通过（dubbo:service或dubbo:reference的）retries设置重试次数。dubbo默认的负载均衡策略是随机random，按权重设置随机概率。
6、直连测试
我们写完dubbo的提供者之后，为了测试服务接口的正确性，会进行直连测试。首先，在提供者端，将dubbo:registry的register设置为false，使其只订阅服务不注册正在开发的服务；然后，在消费者端，通过dubbo:reference的url指向提供者，进行直连测试。
*7、所谓dubbo集群（被动说）
所谓dubbo集群就是dubbo的服务部署多份，在不同的机器或同一台机器的不同端口号，从而在启动时可以向注册中心注册服务，这样结合dubbo的集群容错策略和负载均衡策略来提高可用性。
1、介绍下dubbo和zookeeper
2、dubbo+zookeeper怎样实现session共享（在消费端）？
3、为什么用dubbo+zookeeper？
4、生产者和消费者时怎么交互的？
5、你看过dubbo底层吗？
6、zookeeper的作用？
1、介绍下dubbo和zookeeper
（1）dubbo和zookeeper简介
dubbo是阿里巴巴开源项目，基于java的高性能rpc分布式服务框架，现已经是apache开源项目。dubbo把项目分为服务提供者和服务消费者，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，从而提高业务复用。
zookeeper是dubbo的提供者用于暴露服务的注册中心，起一个调度和协调的作用。
（2）dubbo通信方式
dubbo通信方式采用长链接方式，所以当spring启动后链接就接通，dubbo的消费者和生产者就可以直接调用。dubbo基于tcp/ip协议，交互性能非常高，支持匿名传参、隐式传参、泛化调用。
当时是为了解决单个服务器站点的压力，将项目拆分成页面+controller属于消费者，service+dao属于生产者，所有生产者暴露的端口都注册在zookeeper里面，这时候，消费者要调用生产者去zookeeper中取就可以了。所以我们部署了多套生产者，所有消费者的请求可以由多个生产者去提供，具体由哪个生产者提供可以由zookeeper的配置去决定。
（3）dubbo框架的5个核心组成部分
dubbo框架有5个核心组成部分，分别是
3.0 容器container，它的作用是用来充当容器来加载、运行服务提供者
3.1 提供者provider，它的作用是为消费者提供数据
3.2 注册中心registry，它的作用是用来注册和发现服务
3.3 消费者consumer，它的作用是调用远程提供者提供的服务
3.4 监控中心monitor，它的作用是用来统计服务的调用次数以及调用时间
（4）dubbo的集群容错机制和负载均衡策略
配置dubbo集群来提高健壮性和可用性。dubbo默认的集群容错机制是失败自动切换failover，默认重试2次，可以通过（dubbo:service或dubbo:reference的）retries设置重试次数。dubbo默认的负载均衡策略是随机random，按权重设置随机概率。
2、dubbo+zookeeper怎样实现session共享（在消费端）？
我们的消费者只有一个模块，所有的请求首先都是进入这个模块里面，生产者有多个模块，session都在消费者这个action里面。如果存在多个消费者的情况下，会存在session共享问题，我们可以将session的id作为key值，用户对象作为value值存储到redis。当每次发送请求的时候，拿着浏览器的session id去redis取，如果能取到，表示用户已存在，如果不能取到，就重新登录。
3、为什么用dubbo+zookeeper？
（1）实现了分布式部署，如果不用的话，传统的项目就是action > service > dao，有三部分请求，单个tomcat，用了dubbo+zookeeper之后，分成了消费者和生产者，划分成不同的模块，有几个模块就有几个tomcat，大大降低tomcat的压力，而且后期随着访问量的增加，我们可以不断的增加生产者，每个单个web服务节点者所受到的压力明显降低。
（2）dubbo基于tcp协议高效的。dubbo和其他分布式的比较：用webservice,但他的效率不高，基于soap协议；用restful形式的服务http+json，但后来一想，服务太多，服务之间调用关系混乱；httpclent是基于http协议的，效率低，他传输的是json，它是短链接，他不能实现分布式部署。
4、生产者和消费者时怎么交互的？
dubbo首先向zookeeper暴露端口，消费者通过zookeeper订阅服务，消费者发送请求，zookeeper用来调度，调度的方式有两种，轮询和随机。把这些请求都拿给生产者，如果其中一个生产者挂掉，有新的生产者，会把请求分发给新的生活者。
5、你看过dubbo底层吗？
生产者跟消费者之间相当于长连接长请求，长连接我个人理解就是，消费者和生产者之间修通了一个水管，一但spring容器项目一启动，dubbo生产者和消费者之间就接通了，它一直保存接通状态，所以它传一个对象，性能是非常高的，多半是基于tcp协议，tcp协议属于交换机层，性能比较高。传统的分布式，采用的是http协议，请求一次，响应一次。相当于喝水时，一种是系统之间修通一个水龙头随时喝随时有，一种是接一杯喝一杯。
其他的源码闲的时候，基本上通过maven来看过没有刻意的去了解，因为平时这个业务开发状况很繁琐。
6、zookeeper的作用？
zookeeper作用是注册和发现服务。
dubbo是把项目实现分离，分为消费端跟服务端，在消费者这边的配置文件中添上zookeeper地址，让它连上zookeeper，每个服务端都暴露一个端口给zookeeper，这样就实现服务端在zookeeper中注册，消费者发送请求给zookeeper，zookeeper接收请求，zookeeper再分发给这些服务端。