我刚读到关于rpc http://www.grpc.io/远程过程调用，另一方面我们有一个webservice，其中客户端向服务器和服务器响应请求。
rpc也是如此，stub称之为服务器端的方法。我认为同样的事情可以在webservice的帮助下实现。
什么rpc可以有所作为，哪里更好用？
Webservices促进松耦合。你应该更喜欢。 RPC限制您使用某种编程语言。当您使用Web服务时，您可以使用不同的语言甚至不同的操作系统来交换信息。当您考虑连接几种类型的设备时，您应该使用Web服务，但是当您构建具有多个模块的分布式应用程序时，RPC可能更适合。
RPC是一种协议，一个程序可以使用该协议从位于网络上另一台计算机上的程序请求服务，而无需了解网络的详细信息。过程调用有时也称为函数调用或子例程调用。
“亲爱的孩子有很多名字”。 RPC，Soap WS，REST，RMI和其他只是计算机之间通信的不同方式，无论您选择哪一种，都有很多相似之处可以达到相同的最终结果。在这种情况下（grpc），RPC只是一个通用的“远程过程调用”名称，表明它的用途。
在选择其中一种技术时，您需要了解其中的差异，因此，例如，RMI是一种仅限Java的技术，当您不在完整的Java环境中时，您不想使用它（即便如此，我也不会去为了它）。如果你真的喜欢SOAP和/或XML，你可能想要使用常规的web服务。如果您更喜欢JSON而不是HTTP，那么REST可能是您的选择。如果你想走向前沿，你可能想选择grpc或其他类似的技术。
通常使用的技术将由现有的代码库决定，因此，如果您之前使用过SOAP Web服务，那么您将继续使用它。
什么rpc可以有所作为，哪里更好用？
我看到的主要优点是你在编译时被迫捕获更多错误。
这篇关于gRPC-Web: Moving past REST+JSON towards type-safe Web APIs的帖子说：
"
"
我看到的主要优点是您具有可在不同场景中重用的标准操作和通用概念。
在Richardson Maturity Model - steps toward the glory of REST中引入了不同层次的概念。你可以从那里获得一些优势。
"
1级通过使用分而治之来解决处理复杂性的问题，将大型服务端点分解为多个资源。
2级引入了一组标准动词，以便我们以相同的方式处理类似的情况，消除不必要的变化。
Level 3引入了可发现性，提供了一种使协议更加自我记录的方法。
"
当你拥有一个不熟悉HTTP或其他常用协议的领域专家团队时，rpc可能适合内部使用。它在后端到后端通信中也具有优势，其中不涉及浏览器。使用像gRPC这样的技术，可以支持多种语言/技术之间的通信。
在所有其他情况下，类似HTTP的通信似乎仍然是2017年大多数用例的标准？
即使很久以前就提出这个问题，我想补充一下我的简短答案，并提出重要的不同之处，希望对未来的读者有所帮助。
------------------------------------------------------------------------------
| Category | RPC | Web Services
------------------------------------------------------------------------------
|Operation's Location | On top of TCP | on top of HTTP Protocol
------------------------------------------------------------------------------
|Data format | Binary | Text, XML, JSON, ect.
------------------------------------------------------------------------------
|Speed | Slow (Marshilling) | Fast
------------------------------------------------------------------------------
我没有提到RPC和Web服务的描述，因为你可以清楚地看到其他人的回答。