那些年，我们错过的RPC

引子

RPC（Remote Procedure Call，远程过程调用）是一种跨网络调用服务的技术，它允许程序在一个网络节点上调用另一个网络节点上的服务，仿佛它们在同一台计算机上一样。作为在当下炙手可热的热门话题，它已在各大企业级软件设计中崭露头角，成为了开发工程师的必备技能。

然而，我们大部分人所理解的RPC仅仅是一套框架，一种库或者是一个中间件，人们基于框架、库或者中间件来进行开发，仅此而已。其实，RPC不单单是一种技术，它还是一种思想，一种系统架构，一种解决跨网络调用的方法，而这才是其真正的核心所在。
在《Java开发者的RPC实战课》这本书中，作者DannyIdea正是在这一理解基础上，一步一步引领你从零开始去写一个RPC框架。这需要你知道什么是网络通信，什么是网络编程，了解各种各样的编码和解码格式，必须会多线程编程，更要熟悉网络协议及序列化和反序列化。由此可见，RPC框架的本质实际上就是网络框架，只不过它将网络通信的底层细节隐藏了起来，让上层开发人员可以轻松地使用它进行远程过程调用。

然后，我们就得问了，究竟是谁误解了它？而又是谁一次次地错过了它呢？

误解

在过往的认知里，很多人将RPC理解为网络框架，认为它无非就是构建了一个与框架相同的连接池，采用了与框架类似的编码解码器，实现了与框架相似的路由选择器，甚至还配有与框架一般无二的服务治理中心。尽管这是一种误解，但是这样的理解却有着它存在的合理性，因为在早期RPC的发展历程中，大部分技术人员会优先选择用 RPC 来取代原来的网络编程框架，因为它们的工作原理类似，使用起来也较为方便。同时，这样的设计也得到了主流RPC框架的认可，因而造成了大家对RPC的误解。

不过，我们依旧需要清楚地认知到，RPC本质上还是一种思想，它和网络框架是两码事。它其实更像是一个面向服务的架构（SOA） ，你可以用它去构建分布式系统，也可以用它去构建微服务。换句话说，RPC框架只是一个实现 RPC 思想的工具，而 RPC 本身才是真正的核心。倘若我们真的错把RPC的工具框架当成了RPC的核心，那问题可就大了！

错过

在技术高速发展的今天，谁也不愿成为潮流的落后分子。这就造成了我们在遇到RPC的时候，喜欢用最快的时间去上手它、去了解它，然而，我们以为只要对它的使用框架、库或者中间件的熟悉了，那就等于掌握了RPC的全部精髓，然后我们将精力和时间都用在了性能优化上，殊不知，性能优化只是其中的一部分，对于RPC来说，性能优化反倒成了不太重要的部分。所以，当我们还在为性能优化而沾沾自喜的时候，其他人已经在通过RPC去解决实际问题了。

有人会说，我用过RPC框架，但我不知道RPC是什么。 想想也是，因为我们一直都在用它来写代码，并没有真正地去关注和理解它背后的思想。有些人甚至会将它和WebService、RESTful混为一谈。这都是不够的，甚至可以说是无效的，你也许学到了RPC的使用方法，却错失了它的精髓，最终落得一个会用不会修的下场。

总结

RPC作为一种思想，一种架构，一种解决跨网络调用的方法，不仅仅是一套框架、一个库或者一个中间件，而是一种技术，是一个系统，是一个解决跨网络调用的方案。只有深刻地理解了它的思想，掌握了它的精髓，才能真正地用好它，从而提高我们的开发效率和解决问题的能力。

从现在起，不要再局限于RPC的使用层面，而是要站在更高的角度去思考，去理解它的本质，去掌握它的核心思想，这样才能在未来更加复杂的环境中游刃有余，成就一番事业。