读《凤凰架构》- RPC的历史与知识

读《凤凰架构》- RPC的历史与知识

引用： 《凤凰架构》- 周志明

访问远程服务

• 两个进程交换数据，在计算机科学成为IPC, 目前IPC技术有：pipe管道，中断信号，同步信号量，消息队列，共享内存，IPC socket.
• RPC被看作是一种特殊的IPC, 早期RPC运用于网络通信，透明调用特性导致滥用，甚至被质疑。
• 远程调用比本地调用需要额外重视：网络可靠，带宽，安全，扩展性，维护与传输成本。
• RPC像本地调用一样透明就必须为这些问题买单。
• RPC是业务层通讯，IPC是系统底层通讯，是一种业界主流观点。
• 1981年的RPC调用的定义中强调了RPC是进程在语言层面的，基于有限带宽，传输控制信息用的。（环境与用途）
• 理解起来，RPC是为了在有限条件下实现透明化的跨进程控制。
• RPC需要解决问题可以归纳为“表示数据”“传输数据”“表示方法”。以webservice为例子，对应“XML”“SOAP”“WSDL”
• 如果是JSON-RPC的话对应的问题解决方案是“json”“HTTP”“JSON webservice 协议”
• RPC三个要解决的问题都是追求跨平台的
• 近代RPC协议在跨平台和轻量级上争得头破血流。
• webservice不够轻量，在于他的协议栈的扩展包含了太多复杂的东西，包括事物性，一致性，事件，通知，安全，防重放等。
• RPC的困境在于又要透明的解决网络等问题，又要协议本身轻量简单。（就好像要求25岁的你10年工作经验）
• 这个问题即便是现在依然困扰着业界（所以，不要再过度痴迷json-rpc和grpc啦）
• 基于这个尴尬的事实，RPC分三个流行的流派“面向对象RMI”“追求性能的gRPC”“追求简单的json-rpc”
• 个人经验，规模大的选gRPC类型，追求敏捷选json-rpc。至于RPC面临的网络问题（安全，事物，可靠，成本）就根据业务取舍引入其他组件弥补一下。
• 也因为追求轻便化，很多RPC不正面解决RPC三个问题（数据表示，通讯方式，方法描述），转而把解决问题的方法做成扩展口，用户根据需要拔插。
• 所以，我们清楚了一点，各种“负载均衡，服务发现，可观察性”等奇淫巧技都是RPC中的三大问题（数据表示，通讯方式，方法描述）引发的。
• 分布式系统不一定要面向方法，也就说不一定要去正面刚RPC三大问题。
• REST和RPC是不同道上的东西，很难比较。
• REST提出者是搞一辈子web的，RPC的提出是做系统进程通讯的。本质上不是一个道上的。
• REST representational state transfer 中的“representational 表征” 可以理解为是hyper text 超文本的进一步抽象。
• REST看起来比较过于简单，以至于处理复杂业务时跟RPC比起来显得束手束脚。
• 复杂技术背景下，流行轻量级和定制化设计，比如轻量级RPC与Backend For Frontend 的提出。
• 网关意义，正向路由和反向代理。