“Http协议和RPC协议有什么区别？”最近很多人问我这个问题，他们都不知道怎么回答。今天我们就来了解一下这个问题的高手回答。另外，我把文字版本的内容整理到了一个15W字的面试文档里了。大家可以看文章尾端领取。下面看看高手的回答高手：这个问题我想从三个层面来回答。从功能特性来说。http是一个属于应用层的超文本传输协议，是万维网数据通信的基础，主要服务在网页端和服务端的数据传输上。RPC是一个远程过程调用协议，它的定位是实现不同计算机应用之间的数据通信，屏蔽通信底层的复杂性，让开发者就像调用本地服务一样完成远程服务的调用。因此，这两个协议在定位层面就完全不同。其次，从实现原理来说。http协议

13|优雅关闭：如何避免服务停机带来的业务损失？我们在RPC架构下，需要考虑当服务重启时，如何做到让调用方系统不出问题。当服务提供方要上线时，一般是通过部署系统完成实例重启，在这个过程汇总，服务提供方不会事先告诉调用方哪些实例会被重启，从而让调用方切换流量。而对调用方来说，它也无法预测服务提供方哪些实例会重启，因此负载均衡还是有可能降正在重启的实例挑选出来，这样导致请求被分发到正在重启的服务实例中，造成调用方无法拿到正确的响应结果。在服务重启的时候，对于调用方来说，有以下2种情况：调用方发请求前，目标服务已经下线。对于调用方来说，跟目标节点的连接会断开，这时调用可以立刻感知到，并在其健康列表中

13|优雅关闭：如何避免服务停机带来的业务损失？我们在RPC架构下，需要考虑当服务重启时，如何做到让调用方系统不出问题。当服务提供方要上线时，一般是通过部署系统完成实例重启，在这个过程汇总，服务提供方不会事先告诉调用方哪些实例会被重启，从而让调用方切换流量。而对调用方来说，它也无法预测服务提供方哪些实例会重启，因此负载均衡还是有可能降正在重启的实例挑选出来，这样导致请求被分发到正在重启的服务实例中，造成调用方无法拿到正确的响应结果。在服务重启的时候，对于调用方来说，有以下2种情况：调用方发请求前，目标服务已经下线。对于调用方来说，跟目标节点的连接会断开，这时调用可以立刻感知到，并在其健康列表中

15|熔断限流：业务如何实现自我保护？为什么我们的服务需要自我保护？RPC是解决分布式系统通信问题的一大利器，它会面临高并发的场景，这意味着我们提供服务的每个服务节点都有可能由于访问量过大而引起一系列的问题，例如业务处理耗时过长、CPU利用率过高、频繁FullGC以及服务进程直接宕机等，在生产环境中，我们要保证服务的稳定性和高可用性，这就需要业务进行自我保护，从而在高访问量、高并发的场景下，应用系统依然稳定，服务依然高可用。使用RPC时，业务如何实现自我保护？可以在服务提供方做限流操作，在服务调用方做熔断操作。熔断是调用方为了避免在调用过程中，服务提供方出现问题的时候，自身资源被耗尽的一种保护

15|熔断限流：业务如何实现自我保护？为什么我们的服务需要自我保护？RPC是解决分布式系统通信问题的一大利器，它会面临高并发的场景，这意味着我们提供服务的每个服务节点都有可能由于访问量过大而引起一系列的问题，例如业务处理耗时过长、CPU利用率过高、频繁FullGC以及服务进程直接宕机等，在生产环境中，我们要保证服务的稳定性和高可用性，这就需要业务进行自我保护，从而在高访问量、高并发的场景下，应用系统依然稳定，服务依然高可用。使用RPC时，业务如何实现自我保护？可以在服务提供方做限流操作，在服务调用方做熔断操作。熔断是调用方为了避免在调用过程中，服务提供方出现问题的时候，自身资源被耗尽的一种保护

