目前，对于一个完整的应用来说，通常包含了若干支持不同功能的服务，亦或者是函数，这些服务之间往往可能需要互相调用，使用已经实现的服务功能，而不是需要在每个服务进程中再去重复实现已经有的功能。
这不仅对于开发者来说是一种比较合理的设计方式，对于服务的维护者来说，也不需要在每次服务出现问题或者需要更新服务功能的时候，必须迭代整个应用，而是只需要单独针对这个服务功能进行升级处理即可。
但是随着应用功能的扩展，单机部署的应用逐渐显得臃肿，这时，架构设计者尝试将一些较大的服务剥离开来，单独部署在另一台主机设备上，从而实现核心应用服务器的减负，提高资源利用率和服务性能，这就是 分布式部署 的方式。这也是一种从应用到服务的一种转变，
但是，此时服务部署在不同的机器上面，那服务之间要怎么实现相互调用呢？此时，RPC (Remote Procedure Call 远程过程调用) 就应运而生。
到这里，相信可能已经猜到了 RPC 的含义了，其实 RPC 本身就是一种概念，也就是 如何进行远程的服务调用 ，它不是一个协议，也不是一个解决方案，而是这些所有可以实现远程服务调用的解决方案的概念本身，此时你可能会马上联想到了 HTTP 协议，因为从上面的阐述来看，通过 HTTP 的方法调用同样可以解决以上的问题，而事实上，HTTP 就是可以用来实现 RPC 的一种方式。
你也完全可以自己实现一种 RPC 服务，根据你定义的通讯方式，只要保证当本地程序进行远程方法访问的时候，远程服务可以顺利接收到请求，并且能够识别客户端所调用的方法，并解析得到其中的参数，从而调用本地的函数并将最终得到的结果返回给客户端，这样也可以解决远程调用的问题。
因此，不需要局限于解决方法，任何可以高效并且稳定的解决问题的方案都是一个优秀的方案，很多时候一些流行的框架和方法都是为了解决某个既有问题而诞生的，因此当你清楚根本问题时，你就可以很好的理解这个框架或者理念。