远程对象调用
要说“远程对象”，必先说“远程调用”，也就是RPC。比较著名的RPC框架有，最近很火的gRPC，也就是Google开源的RPC。另外还有Facebook开源的Thrift等等……我厂内部也有很多RPC框架，琳琅满目不暇接。Java在JDK里面也支持RMI（Remote Method Invoke: 远程方法请求）功能，也可以视为一种RPC，但实际上这个更像我们现在要讨论的“远程对象调用”。
在诸多的RPC中，我们都基本认为是通过网络，对运行在另外一个进程（或者电脑）里的某个函数，发起一次调用请求。既然是一次函数调用，那么我们自然要传入参数，然后期望获得返回值。在这个过程中，我们往往只需要输入：函数名+参数，RPC就能找到一个远程的进程，去执行对应的函数，然后传入目标参数。在这个过程里，执行这个函数的进程，会被认为是无状态的，所有的输出，都仅与输入的参数有关，除非有一部分状态是记录在数据库（持久化设备）上的。因此，计算的过程（算法），和计算的数据，实际上分离的，这些计算所需的数据，要么来源于参数，要么是数据库设备。而被请求的函数，以及装载这个函数的容器——进程，是不保证任何的状态维护能力的。
而“远程对象调用”，正是在“状态”这个环节上，和RPC不同——它是由框架去保证某种状态的。当我们发起一个远程对象调用的时候，是需要首先“找到”一个远程对象，然后再发起“方法”（成员函数）调用。这和RPC就产生了两个明显的区别：
- 我们需要用某种手段定位到对象，而不是仅仅用一个函数名。对象是一个更复杂的远程概念，因为有可能同属于一个类（class），而存在多个状态一致或不一致的对象，在远程的机器上存在。我们就不能仅仅通过一个固定的路由标志（比如类名）去找一个这样的对象。远程对象的路由方式成为不同“远程对象调用”框架之间的一个显著区别。
- 我们并不需要把所有的数据，在每次请求时都通过参数发给远程对象，因为对于同一个远程对象来说，它是可以包含大量过程状态的。我们只要找到正确的远程对象，就能获得之前操作所造成的结果状态。有远程对象往往是生存在进程的内存中，所以对于访问自己的状态数据，会非常快速，这对于有延迟压力的程序来说，是非常有用的。
所以，远程对象调用，最大的特点，就是数据和计算是合并在一起的——这很好的提高了使用面向对象编程的便利性，也大大降低了远程调用中因为数据拉取产生的延迟。
