最近学了RPC，关于对RPC知识的一点汇总
RPC调用 使用 RPC 的目的是让我们调用远程方法像调用本地方法一样无差别。并且RESTful API通常是基于HTTP协议，传输数据采用JSON等文本协议，相较于RPC 直接使用TCP协议，传输数据多采用二进制协议来说，RPC通常相比RESTful API性能会更好。
RESTful API多用于前后端之间的数据传输，而目前微服务架构下各个微服务之间多采用RPC调用。
net/rpc RPC 的消息传输可以通过 TCP、UDP 或者 HTTP等，所以有时候我们称之为 RPC over TCP、 RPC over HTTP（RPC 通过HTTP 传输消息的时候和 RESTful的架构是类似的，但是也有不同）。
Go语言的 rpc 包提供对通过网络或其他 i/o 连接导出的对象方法的访问，服务器注册一个对象，并把它作为服务对外可见（服务名称就是类型名称）。注册后，对象的导出方法将支持远程访问。服务器可以注册不同类型的多个对象(服务) ，但是不支持注册同一类型的多个对象。
RPC over HTTP 和 RESTful RPC 的客户端和服务器端是紧耦合的，客户端需要知道调用的过程的名字，过程的参数以及它们的类型、顺序等。一旦服务器更改了过程的实现，客户端的实现很容易出问题。RESTful基于 http的语义操作资源，参数的顺序一般没有关系，也很容易的通过代理转换链接和资源位置，从这一点上来说，RESTful 更灵活。
它们操作的对象不一样。 RPC 操作的是方法和过程，它要操作的是方法对象。RESTful 操作的是资源(resource)，而不是方法。
RESTful执行的是对资源的操作，增加、查找、修改和删除等,主要是CURD，所以如果要实现一个特定目的的操作，比如为名字姓张的学生的数学成绩都加上10这样的操作，RESTful的API设计起来就不是那么直观或者有意义。在这种情况下, RPC的实现更有意义，它可以实现一个Student.Increment(Name, Score) 的方法供客户端调用。 RPC over TCP 和 RESTful 如果直接使用socket实现 RPC，除了上面的不同外，可以获得性能上的优势。
RPC over TCP可以通过长连接减少连接的建立所产生的花费，在调用次数非常巨大的时候(这是目前互联网公司经常遇到的情况,大并发的情况下)，这个花费影响是非常巨大的。 RESTful 也可以通过 keep-alive 实现长连接， 但是它最大的一个问题是它的request-response模型是阻塞的 (http1.0和 http1.1, http 2.0没这个问题)，发送一个请求后只有等到response返回才能发送第二个请求 (有些http server实现了pipeling的功能，但不是标配)， RPC的实现没有这个限制。
