thrift 重要的几个组件有 ：数据类型，transport，protocol，versioning，processor
1.数据类型 thrift的数据类型有1.一些原生类型，比如string，int等等 2.container 有list set map 3. 自定义的复杂类型struct
2.transport 和nio的channel很像，负责底层数据的读写，有很多种类型，比如从socket，文件，或者memory中读写等
3.protocal 负责组织数据流的格式，数据的序列化，反序列化等等
4.versioning thrift每个组件都可以有自己实现版本控制的方法。在struct里，通过把idetifyID和数据类型结合起来构成这个字段的唯一标识码。在transport和protocol里，可以分别对传输的数据进行自定义的版本标识
对于service的接口，方法名貌似不能重复，至少看源码的时候，发现直接根据方法名进行hash，找到对应的processFunction。方法的入参，和struct一样，通过identifyId和数据类型来共同标识一个参数。
基于通过identifyID和数据类型结合的方式来定义一个变量的方式，带来的一个问题是，在增加或者删除变量的时候，不要对原有的字段的identifyID进行修改，否则会出现反序列化失败的情况
5.processor 在processor里调用transport和protocol对数据进行读写，序列化和反序列化，还有中间的业务逻辑的调用等等
看了下TBaseProcessor 的实现，发现现在代码里基本都是通过这个基类来实现Processor的功能。每个方法都被抽象成一个ProcessFunction，然后通过方法名来进行hash，拿到对应的ProcessFunction，然后执行相应的方法。
ProcessFunction中，首先通过一个需要子类实现的getEmptyArgsInstance方法，实例化一个代表方法中参数的对象，然后通过这个对象来对inputPtotocol进行读取，把参数都读进来。
读进来后，再通过getResult方法，来对真正的方法进行调用，拿到结果，然后再通过outPutPtotocol写出去
这种Procesor实现的好处是，不用通过反射来对目标方法进行调用 坏处是，每个方法都要创建相应的Function类，但是这些代码都是自动生成的，不需要我们自己去实现
另一个比较重要的组件是Server，Server提供的功能是把服务（ip，端口等）向外暴露，对请求进行处理（对connection进行接收，数据读取等），比如是单线程处理，还是多线程处理，还是在线程池里进行处理。对上述的组件进行组合，比如选用什么样的protocol，选用什么样的transport等，并调用相应的组件对数据进行读取和解析等等。
