thrift

1 有时候我们为了thrift的也能自动支持http访问，需要处理一下。 于是想到了json-rpc,找了一下，有人已经有人同样解决过: https://www.jianshu.com/p/a757453523ae 这个文章我看了，方案对我没什么太大的意义（因为我不想改开源的源码，这样不方便升级），给我的帮助是提前知道有两个问题需要解决（第一次玩jsonrpc），两个问题: 1 thrift生成代码不适合加注释(其实就是序列化与反序列化的时候使用)，加了再重新generate就需要再手工加，这显然不现实 ２ thrift 生成的实体中有多余字段，需要过滤掉，不过滤也不是不行，但是毕竟看上去碍眼 2 改进 上面这个文章的思路是没问题，但是关于他想做开源的源码级别上的修改， 我觉得这样以后升级会是个麻烦，于是花了一个小时仔细琢磨了一下，发现还是有个空子可以钻。 我是做了两个地方的改进，就可以完成不需要改开源的源码 2.1 改进点1 　　为了解决问题１也就是thrift加注释的事，他的方案是改了开源的源代码，但是我看了，没必要，我仔细读了一下代码， 发现他内部有一个缓存，于是我们可以在系统启动的时候先写缓存，这样就不用改源代码折腾了 　　这个空子就涉及到 钻空子也很简单,利用反射就完成了 只需要在系统启动的时候就开始更新即可 但是有一点特别重要，这个map维护的是接口中变量名的关系

前言 Thrift是一个轻量级、跨语言的远程服务调用框架，最初由Facebook开发，后面进入Apache开源项目。它通过自身的IDL中间语言, 并借助代码生成引擎生成各种主流语言的RPC服务端/客户端模板代码。 Thrift支持多种不同的编程语言，包括C++、Java、Python、PHP、Ruby等，本系列主要讲述基于Java语言的Thrift的配置方式和具体使用。 正文 Thrift的技术栈 Thrift对软件栈的定义非常的清晰, 使得各个组件能够松散的耦合, 针对不同的应用场景, 选择不同是方式去搭建服务。 Thrift软件栈分层从下向上分别为：传输层(Transport Layer)、协议层(Protocol Layer)、处理层(Processor Layer)和服务层(Server Layer)。 传输层(Transport Layer)：传输层负责直接从网络中读取和写入数据，它定义了具体的网络传输协议；比如说TCP/IP传输等。 协议层(Protocol Layer)：协议层定义了数据传输格式，负责网络传输数据的序列化和反序列化；比如说JSON、XML、二进制数据等。 处理层(Processor Layer)：处理层是由具体的IDL（接口描述语言）生成的，封装了具体的底层网络传输和序列化方式，并委托给用户实现的Handler进行处理。 服务层(Server

前言 Thrift 提供的网络服务模型：单线程、多线程、事件驱动，从另一个角度划分为：阻塞服务模型、非阻塞服务模型。 阻塞服务模型： TSimpleServer 、 TThreadPoolServer 。 非阻塞服务模型： TNonblockingServer 、 THsHaServer 和 TThreadedSelectorServer 。 TServer 类的层次关系： 正文 TServer TServer 定义了静态内部类 Args ， Args 继承自抽象类 AbstractServerArgs 。 AbstractServerArgs 采用了建造者模式，向 TServer 提供各种工厂： 工厂属性 工厂类型 作用 ProcessorFactory TProcessorFactory 处理层工厂类，用于具体的TProcessor对象的创建 InputTransportFactory TTransportFactory 传输层输入工厂类，用于具体的TTransport对象的创建 OutputTransportFactory TTransportFactory 传输层输出工厂类，用于具体的TTransport对象的创建 InputProtocolFactory TProtocolFactory 协议层输入工厂类，用于具体的TProtocol对象的创建