RPCX介绍
rpcx是一个快速的、包含更多特性的RPC框架。
rpcx 2.0及以下扩展了Go标准rpc包，但是rpcx 3.0重构并且不再使用Go标准rpc包。
RPCX基于以下目标开发：
- 简单：易学，易开发、易于集成和易于部署
- 性能：高性能（远优于grpc-go）
- 跨平台：支持原始字节切片、JSON、Protobuff和MessagePack，理论上可以用于java、php、python、c/c++、node.js、c#和其他平台
- 服务发现和服务治理：支持zookeeper、etcd和consul。
它包含以下特性：
- 支持原始Go函数，不需要定义proto文件
- 可插入。特性可扩展，例如服务发现、跟踪等功能
- 支持TCP、HTTP、QUIC和KCP
- 支持多种编解码格式，例如JSON、Protobuf、MesagePack和原始字节
- 服务发现。支持点对点、可配置多节点、zookeeper、etcd、consul和mDNS
- 容错。失败转移、快速失败、失败重试
- 负载均衡。支持随机、轮询、一致性哈希、权重、网络质量和地理位置
- 支持压缩
- 支持传递元数据
- 支持授权
- 支持心跳和单向请求
- 其他特性：测量、日志、超时、别名、熔断
- rpcx适用二进制协议，独立于平台，这意味着你可以使用java、python、node.js等其他语言开发服务，也可以使用其他编程语言请求Go编写的服务
这里有一个UI管理工具：rpcx-ui
RPC
RPC（远程过程调用）是指计算机程序使一个不同地址空间（一般位于同一个共享网络里的另一台计算机）的过程执行。远程过程的编码类似于一个普通的本地过程调用，程序员不需要明确编写远程交互的代码。也就是说，程序员基本上是编写相同的代码，不论子过程是本地的还是远程的。这个是一种客户端--服务器端的交互方式（调用者是客户端，执行者是服务器端），典型地通过一个请求-响应地消息传递系统实现。RPC模型实现了一定程度的本地透明，也就是说，调用不论是在本地或者是远程地过程都基本是一样地，但实际上并不是完全相等的，因此本地调用能和远程调用区分开。远程调用与本地调用相比一般会慢上一个量级，并且更不可靠，因此区分他们非常重要。
响应-请求协议可追溯至1960年代的早期分布式计算，远程过程调用作为网络操作模型的理论提案可追溯至1970年代，实用的实现可追溯至1980年代。1990年代，随着面向对象编程的流行，远程方法调用（RMI）的可替换模型被普遍实现，例如公共对象请求代理体系结构（CORBA，1991）和Java远程方法调用。因此RMI随着因特网的增长变得流行起来，特别是2000年代。
现代操作系统使用远程过程调用可追溯至RC 4000批处理系统，该系统使用请求-响应协议来处理同步化。把网络操作看作远程过程调用的想法至少可以追溯至1970年代的早期ARPANET文档。1978年，Per Brinch Hansen提出分布式进程，一种由进程之间的过程调用组成的基于“外部请求”的分布式计算语言。
Bruce Jay Nelson一般被认为是发明“remote procedure call”一词的人（1981），第一个可行的实现名为Lupine，由Xerox PARC公司的Andrew Birrel和Bruce Nelso在Cedar环境下编写。Lupine自动生成根节点，提供类型安全的绑定，使用高效的协议进行通讯。1981年Xerox公司的“Courier”是最先商业化运用RPC的其中之一。Unix上第一个流行的RPC实现是Sun‘s RPC（现在称为ONC RPC），用作网络文件系统的基础。
RPC是一个请求-响应协议。一个RPC由客户端发起，通过发送一个请求消息到一个已知的远程服务器，使用给定的参数去执行一个特定的过程。远程服务器发送一个响应到客户端，然后应用继续它自己的进程。当服务器处理调用的时候，客户端被阻塞（它会一直等待，直到服务器结束处理才恢复运行），除非客户端发送给服务器的是一个异步请求，例如XHTTP调用。由很多不同的PRC变种，不同的实现中由很微妙的区别，导致了由很多种不同的（不兼容）RPC协议。
远程过程调用和本地调用之间一个非常重要的区别是远程调用会因为不可预知的网络问题而失败。另外，调用者一般必须处理这些不知道远程过程是否真的被请求到的失败。幂等的过程（如果被调用超过一次没有额外的影响）很容易处理，但是调用远程过程来编写底层子系统仍然受限制并且经常有很多困难。
以上内容来自于维基百科
RPC在微服务架构中应用广泛。
微服务是面向服务架构（SOA）风格的一个变种，它把一个应用分解成一些松耦合服务的集合。在微服务架构中，服务应该是合理粒度的，协议应该轻量级。把一个应用分解为多个小的服务的好处是提高模块化和让应用更易于理解、开发和测试。同时可以允许小的独立团队开发、部署和缩放他们独立的服务来并行化开发。该架构也允许一个独立的服务通过持续的重构出现。基于微服务的架构允许持续交付和部署。
微服务之间的通讯可以使用RPC或者RESTful，也可以使用其他的进程内通讯机制。