RPC TAF（TARS）框架初学

RPC简介

RPC 即远程过程调用（Remote Procedure Call Protocol，简称RPC），像调用本地服务(方法)一样调用服务器的服务(方法)。通常的实现有 XML-RPC , JSON-RPC , 通信方式基本相同, 所不同的只是传输数据的格式.

RPC是分布式架构的核心，按响应方式分如下两种：

同步调用：客户端调用服务方方法，等待直到服务方返回结果或者超时，再继续自己的操作

异步调用：客户端把消息发送给中间件，不再等待服务端返回，直接继续自己的操作。

同步调用的实现方式有WebService和RMI。Web Service提供的服务是基于web容器的，底层使用http协议，因而适合不同语言异构系统间的调用。RMI实际上是Java语言的RPC实现，允许方法返回 Java 对象以及基本数据类型，适合用于JAVA语言构建的不同系统间的调用。

异步调用的JAVA实现版就是JMS(Java Message Service)，目前开源的的JMS中间件有Apache社区的ActiveMQ、Kafka消息中间件，另外有阿里的RocketMQ。

为什么使用RPC

在刚开始接触RPC时，确实很难懂得这种框架的用途的所在。像通常的客户端——服务器模型，在调用服务端服务时，一般都是直接使用http协议（get和post方法），底层一点的就是直接操纵网络层协议（tcp）。而使用RPC框架，是让你在调用远端服务时，像调用本地服务一样。RPC使用的更多情况可能是你写的服务端程序需要调用另一个服务端提供的服务。

从使用方面看，Http接口只关注服务提供方（服务端），对于客户端怎么调用，调用方式怎样并不关心，通常情况下，客户端使用Http方式进行调用时，只要将内容进行传输即可，这样客户端在使用时，需要更关注网络方面的传输，比较不适用与业务方面的开发；

而RPC服务则需要客户端接口与服务端保持一致，服务端提供一个方法，客户端通过接口直接发起调用，业务开发人员仅需要关注业务方法的调用即可，不再关注网络传输的细节，在开发上更为高效。（PRC是服务端提供好方法给客户端调用。定位到类，然后通过类去调用方法。）

从性能角度看，使用Http时，Http本身提供了丰富的状态功能与扩展功能，但也正由于Http提供的功能过多，导致在网络传输时，需要携带的信息更多，从性能角度上讲，较为低效。而RPC服务网络传输上仅传输与业务内容相关的数据，传输数据更小，性能更高。

从运维角度看，使用Http接口时，常常使用一个前端代理，来进行Http转发代理请求的操作，需要进行扩容时，则需要去修改代理服务器的配置，较为繁琐，也容易出错。而使用RPC方式的微服务，则只要增加一个服务节点即可，注册中心可自动感知到节点的变化，通知调用客户端进行负载的动态控制，更为智能，省去运维的操作。

RPC框架要解决的问题

通讯问题 : 主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
寻址问题： A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。
序列化与反序列化：当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。同理，B服务器接收参数要将参数反序列化。B服务器应用调用自己的方法处理后返回的结果也要序列化给A服务器，A服务器接收也要经过反序列化的过程。

RPC框架的流程

服务调用方（client）(客户端)以本地调用方式调用服务；
client stub（客户端存根）接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；在Java里就是序列化的过程
client stub找到服务地址，并将消息通过网络发送到服务端；
server stub收到消息后进行解码,在Java里就是反序列化的过程；
server stub根据解码结果调用本地的服务；
本地服务执行处理逻辑；
本地服务将结果返回给server stub；
server stub将返回结果打包成消息，Java里的序列化；
server stub将打包后的消息通过网络并发送至消费方
client stub接收到消息，并进行解码, Java里的反序列化；
服务调用方（client）得到最终结果。

RPC框架的目标就是把2-10步封装起来

RPC框架的实现及服务的发布

参考：你应该知道的RPC原理

这里顺带说一下BIO,NIO,AIO，其实就是网络IO的几种模式（阻塞IO,非阻塞IO，异步IO），还有一种更常用的多路IO复用，详见：select用法&原理详解（源码剖析）

TAF简介

TaF是腾讯内部使用的框架，TARS是该框架的开源版本（主要区别在于运维侧，精简和优化了和内部系统耦合比较深、以及内部运维管理相关的一些功能特性）TARS主要是支持多语言的高性能RPC开发框架和配套一体化的服务治理平台，可以帮助企业或者用户以微服务的方式快速构建稳定可靠的分布式应用。

框架功能

IDL（接口定义语言）：统一不同语言的访问协议，二进制、可扩展、代码自动生成、支持多平台。
RPC：支持同步、异步、单向调用（客户端发出调用请求后就结束调用，服务端不返回调用结果）。
高性能：框架提供10w/s以上的吞吐量。
容错：任何一台服务down掉不影响业务访问。
伸缩性：服务可以方便的平行扩展。
管理：在web上就能对系统的服务进行部署、发布、上线、扩容、缩容等管理操作。

这便是Tars微服务架构的雏形，有了它之后，业务开发人员开始聚焦业务真正的逻辑，提高了开发效率，系统的运营管理开始简单化、规范化、流程化，提升了运维效率。

框架结构

关于框架结构的介绍详见文章：腾讯开源基于微服务的平台Tars：RPC开发、服务治理及一体化运营管理

在了解这些框架的知识时，涉及到几个小的知识点：

IP收敛

一个公司提供的服务可能需要用到第三方服务，这时候第三方服务需要对这个公司进行安全认证。常用的方法就是将这个公司使用的服务器IP地址列入白名单中。但这种做法在维护上很有问题，公司可能因为扩容或者是由于使用云服务器而导致IP地址变更等问题，导致第三方服务使用失败。因此，可以在一个固定IP的服务器上封装第三方服务作为一个内部微服务，提供给其他服务使用。这就是收敛企业对外访问的 IP 地址。详见文章：使用代理服务器收敛服务外网IP

灰度放量

灰度放量，就是从产品版本A到版本B之间进行发布或测试的办法。
有如从黑色到白色中间，需要灰色过渡一下。

灰度放量，就是选择部分用户，提供新升级的版本享受试用。一般又叫灰度测试。

灰度测试的形式和对比测试（AB test）有些相似。
不同的是，AB test较重注重两种方案之间的测试比较，灰度测试一般是在已有产品功能升级上的测试比较。

对于一些对用户需求和反馈把握不住的功能，新版本可能造成反馈效果不确定的时候，可以用灰度放量，让部分用户先升级到新的版本功能，测试用户的接受程度和使用数据变化。
一方面提供依据改进新版本。
一方面评估最终效果是否值得全面升级。

所以灰度放量，很重要的一点是要可以通过“放量”的用户，进行跟踪的数据比较，结合用户访谈等其他调研手段获得反馈。

在互联网产品中，灰度放量有诸如通过IP地址，用户ID的选择性方式实现。最近比较流行的方式就是提供版本测试的邀请码，或者申请的方式为少量用户提供新版本试用。新浪微博V5版本的测试、人人网的个人主页的时间线模式，就是采用的这种方式“放量”。

通信协议之序列化

详见文章：通信协议之序列化

个人感觉，IDL是一种语言，而JCE协议就是使用这种语言的协议。对于JCE的学习还在进行当中。

文本协议和二进制协议

App与后台通信：从文本协议到二进制协议

可能有用的资料

一个高性能RPC框架原理剖析

TAF 必修课（一）：整体架构理解

TAF 入门源码学习总结

Tencent/Tars

这种大牛的技术成果，不是三言两语就能学懂看会的。关于TAF平台的使用，还要在日后慢慢摸索~~