概要
- RPCは、あるアイデア基盤となるネットワーク技術の考え方を理解することなく、ネットワークを介してリモートコンピュータからのサービス要求：。
- RPC対処すべき2つの問題：
- 分散システム、サービス呼び出しの間で問題を解決します。
- リモート呼び出しは、のようにすることができるようにする場合は、ローカルコールの発信者は、リモート呼び出しのロジックを知覚することはできませんので、簡単になど。
- RPCフレームワークを実現するためには、単に基本的に完了した以下の3点を実現する必要があります。
- コールIDマップ：ファンクション文字列も整数IDを使用することができ、直接使用することができます。一般的なマッピングテーブルは、ハッシュテーブルです。
- シリアライズデシリアライズ：あなたがあなた自身を書くことができ、またはあなたのよういるProtobufのFlatBuffersを使用することができます。
- ネットワークトランスミッション：TCP最も一般的な、UDPは、HTTP2ことができます;ソケットはまた、独自のを書くことができます。
1 - ローカルコールとは何ですか
言及せず、RPCといえば、分散生まれたこのフィールドのRPCを促します。
、あなたは電卓のインターフェースを持っていると仮定し計算し、その実装クラスCalculatorImpl、システムまたは単一のアプリケーションは、あなたが追加操作、新しいダイレクトCalculatorImplを実行するためにaddメソッド電卓を呼び出し、その後、ライン上のaddメソッドを呼び出す必要がありますこれは実際には非常に一般的であるローカル関数呼び出しために、同じアドレス空間、または同じメモリでは、そのスタックおよび方法により、引数スタックを実現することができます。
2-何を（ローカルコールの変換をデカップリング）されているリモート・プロシージャ・コール
さて、このような高い性能と高い信頼性などの要因を考慮して、あなたが分散アプリケーションのためのシステムを改革することを決定し、多くは、このような上記の電卓のように別々の機能、実行を共有することになる、あなたは別のサービスにそれを置きます内部には、他のサービスがそれを呼び出すようにしましょう。
質問がある今回は、その後、どのようにBメソッドCalculatorImplコールサービスに追加し、クラス内CalculatorImplサービスAがありませんでしたか？
一部の学生は、RESTfulなサービス・インターフェースBを公開し、B / Sの構造はそう呼ばれて模倣することができ、と言うだろう、そしてA RESTfulな追加するための間接的な方法CalculatorImplコールインタフェースを呼び出すことによって、このサービス。
まあ、これは非常に近いRPCのですが、その場合、各呼び出しは、コードhttpリクエストの束を記述する必要がされていないこと、それを開始するために？例えばhttpClient.sendRequest ...のように、それは、ユーザーがこのように、以下のリモートプロシージャコールにそれを感じるように、リモート呼び出しを開始するために、ローカルの呼び出しと同じにすることはできません。
@Reference プライベート電卓電卓; ... calculator.add（1,2）。 ...
このとき、一部の学生はと、言うプロキシモード（TODO）うん！オブジェクトがスキャンされる場合、好ましくは、それは春のIoCと組み合わせて使用されると、注入算出スプリングを介してオブジェクトを、注射は、注釈は、それが容器にプロキシオブジェクトは、プロキシオブジェクトを生成し得、@Referenceを添加しました。プロキシの内部には、RPCリモートプロシージャコールHttpClientを介して達成されます。
おそらく、この説明上記より抽象的、しかしそれは、アリ・ダボなどのアイデアやソリューションのRPCフレームワークを、解決すべき多くの問題です。
要約すると、2つのRPCの問題に対処します：
- 分散システム、サービス呼び出しの間で問題を解決します。
- ローカル電話への長距離電話をさせることが可能な限り簡単に、発信者は、リモート呼び出しのロジックを知覚できない場合。
3 - 完全なフレームのRPC
サービス発見、負荷、フォールトトレラント、ネットワーク送信、等組立配列を含むRPCを使用する典型的なシナリオでは、ここで「RPCプロトコル、」それがどのようにネットワークの伝送手順のシーケンスを示しています。
3.1 RPCコア機能
RPC 的核心功能是指实现一个 RPC 最重要的功能模块，就是上图中的”RPC 协议”部分：
一个 RPC 的核心功能主要有 5 个部分组成，分别是：客户端、客户端 Stub、网络传输模块、服务端 Stub、服务端等。
下面介绍核心 RPC 框架的重要组成：
- 客户端(Client)：服务调用方。
- 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数数据信息打包成网络消息，再通过网络传输发送给服务端。
- 服务端存根(Server Stub)：接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理。
- 服务端(Server)：服务的真正提供者。
- Network Service：底层传输，可以是 TCP 或 HTTP。
3.2 RPC 核心之三个技术点
RPC 的核心功能主要由 5 个模块组成，如果想要自己实现一个 RPC，最简单的方式要实现三个技术点，分别是：
- 服务寻址
- 数据流的序列化和反序列化
- 网络传输
服务寻址
1-说明：服务寻址可以使用 Call ID 映射。在本地调用中，函数体是直接通过函数指针来指定的，但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。
所以在 RPC 中，所有的函数都必须有自己的一个 ID。这个 ID 在所有进程中都是唯一确定的。
客户端在做远程过程调用时，必须附上这个 ID。然后我们还需要在客户端和服务端分别维护一个函数和Call ID的对应表。
当客户端需要进行远程调用时，它就查一下这个表，找出相应的 Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
2-实现方式：服务注册中心。要调用服务，首先你需要一个服务注册中心去查询对方服务都有哪些实例。Dubbo 的服务注册中心是可以配置的，官方推荐使用 Zookeeper。
3-实现案例：RMI (Remote Method Invocation，远程方法调用)，也就是 RPC 本身在Java里面的实现方式，网络协议使用的是TCP。
RMI 架构图
Registry(服务发现)：借助 JNDI （TODO）发布并调用了 RMI 服务。实际上，JNDI 就是一个注册表，服务端将服务对象放入到注册表中，客户端从注册表中获取服务对象。
RMI 服务在服务端实现之后需要注册到 RMI Server 上，然后客户端从指定的 RMI 地址上 Lookup 服务，调用该服务对应的方法即可完成远程方法调用。
Registry 是个很重要的功能，当服务端开发完服务之后，要对外暴露，如果没有服务注册，则客户端是无从调用的，即使服务端的服务就在那里。
序列化和反序列化
客户端怎么把参数值传给远程的函数呢?在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。
但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。
这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。
只有二进制数据才能在网络中传输，序列化和反序列化的定义是：
- 将对象转换成二进制流的过程叫做序列化
- 将二进制流转换成对象的过程叫做反序列化
这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。
网络传输
网络传输：远程调用往往用在网络上，客户端和服务端是通过网络连接的。
所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把 Call ID 和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。
只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。
尽管大部分 RPC 框架都使用 TCP 协议，但其实 UDP 也可以，而 gRPC 干脆就用了 HTTP2。
TCP 的连接是最常见的，简要分析基于 TCP 的连接：通常 TCP 连接可以是按需连接(需要调用的时候就先建立连接，调用结束后就立马断掉)，也可以是长连接(客户端和服务器建立起连接之后保持长期持有，不管此时有无数据包的发送，可以配合心跳检测机制定期检测建立的连接是否存活有效)，多个远程过程调用共享同一个连接。
所以，要实现一个 RPC 框架，只需要把以下三点实现了就基本完成了：
- Call ID 映射：可以直接使用函数字符串，也可以使用整数 ID。映射表一般就是一个哈希表。
- 序列化反序列化：可以自己写，也可以使用 Protobuf 或者 FlatBuffers 之类的。
- 网络传输库：可以自己写 Socket，或者用 Asio，ZeroMQ，Netty 之类。
3.3 RPC 核心之网络传输协议
要实现一个 RPC，需要选择网络传输的方式。
在 RPC 中可选的网络传输方式有多种，可以选择 TCP 协议、UDP 协议、HTTP 协议。
每一种协议对整体的性能和效率都有不同的影响，如何选择一个正确的网络传输协议呢?首先要搞明白各种传输协议在 RPC 中的工作方式。
基于 TCP 协议的 RPC 调用
由服务的调用方与服务的提供方建立 Socket （TODO）连接，并由服务的调用方通过 Socket 将需要调用的接口名称、方法名称和参数序列化后传递给服务的提供方，服务的提供方反序列化后再利用反射调用相关的方法。
***将结果返回给服务的调用方，整个基于 TCP 协议的 RPC 调用大致如此。
但是在实例应用中则会进行一系列的封装，如 RMI 便是在 TCP 协议上传递可序列化的 Java 对象。
基于 HTTP 协议的 RPC 调用
该方法更像是访问网页一样，只是它的返回结果更加单一简单。
其大致流程为：由服务的调用者向服务的提供者发送请求，这种请求的方式可能是 GET、POST、PUT、DELETE 等中的一种，服务的提供者可能会根据不同的请求方式做出不同的处理，或者某个方法只允许某种请求方式。
而调用的具体方法则是根据 URL 进行方法调用，而方法所需要的参数可能是对服务调用方传输过去的 XML 数据或者 JSON 数据解析后的结果，***返回 JOSN 或者 XML 的数据结果。
由于目前有很多开源的 Web 服务器，如 Tomcat，所以其实现起来更加容易，就像做 Web 项目一样。
两种方式对比
- 基于 TCP 的协议实现的 RPC 调用
- 优点：由于 TCP 协议处于协议栈的下层，能够更加灵活地对协议字段进行定制，减少网络开销，提高性能，实现更大的吞吐量和并发数。
- 缺点：但是需要更多关注底层复杂的细节，实现的代价更高。同时对不同平台，如安卓，iOS 等，需要重新开发出不同的工具包来进行请求发送和相应解析，工作量大，难以快速响应和满足用户需求。
- 基于 HTTP 协议实现的 RPC 调用
- 优点：可以使用 JSON 和 XML 格式的请求或响应数据。而 JSON 和 XML 作为通用的格式标准(使用 HTTP 协议也需要序列化和反序列化，不过这不是该协议下关心的内容，成熟的 Web 程序已经做好了序列化内容)，开源的解析工具已经相当成熟，在其上进行二次开发会非常便捷和简单。
- 缺点：但是由于 HTTP 协议是上层协议，发送包含同等内容的信息，使用 HTTP 协议传输所占用的字节数会比使用 TCP 协议传输所占用的字节数更高。因此在同等网络下，通过 HTTP 协议传输相同内容，效率会比基于 TCP 协议的数据效率要低，信息传输所占用的时间也会更长，当然压缩数据，能够缩小这一差距。
参考
RPCが何であるかを私の妻に説明する方法1.柳、 https://www.jianshu.com/p/2accc2840a1b