-------------------RPC------------
？RPC接口与HTTP接口相比，有什么优势？
HTTP协议，需要带HTTP请求头，导致传输起来效率或者说安全性不如RPC，特别是微服务里业务请求十分频繁的情况下不适合；
首先就是长链接减少3次握手，不必每次通信都要像http 一样去3次握手什么的，减少了网络开销
其次就是RPC框架一般都有注册中心，具有SOA服务治理，，有丰富的监控管理、发布、下线接口、动态扩展等
第三个来说就是安全性
作用？为什么要应用rpc层呢，一个功能，一套代码下来不就解决了么？
1 灵活部署 2 解耦
订单系统，支付系统，商品系统，用户系统。都是分开部署，单独上线的。
RPC原理？
RPC的真正目的是解耦服务，RPC的原理主要用到了动态代理模式，至于http协议，只是传输协议而已
总结：RPC主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。HTTP主要用于对外的异构环境，浏览器接口调用，APP接口调用，第三方接口调用等。
-------------------dubbo+zk+监控的搭建-------------
？我搭建过，如何搭建？
引用：https://blog.csdn.net/mijichui2153/article/details/81102277
0、搭建java和tomcat环境
一、搭建zookeeper
下载zk软件安装包zookeeper-3.5.3-beta.tar，存放在tomcat目录 /usr/mysoftware/tomcat ，创建建立logs文件夹和data文件夹用于存放日志和数据。修改端口等配置
clientPort使用默认的2181端口即可：
（配集群再另说）。
在进入到bin目录，启动tomcat服务：
二、搭建dubbo监控中心
版本要求：
下载admin软件安装包dubbo-admin-2.5.6.war及以上版本，否则会不支持JDK1.8！
存放在tomcat目录，修改配置dubbo.properties文件指向Zookeeper注册中心的IP地址 ，（说明监控管理中心是直接读的zk，由zk去收集提供者和调用者信息）
然后启动tomcat服务
三、接下来继续生产者和生产者的系统搭建
提供者：
maven引入zkclient包，dubbo包.
启动类加上@EnableDubbo，接口实现类直接用dubbo自带的@Service往注册中心注册提供者接口服务，通过配置向注册中心注册接口服务信息。
调用者：
maven引入zkclient包，dubbo包，提供者接口所在的pom包.
启动类加上@EnableDubbo，业务层直接用dubbo自带的@Reference从注册中心获取提供者接口列表，然后本地调用（底层会以真实地址调用）。
分别把它两放入tomcat启动。
？搭建和使用过程中遇到哪些问题？
1 、监控项目需要更改配置
Java代码
- dubbo.jetty.directory=/home/xx/dubbomitor/dubbo-monitor-simple-2.5.5/monitor
- dubbo.charts.directory=${dubbo.jetty.directory}/charts
- dubbo.statistics.directory=/home/xxx/dubbomitor/dubbo-monitor-simple-2.5.5/monitor/statistics
monitor 这个文件夹需要自己创建的。statistics,charts文件夹，监控项目会自动创建。
2 、项目服务端和客户端增加配置,不然一直找不到服务
statistics 对应的服务端。配置文件中增加
<dubbo:monitor protocol="registry"/>
charts 对应的客户端
<dubbo:monitor protocol="registry"/>
3、zk的端口和tomcat的端口冲突了。如果tomcat先启动了那么zk就无法真正的启动。归根结底：zk的默认端口是8080，这个是和tomcat的默认端口冲突，这回造成每次两者只能启动一个另一个启动不成功。
验证：你直接将tomcat和zk都启动，然后查看端口占用情况“netstat -an |grep 8080”。如下图所示显然是冲突了。
解决办法：在上面vim zoo.cfg 中加上一句
admin.serverPort=8088 #改为没有被占用的端口号
4、如果还是连不上的话关闭防火墙试试。
5、Service用成了spring的
-------------------dubbo-------------
？dubbo底层原理？
图
？Dubbo的作用或优点（为什么要使用dubbo）？
以12306系统为例，平日里的访问量和春运时的访问量是完全不同的。春运时硬件设备容量不足，肯定需要临时租用一些硬件设备动态加入，用完又动态撤下来，不影响服务。dubbo就是其中一种解决方案能动态的、流动性的调度各个服务。
？选dubbo的原因(与cloud比)？
1、Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
2、SpringCloud基于Http调用的方式，更加灵活，但是消息封装臃肿(可以使用gzip压缩)；Dubbo基于RPC调用的方式（但提供者与zk之间是用的netty,scoket->netty(长连接有状态)），使服务就像可以调用自己本地的服务一样调用别人的服务
3、Dubbo 的定位始终是一款 RPC 框架，而 Spring Cloud 的目标是微服务架构下的一站式解决方案.如果公司对效率有极高的要求建议使用 Dubbo，相对比 RPC 的效率会比 HTTP 高很多
(Dubbo缺点是只支持java)
？选cloud的原因(与dubbo比)？
Dubbo 的定位始终是一款 RPC 框架，而 Spring Cloud 的目标是微服务架构下的一站式解决方案
如果公司选择微服务架构去重构整个技术体系，那么
Spring Cloud 是当仁不让之选，它可以说是目前最好的微服务框架没有之一，并且可以断言，将来Dubbo可以很好的整合到Spring Cloud中。
Spring Cloud是一个全家桶。
？dubbo与cloud的相同点和不同点?
引用：https://blog.csdn.net/zhanggqianglovec/article/details/104055255
回答1相同点：
dubbo和spring cloud都是微服务框架。
服务发现：就是不用知道服务的ip端口，通过服务名就能使用服务。
回答2不同点：
1、功能组件范围：Dubbo 关注于服务治理这块并且以后也会继续往这个方向去发展，Spring Cloud 关注的是微服务的全套解决方案。Dubbo的功能包括服务注册发现，远程调用，监控等等。Cloud包括全套组件。
2、服务注册和发现：spring cloud服务服务注册和发现,是Eureka组件，Eureka就是为了服务发现而设计的。Dubbo的服务发现模块基于zookeeper实现，是用来保证分布式一致性的一个软件。不是为了服务发现注册而设计的;
3、调用方式：Spring Cloud 抛弃了 Dubbo 的 RPC 通信，Cloud采用的是基于 HTTP调用 的 REST 方式（当然它也有第二种方式和dubbo类似，即接口实现+注解）， Cloud 的REST 相比 RPC 更为灵活，服务提供方和调用方不存在代码级别的强依赖，这在强调快速演化的微服务环境下显得更加合适。但Dubbo 的 RPC服务调用的性能更好
4、阿里的Dubbo和spring家族的Cloud。
特点比较：
运行流程比较
Dubbo：
SpringCloud：(ribbon可用feign替换，以接口+注解方式替换restTemplate)
-------------------Dubbo负载均衡（需利用zk）-------------
？负载均衡工作原理？
每个服务提供者启动时创建一个父节点（存在则重复用），应用客户端通过读取节点列表获得可用服务器列表，并订阅节点事件。若有服务提供者宕机断开时触发事件，客户端监测到后把该Server从可用列表中删除。若有新增节点，也触发订阅的节点事件，列表+1
图
？负载均衡的作用或优点？
负载均衡作用：高可用。
Zookeeper注册中心作用：当提供者出现断电等异常停机时，Zookeeper注册中心能自动删除提供者信息，当提供者重启时，能自动恢复注册数据，以及订阅请求。
？我搭建过，如何搭建？
？搭建和使用过程中遇到哪些问题？
？负载均衡dubbo与nginx的区别?
dubbo的负载均衡是服务层面（在http调用之前，本地负载），nginx的负载均衡在http请求层面。
dubbo在服务发现这个地方做的更像一个dns（解析别名找到具体提供者地址）。
-------------------zookeeper自带集群（是zk自已，不是客户端）-------------
？Zookeeper自带的特性（是zk自已，不是客户端）？
1、Zookeeper：一个leader，多个follower组成的集群（只要zk集群中有半数以上节点存活，集群就能提供服务）
2、全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的
3、分布式读写，更新请求转发，由leader实施
4、更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
5、数据更新原子性，一次数据更新要么成功，要么失败
6、实时性，在一定时间范围内，client能读到最新数据
-------------------Zookeeper注册中心-------------
？Zookeeper注册中心的原理？
？Zookeeper与eureka的区别？
检测节点服务变化的不同：前者长连接发现变化，就立马事件通知；心跳机制间隔性检测变化，然后通知
-------------------zookeeper分布式锁-------------
？分布式锁工作原理？
主要得益于 ZooKeeper 为我们保证了数据的强一致性.
一个是 保持独占，所有客户端都去创建临时节点，最终成功创建的那个客户端也即拥有了这把锁。
另一个是 控制时序,所有客户端都去创建临时有序节点，临时拥有了这把锁，用完断开连接就释放，全局时序执行下一个。
？zookeeper分布式锁怎么实现的（实现原理）？
答：通过一起去创建节点同一个节点 的方式来实现。每个节点是唯一的，只能有一个成功
所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。（使用临时节点，失效时间容易控制，程序执行完成之后此序列节点消失）
步骤：https://www.cnblogs.com/toov5/p/9899489.html
多个客户端（jvm）同时在Zookeeper上创建同一个相同的临时节点；（zkClient.createEphemeral(lockPath)）
jvm1创建成功时候，jvm2和jvm3创建节点时候会报错，该节点已经存在；（这时候 jvm2和jvm3进行等待）
jvm1执行完毕，释放锁。关闭当前会话连接（就会清除临时节点）。临时节点不复存在了并且事件通知Watcher，jvm2和jvm3继续创建。
？的作用或优点？
-------------------Zookeeper配置中心-------------
？Zookeeper配置中心的原理？
发布与订阅模型，发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。
？的作用或优点，基于Zookeeper实现分布式配置中心有什么好处？
一、答：实时推送稳定性、实效性。
优势
1、多个环境配置集中管理。
2、配置更改，实时推送，jvm环境变量及时生效。
3、依靠配置变更，动态扩展功能，减少二次上线带来的成本。
4、减少开发人员、运维人员修改配置带来的额外开销。
---------以前的-------
？基于Zookeeper-dubbo的实现原理？
答：dubbo是一个分布式框架，远程服务调用的分布式框架,其实现原理是这样的：
使用流程：
第一步：zookeeper先搭建一个注册中心。
第二步：生产者到zk注册中心注册发布服务（发布服务需要使用spring容器和dubbo标签来发布服务。并且发布服务时需要指定注册中心的位置。）
第三步：消费者到zk注册中心订阅服务，zk发现生产者服务变动，会告知消费者，消费者对订阅到的生产者服务进行调用。
Zookeeper注册中心的作用主要就是注册和发现服务的作用。类似于房产中介的作用，在系统中并不参与服务的调用及数据的传输。
？服务提供者暴露一个服务的详细过程？
观察dubbo的启动日志你会发现，dubbo的provider启动主要是以下几个过程：
1.首先provider启动时，先把想要提供的服务暴露在本地。
2.然后再把服务暴露到远程。(需要网络通信,如下)
3.启动netty服务，建立长连接。（注意和rpc的区别，rpc是消费者调服务器;netty是与zk建立长连接）
4.连接到注册中心zk上。
5.然后监控zk上的消费服务。（dubbo-admin监控中心）
dubbo的所有provider把接口服务通过netty长连接，注册到注册中心zk上
？服务消费者消费一个服务的详细过程？
消费者端，首先ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例。
接下来把Invoker转为客户端需要的接口。
？dubbo 负载均衡的实现原理？（本地负载均衡，效率比nginx高，所以不用nginx代理）
dubbo消费者从zookeeper取得了服务器列表之后，会根据配置的负载均衡策略（默认，是随机调用其中的一个），执行RPC调用提供者，就实现了类似负载均衡，到底是不是真的负载，还得看策略。
由dubbo源码里实现的，里面有各种负载均衡策略。
zookeeper自己本身没有负载均衡功能，（但是他的特性可以辅助dubbo实现类似负载均衡的能力）
zookeeper只做服务发现，保存服务配置，然后dubbo中调用的时候，根据后台服务器来做动态均衡
？dubbo 负载均衡策略有几种？
1.random loadbalance
默认,随机调用实现负载均衡，可以对 provider 不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。
2.roundrobin loadbalance
这个的话默认就是轮询调用，均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。
3.leastactive loadbalance
这个就是自动感知机器性能调用，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求。
4.consistanthash loadbalance
一致性 Hash 算法，相同参数的请求一定分发到一个 provider 上去，provider 挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性 Hash 策略。
？Dubbo有几种容错机制（某个机器挂了）？
1.failsafe 失败安全，可以认为是把错误吞掉（记录日志）
2.failover(默认) 重试其他服务器；retries(2)重试的次数，默认为2次---故障转移
3.failback 失败后自动恢复
4.forking forks. 设置并行数
5.Broadcast 广播，任意一台报错，则执行的方法报错，通过cluster方式，配置制定的容错方案
布署存在的问题：
但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。
-----Dubbo------
？什么是RPC框架？
是一种远程过程调用的技术思想。
一、RPC 框架主要用来解决两个问题：
解决分布式系统中，服务之间的调用问题。
远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。
二、调用过程涉及到一个过程和几个概念:（RPC 的两个核心模块是：通讯和序列化透明）
Client：调用端，以本地调用方式调用服务端-------------发起调用，先到本地客服端stub
client stub：接收到调用后，负责将方法、参数等组装成能够进行网络传输的消息体（序列化）；client stub找到服务地址，并将消息发送到服务端。-------本地客户端stub把方法及参数序列化成消息体
server stub：收到消息后进行解码（反序列化）；server stub根据解码结果调用本地的服务；本地服务执行并将结果返回给server stub。server stub将返回结果打包成消息体（序列化）并发送至消费方。----------远程服务端stub收到并把消息体反序列化，再调服务端本地方法，拿到结果再做序列化
client stub接收到消息，并进行解码（反序列化），调用端得到最终结果。----------客户端stub把消息体反序列化拿到结果
？RPC传统有哪些调用方式？dubbo 跟传统的http请求的区别？
一、答：scoket/netty（是scoket封装升级版）/httpClient （注意Restful是短连接无状态，Netty是长连接有状态）
一、答：
dubbo设计之初基本都是考虑内网通讯，安全上基本没什么考虑，比http的安全差远了。
rpc长连接、传输效率较高，适用于内部系统互联；
http短连接，协议标准化且易读，容易对接外部系统，适用于上层业务模块
？Dubbo的核心特性(能做什么)？
高性能 RPC 分布式服务框架（分布式服务框架、高性能透明化的RPC远程调用、SOA服务治理方案）,采用spring的配置方式进行配置，完全透明化的接入应用
一、dubbo的核心特性（核心服务）:
1.RPC长连接调用(序列化透明的远程通讯): RPC 主要解决远程调用问题，让调用者无感知透明，屏蔽了远程的调用细节
2.集群负载均衡（服务器均匀调用）: 访问量越来越大，一台服务器不够用了，那就得多放几台服务器。dubbo就会看哪台服务器比较空闲了，然后让它去处理一下该请求。
3.服务自动注册发现（zk服务管理）: 引入了注册中心zk服务，用来感知所有的服务，所有的服务都注册到这个注册中心里，统一管理使服务调用方能动态的查找服务提供方（某服务机器挂了zk还会切别的），使地址透明，使服务提供方可以平滑增加或减少机器。
4.运行期流量调度（灰度发布）：Dubbo 通过配置路由策略，可以实现灰度发布，一部分使用旧代码服务，一部分使用新的
5.可视化的服务治理和运维（SOA服务治理方案-监控，和3有点重合）：可以通过可视化页面来实时查询一些服务的状态，包括基本信息、健康状况等等，也可以去调节等等，方便来监控和运维
？@reference和@resource的区别？
@reference是dubbo注解。
@resource是spring 的,按变量名（就是id）注入，（@Resource默认按 byName（就是id）注入；@Autowired是注解类的，按byType注入，只能有一个子类，不然会异常）
？dubbo的服务降级目的是什么(服务器压力剧增如何保证服务正常)？降级分几类？降级是怎么操作的？
服务降级目的是为了保证核心服务可用。
降级可以有几个层面的分类：自动降级，人工降级；按照功能可以分为：读服务降级和写服务降级；
1.对一些非核心服务进行人工降级，在大促之前通过降级开关关闭那些推荐内容，评价等对主流程序没有影响的功能
2.故障降级，比如调用的远程服务挂了，网络故障，或者RPC服务返回异常。那么可以直接降级，降级的方案比如设置默认值，采用兜底数据（系统推荐的行为广告挂了，可以提前准备静态页面做返回）等等
3.限流降级，在秒杀这种流量比较集中并且流量特别大的情况下，因为突发访问量特别大可能导致系统支撑不了。这个时候可以采用限流来限制访问量。当达到阈值时，后续的请求被降级，比如进入排队页面，比如跳转到错误页面（活动火爆，请稍后重试）
Dubbo的降级方式：Mock (人工降级的话mock到不再弹出推荐内容，故障和限流分别mock向一些静页面和请稍后重试页)
实现步骤
1.在client端创建一个testmock类，实现对应的IGphello的接口（需要对哪个接口进行mock，就实现哪个）名称必须以mock结尾
2.在client端的xml配置文件中，添加如下配置，增加一个mock属性指向创建的testmock
3.模拟错误（设置timeout）模拟超时异常，运行测试代码即可访问到testmock这个类，当服务端故障解除以后，调用过程将恢复正常
？配置优先级别是怎么样的（以timeout为例）？
1.以timeout为例，显示了配置的查找顺序，其他retries，loadbalance等类似。
（1）方法级优先，接口级次之，全局配置在次之
（2）如果级别一样，则消费方优先，提供方次之
（3）其中，服务提供方配置，通过URL经由注册中心传递给消费方
2.建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。
？SpringBoot与Dubbo整合的三种方式？
目的都是把服务提供者或消费端信息（暴露或提供哪个类），zk信息，监控中心配置注入到Dubbo容器里
1、application.properties中配置自动扫配置包路径等，因为集成了dubbo的所有属性，只需要赋值就行。duboo自带的@Service注解来暴露服务，使用@Reference来引用服务（启动类里要加@EnableDubbo来自动扫配置包路径下的带@Service的类发布服务）
2、引入dubbo.xml配置文件，保留Spring的方式，启动类中要通过 @ImportResource 注解引入配置xml，服务dubbo.xml及提供者provider.xml，（服务方暴露服务有两种方式：1）@Service注解只能暴露整个类服务 2）dubbo.xml配置里能指定暴露某类某个方法）
3、使用注解API的方式（注解类配置类），比如***Config 注解类的配置主要有三点：①注解类加注解@Configuration；②每个注解项添加@Bean注入到容器中；③准确使用注解API。定义完注解类之后，还需要配：@DubboComponentScan注解指定dubbo扫描配置类路径，这里值配你要配置所在路径就好。
----- zookeeper------
？Zookeeper的作用？
分布式的注册中心，通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务名对应关系从列表中删除(集群是多个机器的ip对应一个服务名)，如果无服务机器存活会通知消费者。
优点：
1.负载均衡，为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；
2.资源同步，单单有负载均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；
3.命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布（serviceName和URL地址分别就是持久节点和临时节点，临时节点是可以频繁变更IP这些的）
2.还有分布式锁，Mast选举等
