Zeroc ICE -- (RPC) ICE是ZEROC的开源通信协议产品

[vieyahn2017]

ICE是ZEROC的开源通信协议产品，它的全称是：The Internet Communications Engine，翻译为中文是互联网通信引擎，是一个面向对象的中间件，使我们能够以最小的代价构建分布式应用程序。ICE使我们专注于应用逻辑的开发，它来处理所有底层的网络接口编程，这样我们就不用去考虑这样的细节：打开网络连接、网络数据传输的序列化与反序列化、连接失败的尝试次数等。

[vieyahn2017]

https://github.com/zeroc-ice/ice https://github.com/zeroc-ice/ice-demos

[vieyahn2017]

ice & dubbo & thrift & grpc 性能测试对比

[vieyahn2017]

总结 从测试结果可以看出ice的tps遥遥领先，而且并发越高tps比其他越高，其次thrift，dubbo和grpc则差了很多。Grpc最差估计跟用了HTTP2有关。

另外dubbox还支持rest，官方测试rest比kyro要慢1.5倍，本次未对rest测试。

从功能完备性来说ice和dubbo都算比较完备，都有大型生产案例，thrift的服务化功能比较缺失，grpc可能还不够成熟。

Dubbo的插件化机制的确不错，ice初次接触有些概念比较晦涩，经过封装和有详细的资料后要好上许多。

另外《Zeroc Ice权威指南》作者Leader-us对ice的测试结果如下：

Leader-us测试结果Ice则是2.5万，性能差不多是Avro的一倍，综合起来看Avro和thrift的性能应该差不多。

• Apache Avro框架简单，非接口编译的模式灵活度很高，用Json定义的RPC消息结构和方法简单并容易理解

•Http协议的编码和传输机制效率远远低于长连接的Socket模式，本机对比了Avro的Http协议与Netty实现的Socket协议，请求应答消息相同的情况下，HTTP的TPS是500左右，而Netty Socket模式则是1.5万左右，相差很悬殊

•多语言客户端支持并不是那么容易的事情，Avro的Python客户端目前只实现了基本的Http协议，（Java的同时实现了Netty客户端协议），这种情况下，服务端只能也采用Http协议，从而导致并发性能问题

[vieyahn2017]

首先了解什么叫RPC，为什么要RPC，RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

比如说，一个方法可能是这样定义的：Employee getEmployeeByName(String fullName)。 那么：
首先，要解决通讯的问题，主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
第二，要解决寻址的问题，也就是说，A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。
第三，当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。
第四，B服务器收到请求后，需要对参数进行反序列化（序列化的逆操作），恢复为内存中的表达方式，然后找到对应的方法（寻址的一部分）进行本地调用，然后得到返回值。
第五，返回值还要发送回服务器A上的应用，也要经过序列化的方式发送，服务器A接到后，再反序列化，恢复为内存中的表达方式，交给A服务器上的应用。

[vieyahn2017]

为什么RPC呢？
就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，比如比如不同的系统间的通讯，甚至不同的组织间的通讯。由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用，RPC的协议有很多，比如最早的CORBA，Java RMI，Web Service的RPC风格，Hessian，Thrift，甚至Rest API。

关于Netty:

而Netty框架不局限于RPC，更多的是作为一种网络协议的实现框架，比如HTTP，由于RPC需要高效的网络通信，就可能选择以Netty作为基础。除了网络通信，RPC还需要有比较高效的序列化框架，以及一种寻址方式。如果是带会话（状态）的RPC调用，还需要有会话和状态保持的功能。
大体上来说，Netty就是提供一种事件驱动的，责任链式（也可以说是流水线）的网络协议实现方式。网络协议包含很多层次，很多部分组成，如传输层协议，编码解码，压缩解压，身份认证，加密解密，请求的处理逻辑，怎么能够更好的复用，扩展，业界通用的方法就是责任链，一个请求应答网络交互通常包含两条链，一条链（Upstream）是从传输层，经过一系列步骤，如身份认证，解密，日志，流控，最后到达业务层，一条链（DownStream）是业务层返回后，又经过一系列步骤，如加密等，又回到传输层。（图片来源：ChannelPipeline (The Netty Project API Reference (3.2.6.Final))）这样每一层都有一个处理接口，都可以进行不同的操作，比如身份认证，加解密，日志，流控，将不同的处理实现像拼积木那样插接起来就可以实现一个网络协议了（快速开发）。每一层都有自己的实现，上层不需要关注面向网络的操作（可维护）。Netty已经提供了很多实现。（图片来源：http://docs.jboss.org/netty/3.1/guide/html/architecture.html）
当然Netty还有许多好处，比如对非阻塞IO（NIO）的支持，比如在链上传递时最大程度的减少buffer的copy（高性能）。

[vieyahn2017]

以上来自 https://www.zhihu.com/question/25536695
谁能用通俗的语言解释一下什么是 RPC 框架？

[vieyahn2017]

远程过程调用带来的新问题在远程调用时，我们需要执行的函数体是在远程的机器上的，也就是说，Multiply是在另一个进程中执行的。

这就带来了几个新问题：

1. Call ID映射。我们怎么告诉远程机器我们要调用Multiply，而不是Add或者FooBar呢？
   在本地调用中，函数体是直接通过函数指针来指定的，我们调用Multiply，编译器就自动帮我们调用它相应的函数指针。但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以，在RPC中，所有的函数都必须有自己的一个ID。这个ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，必须附上这个ID。然后我们还需要在客户端和服务端分别维护一个 {函数 <--> Call ID} 的对应表。两者的表不一定需要完全相同，但相同的函数对应的Call ID必须相同。当客户端需要进行远程调用时，它就查一下这个表，找出相应的Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。

2. 序列化和反序列化。客户端怎么把参数值传给远程的函数呢？在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。甚至有时候客户端和服务端使用的都不是同一种语言（比如服务端用C++，客户端用Java或者Python）。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。

3. 网络传输。远程调用往往用在网络上，客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把Call ID和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。尽管大部分RPC框架都使用TCP协议，但其实UDP也可以，而gRPC干脆就用了HTTP2。Java的Netty也属于这层的东西。

所以，要实现一个RPC框架，其实只需要把以上三点实现了就基本完成了。
Call ID映射可以直接使用函数字符串，也可以使用整数ID。
映射表一般就是一个哈希表。序列化反序列化可以自己写，也可以使用Protobuf或者FlatBuffers之类的。
网络传输库可以自己写socket，或者用asio，ZeroMQ，Netty之类。

[vieyahn2017]

下面我将展示一下安装过程并且演示一下集群环境下的failover。我们假设安装用的是helm chart。

Stolon 架构图 摘抄自Stolon的介绍。

Stolon 是由3个部分组成的： keeper：他负责管理PostgreSQL的实例汇聚到由sentinel(s)提供的clusterview。 sentinel：it负责发现并且监控keeper，并且计算最理想的clusterview。 proxy：客户端的接入点。它强制连接到右边PostgreSQL的master并且强制关闭连接到由非选举产生的master。

Stolon 用etcd或者Consul作为主要的集群状态存储。