我们先来了解一下智能合约调用的基础原理。智能合约运行在以太坊节点的 EVM 中。因此要 想调用合约必须要访问某个节点。
以后端程序为例，后端服务若想连接节点有两种可能，一种是双 方在同一主机，此时后端连接节点可以采用 本地 IPC(Inter-Process Communication，进 程间通信)机制，也可以采用 RPC(Remote Procedure Call，远程过程调用)机制另 一种情况是双方不在同一台主机，此时只能采用 RPC 机制进行通信。
提到 RPC， 读者应该对 Geth 启动参数有点印象，Geth 启动时可以选择开启 RPC 服务，对应的 默认服务端口是 8545。。
接着，我们来了解一下智能合约运行的过程。
智能合约的运行过程是后端服务连接某节点，将 智能合约的调用(交易)发送给节点，节点在验证了交易的合法性后进行全网广播，被矿工打包到 区块中代表此交易得到确认，至此交易才算完成。
就像数据库一样，每个区块链平台都会提供主流 开发语言的 SDK(Software Development Kit，软件开发工具包)，由于 Geth 本身就是用 Go 语言 编写的，因此若想使用 Go 语言连接节点、发交易，直接在工程内导入 go-ethereum(Geth 源码) 包就可以了，剩下的问题就是流程和 API 的事情了。
总结一下，智能合约被调用的两个关键点是节点和 SDK。
由于 IPC 要求后端与节点必须在同一主机，所以很多时候开发者都会采用 RPC 模式。除了 RPC，以太坊也为开发者提供了 json- rpc 接口，本文就不展开讨论了。
接下来介绍如何使用 Go 语言，借助 go-ethereum 源码库来实现智能合约的调用。这是有固定 步骤的，我们先来说一下总体步骤，以下面的合约为例。
步骤 01:编译合约，获取合约 ABI(Application Binary Interface，应用二进制接口)。 单击【ABI】按钮拷贝合约 ABI 信息，将其粘贴到文件 calldemo.abi 中(可使用 Go 语言IDE 创建该文件，文件名可自定义，后缀最好使用 abi)。
最好能将 calldemo.abi 单独保存在一个目录下，输入“ls”命令只能看到 calldemo.abi 文件，参 考效果如下:
步骤 02:获得合约地址。注意要将合约部署到 Geth 节点。因此 Environment 选择为 Web3 Provider。
在【Environment】选项框中选择“Web3 Provider”，然后单击【Deploy】按钮。
部署后，获得合约地址为:0xa09209c28AEf59a4653b905792a9a910E78E7407。
步骤 03:利用 abigen 工具(Geth 工具包内的可执行程序)编译智能合约为 Go 代码。abigen 工具的作用是将 abi 文件转换为 Go 代码，命令如下:
其中各参数的含义如下。 (1)abi:是指定传入的 abi 文件。 (2)type:是指定输出文件中的基本结构类型。 (3)pkg:指定输出文件 package 名称。 (4)out:指定输出文件名。 执行后，将在代码目录下看到 funcdemo.go 文件，读者可以打开该文件欣赏一下，注意不要修改它。
步骤 04:创建 main.go，填入如下代码。 注意代码中 HexToAddress 函数内要传入该合约部署后的地址，此地址在步骤 01 中获得。
步骤 04:设置 go mod，以便工程自动识别。
前面有所提及，若要使用 Go 语言调用智能合约，需要下载 go-ethereum 工程，可以使用下面 的指令:
该指令会自动将 go-ethereum 下载到“$GOPATH/src/github.com/ethereum/go-ethereum”，这样还算 不错。不过，Go 语言自 1.11 版本后，增加了 module 管理工程的模式。只要设置好了 go mod，下载 依赖工程的事情就不必关心了。
接下来设置 module 生效和 GOPROXY，命令如下:
在项目工程内，执行初始化，calldemo 可以自定义名称。
步骤 05:运行代码。执行代码，将看到下面的效果，以及最终输出的 2020。
上述输出信息中，可以看到 Go 语言会自动下载依赖文件，这就是 go mod 的神奇之处。看到 2020，相信读者也知道运行结果是正确的了。
RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即无论是调用本地接口/服务的还是远程的接口/服务，本质上编写的调用代码基本相同。比如两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数或者方法，由于不在一个内存空间，不能直接调用，这时候需要通过就可以应用RPC框架的实现来解决。
RPC 会隐藏底层的通讯细节（不需要直接处理Socket通讯或Http通讯）
RPC 是一个请求响应模型。客户端发起请求，服务器返回响应（类似于Http的工作方式）
RPC 在使用形式上像调用本地函数（或方法）一样去调用远程的函数（或方法）。
二、常见RPC框架
几种比较典型的RPC的实现和调用框架。
（1）RMI实现，利用java.rmi包实现，基于Java远程方法协议(Java Remote Method Protocol)
和java的原生序列化。
（2）Hessian，是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能。 基于HTTP协议，采用二进制编解码。
（3）THRIFT是一种可伸缩的跨语言服务的软件框架。thrift允许你定义一个描述文件，描述数据类型和服务接口。依据该文件，编译器方便地生成RPC客户端和服务器通信代码。
二、RPC框架实现原理
在RPC框架中主要有三个角色：Provider、Consumer和Registry。如下图所示：
RPC框架面试总结-RPC原理及实现
节点角色说明：
* Server: 暴露服务的服务提供方。
* Client: 调用远程服务的服务消费方。
* Registry: 服务注册与发现的注册中心。
三、RPC调用流程
RPC基本流程图：
RPC框架面试总结-RPC原理及实现
一次完整的RPC调用流程（同步调用，异步另说）如下：
1）服务消费方（client）调用以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3）client stub找到服务地址，并将消息发送到服务端；
4）server stub收到消息后进行解码；
5）server stub根据解码结果调用本地的服务；
6）本地服务执行并将结果返回给server stub；
7）server stub将返回结果打包成消息并发送至消费方；
8）client stub接收到消息，并进行解码；
9）服务消费方得到最终结果。
RPC框架的目标就是要2~8这些步骤都封装起来，让用户对这些细节透明。
四、服务注册&发现
RPC框架面试总结-RPC原理及实现
服务提供者启动后主动向注册中心注册机器ip、port以及提供的服务列表；
服务消费者启动时向注册中心获取服务提供方地址列表，可实现软负载均衡和Failover；
五、使用到的技术
1、动态代理
生成 client stub和server stub需要用到 Java 动态代理技术 ，我们可以使用JDK原生的动态代理机制，可以使用一些开源字节码工具框架 如：CgLib、Javassist等。
2、序列化
为了能在网络上传输和接收 Java对象，我们需要对它进行 序列化和反序列化操作。
* 序列化：将Java对象转换成byte[]的过程，也就是编码的过程；
* 反序列化：将byte[]转换成Java对象的过程；
可以使用Java原生的序列化机制，但是效率非常低，推荐使用一些开源的、成熟的序列化技术，例如：protobuf、Thrift、hessian、Kryo、Msgpack
关于序列化工具性能比较可以参考：jvm-serializers
3、NIO
当前很多RPC框架都直接基于netty这一IO通信框架，比如阿里巴巴的HSF、dubbo，Hadoop Avro，推荐使用Netty 作为底层通信框架。
4、服务注册中心
可选技术：
* Redis
* Zookeeper
* Consul
* Etcd
分布式微服务治理的核心在于: 微服务和分布式
Remote Procedure Call，翻译过来应该是“远程程序调用”，目前业内通用的翻译是“远程过程调用”，但是“过程”这个词很容易造成误解，翻译成“程序”更好理解RPC的意义。
一般所谓的XX协议就是个文档，类似于我们的需求文档，只说了要做什么，但是具体怎么做是由各大开源大佬做的。 一般情况下都会实现核心功能，不同的开源在细节上实现都会不一样，这个需要注意！
RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson 提出的，在 Nelson 的论文 "Implementing Remote Procedure Calls" 中，他提到了几个 RPC的特点 ：
除此之外，这位大佬还给出了实现RPC框架的 详细架构图 ：
结合上图，Nelson 的论文中指出实现 RPC 的程序包括 5 个部分：
所以这架构图的意思是：当 user 想发起一个远程调用时，它实际是通过本地调用 User-stub。并通过本地的RPCRuntime传输 。远端 RPCRuntime 实例收到请求后交给 Server-stub 进行解码后发起本地端调用，调用结果再返回给 User 端。
看完协议内容，跟着就得实现这个协议啦，这时候你是不是发现了问题的严重性： 自！己！一！点！思！路！都！没！有！
所以我们需要再理解一下RPC协议，根据Nelson的论文知道我们要做的两件事：
上述两点其实是实现RPC协议的两大要素： 序列化协议和传输协议 。
因为RPC本质上是进程间通信，而“本地调用和远程调用的对比”实际上就是“进程内通信和进程间通信的对比”。通过两者的对比，我们才能理解到 序列化协议和传输协议 的作用，如下图：
最基本的RPC框架就是 单点式 的，因为A服务直接调用B服务，不经过第三方，这种是最简单的。但是必须是A和B同时部署一套，A1只能调用B1，A2只能调用B2。
所以需要一台A服务对多台B服务，利用第三方服务(注册中心)找到其他B服务，而不是写死B服务的地址。这种RPC才是 分布式 RPC，也是业内主流。
单点RPC框架只需要：
但是我们要做分布式的啊，所以需要：
实际上在生产环境中，我们需要实时监控服务的调用情况，所以需要一个微服务管理中心，甚至是一个自动化运维的管理中心，所以需要：
在文章的第二节我们看到大佬论文中对RPC的总结，其中一个很重要的一点：“通用”。
所以我们需要：
对的，能实现上述五点的，才是一个合格的RPC框架，但还不是优秀，因为我们还要考虑下性能。
先打个底，目前流行的RPC框架大多都是多管闲事，不单单只是RPC框架，你可以看看Dubbo和SpringCloud中除了RPC还有什么骚功能。
可以看看别人的各种RPC框架总结： http://www.cnblogs.com/moonandstar08/p/6291283.html
在网上找到了个图，但是没有提到SpringCloud，暂且看看先，因为有些不认为是对的：
我们可以看到各个RPC框架使用的序列化协议，注册中心，管理中心，是否跨语言，但是传输协议没有提到。
参考这篇博客： http://blog.csdn.net/jek123456/article/details/70208049
综合来说，在性能上rpcx是首选，但是考虑到框架的生态，其实还是推荐Dubbo或者SpringCloud的，因为除了性能，成本也是很重要的，无论是学习成本还是研发成本。
