无论是 Leetcode 和层出不穷的 Online Judge, 核心是帮助大家锻炼 Coding 和解算法题的能力。
未来的趋势是，技术面试以及入职之后的 Ramp-up, 对大家的技术能力要求更高更广。因此我们推出一个新的系列——刷题外传，深入浅出的介绍那些刷题中无法涉及的、在面试和工作中却非常重要的系统知识。
本地调用的局限
很多朋友写起 Leetcode 如占瓜切菜，拿出 Eclipse/IntelliJ 建一个 Solution 类就可以码算法，然后 Main 函数里面放几个 Test case, 跑通了心里的满足感不要不要的。然后大家就觉得，写程序挺简单嘛，写几个类，大不了在 import 几个系统库，调用来调用去，语法没错，逻辑搞对，编译通过了就搞定啦。
真正进入工作了，你耳边想起各种新的词汇，什么 Web Service, RPC, Rest, blabla, 感觉生活不复当初一个 IDE 搞定一切那样美好，你的心中想着，怎么才能 import 这些乱七八糟的 service ? 怎么才能调用它们呢？
OK, 进入正题。初学者、或者大部分学生写过的程序都属于本地调用。
看上面的例子，从 main 到 PrintValue 的调用就是一个典型的本地调用。
当然复杂的例子可以很多，你可以调用各种系统库、第三方库中的类和函数，只要被调用的方法只在本地完成所有实现，那么就是本地调用。
本地调用的假设是所有实现都存在于本地，但这个假设在生产环境中基本不现实。
在真实的场景中，我们喜欢把常用的相对独立的功能单元做成一个服务 (service), 服务的提供者和服务的调用者往往部署在不同的机器上，有不同的团队管理。
这样做的好处很明显：
- 服务的开发者不需要关心谁调用了它的服务；低耦合；
- 服务的开发者只需要关心怎样最优化实现自己的服务，且更容易 Scale; 高内聚；
- 服务的使用者（调用者）不需要关心服务的具体实现；
- 服务的使用者（调用者）只需要处理好自己的调用链中的逻辑；
RPC
既然跨机器、跨服务的调用有样的好处，怎样实现呢？答案有很多种，RPC (Remote Procedure Call), 提供了一种很有意思的思路。
想象一下跨机器间的调用：底层基础一定是网络编程，机器 A 向机器 B 发送消息，另外机器 B 收到消息后，根据某种协议来做一些事情，比如：
- 比如进行一个方法的调用
- 比如对某个资源进行操作
RPC 属于前者，也就是跨机器进行方法的调用。
如图所示，Client / Server routines 可以想象成你的代码。他们通过 Client / Service Stub 和网络协议进行消息传递，看起来好复杂。
为什么设计成这样？Client 的代码直接调用 Service 端的代码不行么？
还是那句话，如果方法的调用者和实现者都在本机，当然可以直接调用（本地调用）。但在网络中传递消息本质上是传输 byte codes, 发消息和收消息的两台机器都需要按同样的规则 序列化/反序列化 消息内容，类似于编码和解码的过程。
换句话说，假设机器 A 需要调用机器 B 上的一个函数 “function_b”. 那么机器 A 需要把调用的 context (包括函数名，参数信息，调用服务地址，e.g 机器 B 的地址和端口）打包序列化成 byte codes, 通过网络协议传到机器 B, 机器 B 再反序列化获得 context, 执行程序实现，把结果再序列化发回给机器 A.
如果每次 RPC 调用都需要手写这么复杂的序列化、反序列化的过程，那可麻烦死了。
考虑到序列化、反序列化的过程都是类似的，能否把他们抽象出来呢？
没错，这就是上图中 Client / Service Stub 的作用。他们封装了 RPC 调用的序列化以及网络调用的部分，所以调用者只需要像调用本地方法一样调用 Client Stub 上的方法，消息就会顺着 Framework 来到另一端进行处理，结果依同样的路径返回调用者。
RPC 的优雅之处在于其良好的封装性，Client 用类似于本地调用的方式进行了跨机器的操作，代码简洁。测试更是非常直观，Mock 一下 Client Stub 怎么方便怎么测试，真的有助于写出高质量的代码。
进阶 RPC
相信读到此处的读者对于 RPC 已经有了不错的理解。那么为什么圈子里流行着各种各样的 RPC Framework 呢，比如最早的 XML-based RPC, Facebook 开源的 Thrift, Google 开源的 gRPC. 大家都在 re-invert wheels 么？
性能是最大的动力。还是如上图所示，RPC 封装的是系列化和网络传输的部分。先说序列化，XML 是最原始的系列化手段，但是其体积大，传输效率低。所以 Thrift 和 gRPC 都实现了自己的 binary 序列化协议，提升了序列化的效率。
换句话说，传递同样的 Context, 使用 XML 序列化产生的消息大小要超过 Thrift/gRPC.
网络协议也是一个优化的重点。Thrift/gRPC 都是在 TCP 的基础上实现自家的应用层协议，效率高。（如果你还搞不清楚 TCP / HTTP 之间的区别，等包子的系列文章吧）。
此外，很多 RPC Framework 也支持 Stream 操作，即 Client / Server 端可以连续发送几条消息给对方，然后等待回复。在很多需要高性能的场景下，Streaming RPC 是比较不错的选择。
尾声
RPC 是一种非常常见的服务调用方式，这篇文章提供一个简单的切入点，帮助大家理解 RPC 的原理和基本应用。粗糙之处，也请大家指正。
转自：包子铺里聊IT