hfut_zhanghu的博客

一、概述 本人最近在开发一款 RPC， 前期看了 binder 机制，并且在极客时间学习了 RPC 的原理，所以整理了其中的内容，后期还会学习一下微软开发的 com 接口，也欢迎一起学习讨论。 如果想学习 binder 的内容，也欢迎学习留言。 RPC 的全称是 Remote Procedure Call，即远程过程调用。功能主要有两个：屏蔽远程调用跟本地调用的区别，让我们感觉就是调用项目内的方法；隐藏底层网络通信的复杂性，让我们更专注于业务逻辑...

一、概述 RPC 是解决分布式系统通信问题的一大利器，而分布式系统的一大特点就是高并发，所以说 RPC 也会面临高并发的场景。在这样的情况下，提供服务的每个服务节点就都可能由于访问量过大而引起一系列的问题，比如业务处理耗时过长、CPU 飘高、频繁 Full GC 以及服务进程直接宕机等等。但是在生产环境中，要保证服务的稳定性和高可用性，这时就需要业务进行自我保护，从而保证在高访问量、高并发的场景下，应用系统依然稳定，服务依然高可用。二、自我保护方式 最常见的方式就是限...

我们日常生活中，在行驶之前都会让发动机空跑一会，可以让汽车的各个部件都“热”起来，减小磨损。换到应用上来看，原理也是一样的。运行了一段时间后的应用，执行速度会比刚启动的应用更快。 在 Java 里面，在运行过程中，JVM 虚拟机会把高频的代码编译成机器码，被加载过的类也会被缓存到 JVM 缓存中，再次使用的时候不会触发临时加载，这样就使得“热点”代码的执行不用每次都通过解释，从而提升执行速度。 但是这些“临时数据”，都在我们应用重启后就消失了。重启后的这些...

一、关闭问题 在“单体应用”复杂到一定程度后，一般会进行系统拆分，也就是时下流行的微服务架构。服务拆分之后，自然就需要协同，于是 RPC 框架就出来了，它用来解决各个子系统之间的通信问题。 拆分之后可以更方便、更快速地迭代业务。那么问题来了，更快速地迭代业务，就是经常更新应用系统，时不时还老要重启服务器。 上线的大概流程：当服务提供方要上线的时候，一般是通过部署系统完成实例重启。在这个过程中，服务提供方的团队并不会事先告诉调用方需要操作哪些机器，从而让调...

一、为什么需要异常重试？一次 RPC 调用，去调用远程的一个服务，比如用户的登录操作，会先对用户的用户名以及密码进行验证，验证成功之后会获取用户的基本信息。当通过远程的用户服务来获取用户基本信息的时候，恰好网络出现了问题，比如网络突然抖了一下，导致请求失败了，而这个请求希望它能够尽可能地执行成功，那这时要怎么做呢？需要重新发起一次 RPC 调用，那代码中该如何处理呢？是在代码逻辑里 catch 一下，失败了就再发起一次调用吗？这样做显然不够优雅吧。这时就可以考虑使用 RPC 框架的重试机制。二、

一、背景首先从讲故事开始有一次碰上流量高峰，突然发现线上服务的可用率降低了，经过排查发现，是因为其中有几台机器比较旧了。当时最早申请的一批容器配置比较低，缩容的时候留下了几台，当流量达到高峰时，这几台容器由于负载太高，就扛不住压力了。解决方案：在治理平台上调低这几台机器的权重，这样的话，访问的流量自然就减少了。但业务接着反馈了，说：当他们发现服务可用率降低的时候，业务请求已经受到影响了，这时再如此解决，需要时间啊，那这段时间里业务可能已经有损失了。紧接着就提出了需求，问：RPC 框架有没

一、为什么选择路由策略？在真实环境中我们的服务提供方是以一个集群的方式提供服务，这对于服务调用方来说，就是一个接口会有多个服务提供方同时提供服务，所以我们的 RPC 在每次发起请求的时候，都需要从多个服务提供方节点里面选择一个用于发请求的节点。既然服务提供方是以集群的方式对外提供服务，那就要考虑一些实际问题。要知道我们每次上线应用的时候都不止一台服务器会运行实例，那上线就涉及到变更，只要变更就可能导致原本正常运行的程序出现异常，尤其是发生重大变动的时候，导致我们应用不稳定的因素就变得很多。为了减

因为有了集群，所以每次发请求前，RPC 框架会根据路由和负载均衡算法选择一个具体的 IP 地址。为了保证请求成功，我们就需要确保每次选择出来的 IP 对应的连接是健康的。调用方跟服务集群节点之间的网络状况是瞬息万变的，两者之间可能会出现闪断或者网络设备损坏等情况。解决方案是让调用方实时感知到节点的状态变化，这样他们才能做出正确的选择。这个道理像我们开车一样，车有各种各样的零件，我们不可能在开车之前先去挨个检查下他们的健康情况，转而是应该有一套反馈机制，比如今天我的大灯坏了，那中控台就可以给我提示；明

一、PRC 框架的服务发现机制。1.1 服务注册在服务提供方启动的时候，将对外暴露的接口注册到注册中心之中，注册中心将这个服务节点的 IP 和接口保存下来。1.2 服务订阅在服务调用方启动的时候，去注册中心查找并订阅服务提供方的 IP，然后缓存到本地，并用于后续的远程调用。二、为什么不使用 DNS？既然服务发现这么“厉害”，那是不是很难实现啊？其实类似机制一直在我们身边，我们回想下服务发现的本质，就是完成了接口跟服务提供者 IP 的映射。那我们能不能把服务提供者 IP 统一换成一

1.1 协议模块1.1.1 传输模块RPC 本质上就是一个远程调用，那肯定就需要通过网络来传输数据。虽然传输协议可以有多种选择，但考虑到可靠性的话，我们一般默认采用 TCP 协议。为了屏蔽网络传输的复杂性，我们需要封装一个单独的数据传输模块用来收发二进制数据。1.1.2 协议封装用户请求的时候是基于方法调用，方法出入参数都是对象数据，对象是肯定没法直接在网络中传输的，我们需要提前把它转成可传输的二进制，这就是我们说的序列化过程。但只是把方法调用参数的二进制数据传输到服务提供方是不够的，我们需

什么是 RPC？我知道你肯定不喜欢听概念，我也是这样，看书的时候一看到概念就直接略过。不过，到后来，我才发现，“定义”是一件多么伟大的事情。当我们能够用一句话把一个东西给定义出来的时候，侧面也说明你已经彻底理解这事了，不仅知道它要解决什么问题，还要知道它的边界。所以，你可以先停下来想想，什么是 RPC。RPC 的全称是 Remote Procedure Call，即远程过程调用。简单解读字面上的意思，远程肯定是指要跨机器而非本机，所以需要用到网络编程才能实现，但是不是只要通过网络通信访问到另一台机器的应