一文探讨 RPC 框架中的服务线程隔离

最近秋招开始了，很多学生开始准备起了秋招，有很多人想知道进一些有名的互联网公司实习有什么要求，正好最近跟一位阿里春招的实习小伙子聊了一些 RPC 相关的知识点，于是我把这篇他的思考转发过来，给大家参考下，我觉得有这样的实力，进大厂实习应该是没有问题的。以下是原文：

自从春招实习之后，眼界真的就一下子开阔起来了，也感觉到了以前的自己好菜啊（虽然现在也是，笑～）。果然学习之路不能停！

微服务如今应当是一个优秀的程序员必须学习的一种架构思想，而RPC框架作为微服务的核心，不说读一遍源码吧，起码它的实现原理还是应该知道的。

然而目前的RPC服务框架，大多存在一个问题，就是当服务提供端Provider应用中，有的服务流量大，耗时长，导致线程池资源被这些服务占尽，从而影响同一应用中的其他服务正常提供。为此，这次博文主要介绍一下我对于这方面的思考。

前言

在绝大多数场景下，对服务资源的隔离可以通过开源框架Sentinel来实现，其通过配置某个服务的并发数，来达到限流和线程资源隔离的目的。坦白的讲，这已经能够满足绝大多数需求了，但是手动取配置这些参数还是比较有难度的，大多得靠大佬们的经验了，而且也不够灵活。

我在学习的时候，也突发奇想，有没有可能不依赖外部的组件，而实现内部的服务资源隔离？再更进一步，有没有可能根据应用内各个服务的流量数据，对每个服务资源进行动态的分配和绑定呢？

打个比方说，某个应用里存在A、B两个服务，100个线程。白天的时候，A服务的流量大，B服务的流量很小，那么在这个时间段内，我们的应用分配给A的资源理应更多。但是也不能全给A拿走了，B也得喝口汤，不然又会出现线程耗尽的情况，所以此时我们可能根据流量数据的比对分给A服务80个线程，B服务20个线程；而到了晚上，A服务没啥人用了，B服务流量来了，那我们就给B更多的资源，但也要保证A可用，比如说，A服务20线程，B服务80线程。

我承认我一开始只是想简单写个RPC框架，学习实现原理而已。但突然有了这样一个想法，我就来了动力，想看看自己的想法行不行得通，下面我便介绍下我的思考，说的有不对的地方也欢迎大家指出和探讨。

线程隔离的三个组件

借鉴了传统的RPC框架的实现原理后，我们只需要修改或者增加三样东西，就可以完成上述的功能，分别为：线程池、数据监控节点Metric和线程动态分配的Monitor。这三者之间的关系可以先看一下这张图有个大概的印象。

线程池<