RPC服务框架探索之Thrift

Posted 2021-04-24 欢歌流浪

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了RPC服务框架探索之Thrift相关的知识，希望对你有一定的参考价值。

前言
架构服务化后，需要实现一套方便调用各服务的框架，现在开源如日中天，优先会寻找开源实现，如果没有合适自家公司业务的，才会考虑从零开发，尤其是一切以KPI为准绳的公司，谁会跟钱过不去？N个月之前，公司大神就开始调研了，最后选中了Thrift这个RPC服务框架。使用不熟悉的技术，我会感到很恐惧，它就相当于一个黑盒，我对它一无所知，它是如何运转的？出了问题该如何解决？带着一丝不安，查阅了相关技术文档。

RPC
很早之前听说过soap,restful api,rpc之类的服务协议，一直都没有机会深入实践，对它们理解的不够深。它们的目的都是提供本地调用远程服务的能力，只是实现方式不同而已。RPC(remote procedure call)意思是远程过程调用，编码时可以把它当作本地方法一样调用，无需关心内部的实现细节，对于调用方很友好很简单。我查阅资料，发现RPC之类的东西很早很早以前就出现了，存在即是合理的，肯定有它的理由。跟本地调用相比有什么优点缺点呢？根据查阅的资料以及自己的理解总结如下：
优势
1 提高系统吞吐能力
2 业务服务解耦
3 更易构建服务分布式集群
4 基础服务重用更方便
劣势
1 因网络开销方法执行时间更长
2 系统更复杂对运维挑战很大
3 排错成本增加
4 数据序列化消耗CPU资源
现在是移动互联时代，数据无时无刻不在产生着，随着时间的推移，随着用户数的增加，随着更多业务的开展，随着功能迭代的频繁，只有业务服务化只有更易构建分布式集群的架构才能应对这些挑战，毕竟单台服务器的能力是有限的，即使是IOE这种高端设备。尤其是现在地下黑产如此猖獗的今天，时不时的遭受到类DDOS攻击，可以方便扩展节点的架构是多么重要，否则会死的很惨。
因此通过RPC协议实现微服务架构是利大于弊的。

Thrift
Thrift是RPC服务协议的一种实现，它是由Facebook开发，2007年开源并且2008年成为Apache开源项目。它的实现目标是支持多语言跨平台简单易使用高性能对业务开发透明屏蔽实现细节专注业务开发。大部分语言提供了类库，可以让开发人员只专注在业务接口实现部分。

实现原理
它由传输层，协议层，处理器，服务层所组成，每个部分不互相依赖，职责单一。
传输层：流协议传输数据，支持socket，http，文件等媒介
协议层：数据封包解包，支持binary，compact，json等
处理器：接口代理，请求转发给相应接口处理
服务层：组装传输层，协议层，处理器，提供RPC服务
客户端调用接口-》客户端数据封包-》传输层-》服端解包-》服端处理器-》服端接口处理。处理完成遵循同样的链路响应。

服端网络模型
简单说明，不做深入了解。
1 单进程
2 单进程多线程
3 单进程事件驱动

IDL
IDL(interface description language)接口描述语言，它包含简单数据类型定义，复杂数据类型结构体定义，复杂数据类型列表定义集合定义，异常类型定义，命名空间声明，接口定义规范等，通过这些规范的组合可以定义好任意复杂的接口，定义好之后，使用IDL编译器可以生成指定语言源码，传输层协议层处理器这些代码会自动生成，只需要专注业务接口具体实现即可。具体类型定义参考官方文档吧。

安装
安装很简单，不同的系统官方文档都有说明，不需要完全死板按照步骤执行，相关依赖如果存在可以跳过相应步骤。安装成功之后就可以使用thrift命令编译IDL文件了。

命令
定义好的IDL文件名以.thrift结尾，通过thrift编译。命令参数说明如下：

实践
平常使用php开发，所以使用PHP实践下，对它有更深入的了解，一般服端开发使用编译型的语言，执行效率更高，以实现简单的NoSQL功能为例子(源码里有各种语言的实现例子)。
1 接口定义(nosql.thrift)

RPC服务框架探索之Thrift