thrift

一、TThreadedSelectorServer线程模型： 该服务会启动1个AcceptThread， 2个SelectorThread（默认为2个，可设置），一个woker线程池（池的大小可设置）， 一个AcceptThread执行accept操作，将accept到的Transport交给SelectorThread线程， AcceptThread中有个balance均衡器分配到SelectorThread； SelectorThread执行read，write操作，read到一个 FrameBuffer （封装了方法名，参数，参数类型等数据，和读取写入，调用方法的操作）交给WorkerProcess线程池执行方法调用。 二、SelectorThread中FrameBuffer读取的过程 每个SelectorThread线程 使用 FrameBuffer 来读取数据。 org.apache.thrift.server.AbstractNonblockingServer.FrameBuffer： private boolean internalRead() { try { if (trans_.read(buffer_) < 0) { return false; } return true; } catch (IOException e) { LOGGER.warn("Got

前言 架构服务化后，需要实现一套方便调用各服务的框架，现在开源如日中天，优先会寻找开源实现，如果没有合适自家公司业务的，才会考虑从零开发，尤其是一切以KPI为准绳的公司，谁会跟钱过不去？N个月之前，公司大神就开始调研了，最后选中了Thrift这个RPC服务框架。使用不熟悉的技术，我会感到很恐惧，它就相当于一个黑盒，我对它一无所知，它是如何运转的？出了问题该如何解决？带着一丝不安，查阅了相关技术文档。 RPC 很早之前听说过soap,restful api,rpc之类的服务协议，一直都没有机会深入实践，对它们理解的不够深。它们的目的都是提供本地调用远程服务的能力，只是实现方式不同而已。RPC(remote procedure call)意思是远程过程调用，编码时可以把它当作本地方法一样调用，无需关心内部的实现细节，对于调用方很友好很简单。我查阅资料，发现RPC之类的东西很早很早以前就出现了，存在即是合理的，肯定有它的理由。跟本地调用相比有什么优点缺点呢？根据查阅的资料以及自己的理解总结如下： 优势 1 提高系统吞吐能力 2 业务服务解耦 3 更易构建服务分布式集群 4 基础服务重用更方便 劣势 1 因网络开销方法执行时间更长 2 系统更复杂对运维挑战很大 3 排错成本增加 4 数据序列化消耗CPU资源 现在是移动互联时代，数据无时无刻不在产生着，随着时间的推移，随着用户数的增加

一、RPC是什么 在很久之前的单机时代，一台电脑中跑着多个进程，进程之间没有交流各干各的，就这样过了很多年。突然有一天有了新需求，A进程需要实现一个画图的功能，恰好邻居B进程已经有了这个功能，偷懒的程序员C想出了一个办法：A进程调B进程的画图功能。于是出现了IPC（Inter-process communication，进程间通信）。就这样程序员C愉快的去吃早餐去了！ 又过了几年，到了互联网时代，每个电脑都实现了互联互通。这时候雇主又有了新需求，当时还没挂的A进程需要实现使用tensorflow识别出笑脸 >_< 。说巧不巧，远在几千里的一台快速运行的电脑上已经实现了这个功能，睡眼惺忪的程序媛D接手了这个A进程后借鉴之前IPC的实现，把IPC扩展到了互联网上，这就是RPC(Remote Procedure Call，远程过程调用)。RPC其实就是一台电脑上的进程调用另外一台电脑上的进程的工具。成熟的RPC方案大多数会具备服务注册、服务发现、熔断降级和限流等机制。目前市面上的RPC已经有很多成熟的了，比如Facebook家的Thrift、Google家的gRPC、阿里家的Dubbo和蚂蚁家的SOFA。 二、接口定义语言 接口定义语言，简称IDL,是实现端对端之间可靠通讯的一套编码方案。这里有涉及到传输数据的序列化和反序列化，我们常用的http的请求一般用json当做序列化工具

步骤： 1.安装 Visual C++ ，目前最新是2019版 　　安装工作负载c++桌面开发 　　 2.pip3安装模块 pip3 install pure-sasl==0.5.1 pip3 install thrift-sasl==0.2.1 --no-deps pip3 install thrift==0.9.3 pip3 install impyla==0.14.1 pip3 install bitarray==0.8.3 pip3 install thriftpy==0.3.9 安装时报错： # TypeError: can't concat str to bytes 3.改错 编辑 　　 python安装目录/site-packages/thrift_sasl/__init__.py # 定位到错误的最后一条，在init.py第94行 (注意代码的缩进) header = struct.pack(">BI", status, len(body)) self._trans.write(header + body) 更改为： header = struct.pack(">BI", status, len(body)) if(type(body) is str): body = body.encode() self._trans.write(header + body) 4

系统环境：Mac 开发环境：Idea Python版本：2.7 开发环境准备：idea可安装thrift插件，https://plugins.jetbrains.com/plugin/7331-thrift-support Mac系统安装thrift： brew install thrift 成功后： $ thrift -version Thrift version 0.12.0 编辑Thrift接口文件：ocrservice.thrift，内容如下： namespace cpp test namespace java com.test.thrift service OCRService { string recognizeWithFile(1:binary file, 2:string uuid, 3:map<string, string> meta); } server.py 为服务端代码 # coding=utf-8 import sys reload(sys) sys.setdefaultencoding('utf-8') # Add import thrift. sys.path.append('gen-py') from ocrservice import OCRService from ocrservice.ttypes import * from thrift

RPC（Remote Procedure Call）远程过程调用，关注笔者的同学应该知道之前笔者出过关于Thrift对应的问题，这次主要来说的是Google开源的Grpc，和Thrift有很大的区别Grpc是基于HTTP2.0并且依赖protobuf，为什么又推出关于grpc的文章呢？请大家继续往下看。 附上: 喵了个咪的博客： w-blog.cn 博文实例demo： GitHub - sunmi-OS/grpc-php-to-golang-demo grpc官网： grpc / grpc.io protobuf代码仓库： Releases · protocolbuffers/protobuf · GitHub 一，为什么要用grpc它的优势是什么 一个高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。 gRPC基于HTTP/2标准设计，带来诸如双向流控、头部压缩、单TCP连接上的多复用请求等特性。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。 性能 Grpc PK Thrift 借鉴： 开源RPC（gRPC/Thrift）框架性能评测 - 沧海一滴 - 博客园 PS：笔者也做了对应的性能测试，后面的文章会附上详细步骤