1.说一下Dubbo的服务模型：
首先dubbo分为服务提供端、注册中心、服务消费端和监控中心。工作流程大致是这样的，当服务提供端启动的时候，服务容器会向注册中心（zk）注册相关服务，同时服务消费端在启动后，会向注册中心拉去服务列表并缓存在消费端，这样在服务消费端不会每次发起请求，都要从注册中心找服务，同时为保证服务提供端与消费端服务的幂等性，dubbo将服务提供端和服务消费端都是以长连接的机制与注册中心连接（其实是发送一个数据很小的心跳包），这样就保证了服务的注册与发现功能。
补充：具体步骤如下：
0、服务容器负责启动、加载，运行服务提供者 1、服务提供者在启动时，向注册中心注册自己要提供的服务 2、服务消费者在启动时，在注册中心订阅自己所需要的服务。 3、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者 4、服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，在选另一台调用。 5、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到控制中心。
2.如果zookeeper宕机，服务消费方是否能够成功调用服务提供方的服务？
首先在生产环境中zookeeper一般是采用集群的方式提供注册中心服务，这样避免了单点故障的发生（zookeeper集群采用选举的机制，推选出一个master节点，其他为备份节点，集群数量一般为奇数台），如果所有zookeeper宕机了，在服务提供方没有服务变动的前提下，消费方式可以正常调用服务的，因为此时消费方在本地内存已经缓存了服务提供方的服务列表。
3.如果一个接口被多次实现，并将实现注册到zookeeper下，如何保证消费方调用指定的接口实现？
可以使用group服务分组或者version版本来实现。 比如当一个接口有多种实现时，可以用group区分：
此外，dubbo消费者也可以设置为：消费任意一个group的服务。当一个接口的实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用
`
<dubbo:service interface="com.foo.BarService" version="1.0.0" />
<dubbo:service interface="com.foo.BarService" version="2.0.0" />
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" /> 此外，消费者消费服任意版本的服务时： <dubbo:reference id="barService" interface="com.foo.BarService" version="*" /> ` 另外 接口升级时，要注意方法：
- 在低压力时间段，先升级一半的提供者为新版本；
- 再将所有的消费者升级为新版本；
- 然后将剩下的一半提供者升级为新版本；
4.dubbo 底层通信协议
Dubbo支持dubbo、http、webservice、redis、hessian、thrift等多种协议。我们一般默认使用dubbo协议。它适合运用的场景为常规远程服务方法调用。但是不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况 同时zookeeper不是dubbo的唯一注册中心选择，我们同时还可以选择redis、eureka等其他第三方组件
