别吵，我们直接开始！
前言以前，制作规模小的系统时，使用的是单体体系结构。 在一台服务器上部署上一个APP应用程序和数据库就足够了。
但是现代化互联网公司的业务逐渐扩大，服务逐渐细分，许多服务之间需要通过远程分布式接口调用通信。 也就是说，不同的服务没有部署在同一服务上。 例如，订购服务是a服务，支付服务是另一服务，有同步呼叫和异步呼叫。 此时，我们需要远程调用不同的服务，使用时调用远程服务就像调用本地服务一样，只要部署一个jar包就可以通过this .
重点：RPC 技术一定是今后工作必备基础，熟练掌握其中一种，知道原理，阅读源码，甚至自己手写一个。
1、面试官：公司用的是什么样的RPC框架？ 能给我介绍一下RPC的工作原理吗？问题分析：面试官想知道基础设施是否与我们项目中使用的相同。 同样是最好的。 可以直接得到。 就算不一样，知道另外一个也应该没什么问题。 毕竟，原理技术很相似，说是你最熟悉的之一。
答：RPC是分布式计算的CS模型，其中客户端始终向服务器发出执行某些进程的请求。 服务器接受请求，使用客户端提供的参数，并在计算完成后将结果返回给客户端。
使用最广泛的Spring Cloud，基于Spring Boot特性集成开源行业中的优秀组件，总体上在微服务体系结构中对外提供了服务治理解决方案。
在国内开源框架中，应用比较广泛的阿里Dubbo后来捐赠给了Apache。 既有腾讯的Tars框架，也有Thrift框架，还有基于Thrift二次开发的RPC框架。 例如，美团的Mtthrift。
这些RPC的大致原理基本相同。 这个时候，从面试官那里得到纸和笔，画画说明RPC的原理)
这张图太复杂了，看起来不像在给自己挖洞，也不容易看起来很复杂。
1-5 逐行解释：
当服务集成到RPC中时，当服务(这里的服务是图中的提供商，服务提供商)启动时，通过注册模块，RPC框架注册服务的唯一ID和IP地址、端口信息等调用方(Consumer )想要调用服务时，使用提供商注册时的服务特定ID前往注册中心，查找可以在线调用的服务，并返回IP列表(3.notify部分) 步骤Consumer基于某些策略，如随机or循环从Registry返回的可用IP列表中实际调用服务(4.invoke )。 最后是统计功能。 RPC框架均提供监控功能，监控服务健康状况，控制服务在线扩展和上线(5.count )，有清晰的流程图，有步骤说明，面试人员满意，继续提问其他问题
2、面试官：服务开始时服务基本信息在注册中心注册。 如果服务提供商锁定，注册中心如何知道服务不再可用？ 3358www.Sina.com/服务中断为答：和主动下线
例如，当服务发布时，在重新启动之前主动通知注册中心。 我会重新启动。 流量进来的话，先不要分我。 请让我为另一台机器服务。 重新启动成功后，放入流量进来。 或者，在管理后台手动直接断开机器。 这是心跳检测
主动下线处理停电等服务未正常脱机的情况。 此时，如果注册中心不知道服务已脱机，则调用该服务时会出现问题。 为了避免这种情况，在注册中心添加心跳检测功能。 它将向服务提供者(Provider )进行心跳检测。 例如，每30s发送一次心跳，如果三次心跳的结果没有返回值，则认为服务已脱机，并立即更新消费者的服务列表，告知消费者调用另一台计算机。
心跳检测关于服务端如何挂注册中心感知的问题，你在这个问题上已经结束了吗？ 还有，你给自己挖了个洞成功了。 面试官可能会继续深挖。 服务提供商(提供商)挂注册中心就可以解决，注册中心会不会自己阻止？ 一连三个问题。
3、面试官：注册中心锁定的情况下，比如使用Zookeeper。 如果Zookeeper锁定，是否可以在服务之间进行交互调用？问题分析：首先，注册中心锁定也分为两种情况。 即使数据库锁定，ZK也可以使用。 因为ZK会将注册器列表缓存在缓存中。
其次，ZK本身就是集群。 当一台计算机锁定时，ZK将继续选择群集中的其他计算机作为主计算机提供服务。 整个集群挂起也没有问题。 因为调用方本地缓存从注册中心获取的服务列表。 省略与注册中心的交互，Consumer和Provider采用直接连接方式，这些策略是可配置的。
答：面试是一个自由交流的时间，每一点都有可能被释放出来继续挖掘，刨根问底
总有你覆盖不到的知识盲区，目的不是为难你，是想了解你的技术沉淀深度。 4、面试官：你对 RPC 了解的很透彻，那你能否自己写一个 RPC 框架？可以简答描述下思路也行。答：这个问题，虽然没有自己动手写过，但是我阅读过源码，大致实现思路是这样的。（画图给面试官）
客户端 invoke 方法编写，使用 JDK 的动态代理技术，客户端调用远程服务方法时调用的是 InvocationHandler 的 invoke 方法。客户端 Filter 方法编写，完善的 RPC 框架少不了监控、路由、降级、鉴权等功能。创建 Socket，在 Filter 方法中实现 Client.write 方法，其逻辑为从连接池（ChannelPool）中获取连接，然后将数据写进 Channel。实现数据序列化、压缩，目的减少网络传输的数据量，向服务端发送 request 数据，这里可以使用 Netty 异步通讯框架。服务端收到客户端发过的消息后，从 Channel 中将消息读出来之前，也会先经反序列化解压。请求就到了服务端 Filter 中。请求依次经过监控、鉴权方法。根据客户端传递来的服务信息和参数，通过反射调用相应的业务服务并拿到业务处理结果。然后在 ResponseFilter 中将返回结果写入 Channel。服务端序列化、压缩等，发送给客户端。客户端收到消息后，经过客户端反序列化、解压缩，后交给 ResponseThreadPoolProcessor 线程池处理。ResponseThreadPoolProcessor 收到消息后，就将结果返回给之前的方法调用，整个调用请求就结束了。面试官： 可以可以，确实是看了，这个问题就到这。（面试官心理：虽然目前项目里不会让你真正去写一个 RPC 框架，知其然知其所以然，遇到这类 RPC 相关问题一定能搞定了，项目组正好缺一个这样的人）
深入分析 已经有 http 协议接口，或者说 RestFul 接口，为什么还要使用 RPC 技术？在接⼝不多的情况下，使用 http 确实是一个明智的选择，比如在初创企业，我们不确定业务能顺利开展下去，可能面临随时倒闭，开发人员也不足，这个时候使用简洁高效的技术，先把东西做出来是最明智的选择，无需一步登天。
系统与系统交互较少的情况下，使用 http 协议优点显而易见：开发简单、测试也比较直接、部署方便，利用现成的 http 协议进行系统间通讯，如果业务真的慢慢做大，系统也慢慢扩大，RPC 框架的好处就显示出来 了，⾸先 RPC 支持长链接，通信不必每次都要像 http 一样去重复 3 次握⼿，减少了网络开销。
其次就是 RPC 框架一般都有注册中心模块，有完善的监控管理功能，服务注册发现、服务下线、服务动态扩展等都方便操作，服务化治理效率大大提高。
基于 TCP 协议实现的 RPC，能更灵活地对协议字段进行定制，相比 http 能减少网络传输字节数，降低网络开销（握手）提高性能。实现更大的吞吐量和并发数，但是需要更多的关注底层复杂的细节， 对开发人员的要求也高，增加开发成本。
总结在面试官夺命三连问的攻击下，前三个题目一定要掌握，最后一个加分项徒手写 RPC 深入分析，可以大大拉升面试官对你的好感，只要有亮点，即使其他问题答得不好，那么问题也不大。
RPC 工作原理总结：
Provider：服务提供方，CS 模型中的 Server。Consumer： 调用远程服务服务消费方，CS 模型中的 Client。Registry：服务注册与发现的服务管理中心。Monitor：统计服务的调用次数和调用时间的监控中心。Container：服务运行容器，如 jetty。RPC 执行过程总结：
服务容器负责启动，加载，运行服务提供者。服务提供者在启动时，向注册中心注册自己提供的服务，暴露自己的 IP 和端口信息。服务消费者在启动时，向注册中心订阅自己所需的服务。注册中心返回服务提供者列表给消费者，如果有变更，注册中心将基于长连接推送给数据消费者。服务消费者，从提供这地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另外一台服务调用。服务消费者和提供者，在内存中累计调用次数和调用时间，定时发送一次统计数据到监控中心。不啰嗦，文章结束，期待三连！