17|异步RPC：压榨单机吞吐量在我们知道RPC框架基础知识后，我们需要从RPC框架整体性能去考虑问题，例如怎么提升RPC框架的性能、稳定性、安全性、吞吐量，以及如何在分布式的场景下快速定位问题等。影响RPC调用吞吐量的根本原因是什么？处理RPC请求比较耗时，并且CPU大部分时间都在等待而非去计算，从而导致CPU利用率不高。RPC请求的耗时大部分是业务耗时，比如业务逻辑中有访问数据库执行慢SQL的操作，所以我们要看怎么能提升业务逻辑处理。要提升吞吐量，关键就两个字：异步。服务调用端怎么异步？对于调用端来说，向服务端发送请求消息与接受服务端发送过来的响应消息，这两个处理过程是两个完全独立的过程，

17|异步RPC：压榨单机吞吐量在我们知道RPC框架基础知识后，我们需要从RPC框架整体性能去考虑问题，例如怎么提升RPC框架的性能、稳定性、安全性、吞吐量，以及如何在分布式的场景下快速定位问题等。影响RPC调用吞吐量的根本原因是什么？处理RPC请求比较耗时，并且CPU大部分时间都在等待而非去计算，从而导致CPU利用率不高。RPC请求的耗时大部分是业务耗时，比如业务逻辑中有访问数据库执行慢SQL的操作，所以我们要看怎么能提升业务逻辑处理。要提升吞吐量，关键就两个字：异步。服务调用端怎么异步？对于调用端来说，向服务端发送请求消息与接受服务端发送过来的响应消息，这两个处理过程是两个完全独立的过程，

19|分布式环境下如何快速定位问题？分布式环境下定位问题有什么难点？分布式环境下定位问题的难点在于，各子应用、子服务之间有复杂的依赖关系，我们有时很难确定是哪个服务的哪个环节出现的问题。如果要通过日志来排查问题，就需要对每个子应用、子服务逐一进行排查，很难一步到位。在分布式环境下如何快速定位问题？有两种方式：借助合理封装的异常信息借助分布式链路跟踪RPC框架打印的异常信息中，需要包含定位问题所需要的异常信息的，比如哪些异常引起的问题（如序列化问题或网络超时问题），是调用端还是服务端出现的异常，调用端与服务端的IP是多少，以及服务接口与服务分组是什么等等。异常的示意图如下所示。一款优秀的RPC框

19|分布式环境下如何快速定位问题？分布式环境下定位问题有什么难点？分布式环境下定位问题的难点在于，各子应用、子服务之间有复杂的依赖关系，我们有时很难确定是哪个服务的哪个环节出现的问题。如果要通过日志来排查问题，就需要对每个子应用、子服务逐一进行排查，很难一步到位。在分布式环境下如何快速定位问题？有两种方式：借助合理封装的异常信息借助分布式链路跟踪RPC框架打印的异常信息中，需要包含定位问题所需要的异常信息的，比如哪些异常引起的问题（如序列化问题或网络超时问题），是调用端还是服务端出现的异常，调用端与服务端的IP是多少，以及服务接口与服务分组是什么等等。异常的示意图如下所示。一款优秀的RPC框

1.前言本文章是笔主在声哥的手写RPC框架的学习下，对注册中心的一个拓展。因为声哥某些部分没有保留拓展性，所以本文章的项目与声哥的工程有部分区别，核心内容在Curator的注册发现与注销，思想看准即可。本文章Git仓库：zko0/zko0-rpc声哥的RPC项目写的确实很详细，跟学一遍受益匪浅：何人听我楚狂声的博客在声哥的项目里使用Nacos作为了服务注册中心。本人拓展添加了ZooKeeper实现服务注册。Nacos的服务注册和发现，设计的不是非常好，每次服务的发现都需要去注册中心拉取。本人实现ZooKeeper注册中心时，参考了Dubbo的设计原理，结合本人自身想法，添加了本地缓存：Clie