1、什么是 RPC 协议？
RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的，本质上编写的调用代码基本相同。也就是说两台服务器A、B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
参考资料：
深入浅出 RPC - 浅出篇 - 瞬息之间- 博客频道 - ****.NET
2、为什么要使用 RPC 协议？（MARK）
1. 简单：RPC 概念的语义十分清晰和简单，这样建立分布式计算就更容易。
2. 高效：过程调用看起来十分简单而且高效。
3. 通用：在单机计算中过程往往是不同算法部分间最重要的通信机制。
通俗一点说，就是一般程序员对于本地的过程调用很熟悉，那么我们把 RPC 作成和本地调用完全类似，那么就更容易被接受，使用起来毫无障碍。
3、RPC 框架的调用原理？
实现 RPC 的程序一般包括 5 个部分：User、User-Stub、RPCRunTime、Server-Stub、Server。
这里 user 就是 client 端，当 user 想发起一个远程调用时，它实际是通过本地调用 user-stub。user-stub 负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的 RPCRuntime 实例传输到远端的实例。远端 RPCRuntime 实例收到请求后交给 server-stub 进行解码后发起本地端调用，调用结果再返回给 user 端。
4、常见的 RPC 框架有哪些，它们都有什么特点？（MARK）
5、如何选择合适的 RPC 框架？
目前市面上提供的 RPC 框架已经可算是五花八门，百家争鸣了。需要根据实际使用场景谨慎选型，需要考虑的选型因素我觉得至少包括下面几点：
1. 性能指标
2. 是否需要跨语言平台
3. 内网开放还是公网开放
4. 开源 RPC 框架本身的质量、社区活跃度
6、什么是 DUBBO？
DUBBO是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案。
7、DUBBO 与其他 RPC 框架的区别，它有什么优势？（MARK）
8、DUBBO 框架的整体架构？
DUBBO 整体架构可以抽象为：消费者、提供者、注册中心、监控中心 四大部分。服务提供者通过注册服务到注册中心，而消费者通过订阅注册中心的事件，当服务提供者新发布服务到注册中心时，消费者会得到注册中心的提醒。消费者可以通过调用注册中心的服务，从而调用到对应的服务。于此同时，监控中心也会监控到此次调用，从而进行服务调用次数的统计。
9、DUBBO 服务的负载均衡策略？
Dubbo框架内置提供负载均衡的功能以及扩展接口，我们可以透明地扩展一个服务或服务集群，根据需要非常容易地增加/移除节点，提高服务的可伸缩性。Dubbo框架内置提供了4种负载均衡策略，如下所示：
- Random LoadBalance：随机策略，配置值为random。可以设置权重，有利于充分利用服务器的资源，高配的可以设置权重大一些，低配的可以稍微小一些。这是 dubbo 的缺省策略。
- RoundRobin LoadBalance：轮询策略，配置值为roundrobin。
- LeastActive LoadBalance：配置值为leastactive。根据请求调用的次数计数，处理请求更慢的节点会受到更少的请求
- ConsistentHash LoadBalance：配置值为ConsistentHash。一致性Hash策略，具体配置方法可以参考Dubbo文档。相同调用参数的请求会发送到同一个服务提供方节点上，如果某个节点发生故障无法提供服务，则会基于一致性Hash算法映射到虚拟节点上（其他服务提供方）
在实际使用中，只需要选择合适的负载均衡策略值，配置即可，下面是上述四种负载均衡策略配置的示例：
<dubbo:service interface="org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService" version="1.0.0" cluster="failover" retries="2" timeout="100" loadbalance="random"
ref="chatRoomOnlineUserCounterService" protocol="dubbo" >
<dubbo:method name="queryRoomUserCount" timeout="80" retries="2" loadbalance="leastactive" />
</dubbo:service>
上述配置，也体现了Dubbo配置的继承性特点，也就是dubbo:service元素配置了loadbalance=”random”，则该元素的子元素dubbo:method如果没有指定负载均衡策略，则默认为loadbalance=”random”，否则如果dubbo:method指定了loadbalance=”leastactive”，则使用子元素配置的负载均衡策略覆盖了父元素指定的策略（这里调用queryRoomUserCount方法使用leastactive负载均衡策略）。
参考资料：
10、DUBBO 的调用失败策略？
假设我们使用的是单机模式的Dubbo服务，如果在服务提供方（Provider）发布服务以后，服务消费方（Consumer）发出一次调用请求，恰好这次由于网络问题调用失败，那么我们可以配置服务消费方重试策略，可能消费方第二次重试调用是成功的（重试策略只需要配置即可，重试过程是透明的）。
- Failover Cluster模式
配置值为failover。这种模式是Dubbo集群容错默认的模式选择，调用失败时，会自动切换，重新尝试调用其他节点上可用的服务。对于一些幂等性操作可以使用该模式，如读操作，因为每次调用的副作用是相同的，所以可以选择自动切换并重试调用，对调用者完全透明。可以看到，如果重试调用必然会带来响应端的延迟，如果出现大量的重试调用，可能说明我们的服务提供方发布的服务有问题，如网络延迟严重、硬件设备需要升级、程序算法非常耗时，等等，这就需要仔细检测排查了。
例如，可以这样显式指定Failover模式，或者不配置则默认开启Failover模式，配置示例如下：
<dubbo:service interface="org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService" version="1.0.0" cluster="failover" retries="2" timeout="100" ref="chatRoomOnlineUserCounterService" protocol="dubbo" >
<dubbo:method name="queryRoomUserCount" timeout="80" retries="2" />
</dubbo:service>
上述配置使用Failover Cluster模式，如果调用失败一次，可以再次重试2次调用，服务级别调用超时时间为100ms，调用方法queryRoomUserCount的超时时间为80ms，允许重试2次，最坏情况调用花费时间160ms。如果该服务接口org.shirdrn.dubbo.api.ChatRoomOnlineUserCounterService还有其他的方法可供调用，则其他方法没有显式配置则会继承使用dubbo:service配置的属性值。
- Failfast Cluster模式
配置值为failfast。这种模式称为快速失败模式，调用只执行一次，失败则立即报错。这种模式适用于非幂等性操作，每次调用的副作用是不同的，如写操作，比如交易系统我们要下订单，如果一次失败就应该让它失败，通常由服务消费方控制是否重新发起下订单操作请求（另一个新的订单）。
- Failsafe Cluster模式
配置值为failsafe。失败安全模式，如果调用失败， 则直接忽略失败的调用，而是要记录下失败的调用到日志文件，以便后续审计。
- Failback Cluster模式
配置值为failback。失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
- Forking Cluster模式
配置值为forking。并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。
- Broadcast Cluster模式
配置值为broadcast。广播调用所有提供者，逐个调用，任意一台报错则报错（2.1.0开始支持）。通常用于通知所有提供者更新缓存或日志等本地资源信息。
上面的6种模式都可以应用于生产环境，我们可以根据实际应用场景选择合适的集群容错模式。