1 有时候我们为了thrift的也能自动支持http访问，需要处理一下。
于是想到了json-rpc,找了一下，有人已经有人同样解决过:https://www.jianshu.com/p/a757453523ae
这个文章我看了，方案对我没什么太大的意义（因为我不想改开源的源码，这样不方便升级），给我的帮助是提前知道有两个问题需要解决（第一次玩jsonrpc），两个问题:
1 thrift生成代码不适合加注释(其实就是序列化与反序列化的时候使用)，加了再重新generate就需要再手工加，这显然不现实
２ thrift 生成的实体中有多余字段，需要过滤掉，不过滤也不是不行，但是毕竟看上去碍眼
2 改进
上面这个文章的思路是没问题，但是关于他想做开源的源码级别上的修改，
我觉得这样以后升级会是个麻烦，于是花了一个小时仔细琢磨了一下，发现还是有个空子可以钻。
我是做了两个地方的改进，就可以完成不需要改开源的源码
2.1 改进点1
为了解决问题１也就是thrift加注释的事，他的方案是改了开源的源代码，但是我看了，没必要，我仔细读了一下代码，
发现他内部有一个缓存，于是我们可以在系统启动的时候先写缓存，这样就不用改源代码折腾了
这个空子就涉及到
钻空子也很简单,利用反射就完成了
只需要在系统启动的时候就开始更新即可
但是有一点特别重要，这个map维护的是接口中变量名的关系,如果是兼容jdk8之前的，需要稍微多一个环节，那就是从实现类中取方法中的变量名，从接口中取同名的method然后维护这个关系即可,为了实现这个需要名称进行比较（更准确需要连参数一起比较），但是只简单比较会称不会出问题呢，于是我翻了它自己映射method时是如何映射的，因为这个映射过程肯定是要找出methods的
我翻了一下源码
com.googlecode.jsonrpc4j.ReflectionUtil#findCandidateMethods
可见他就是简单比较个名字，json-rpc估计无法处理重载,他比较个名字我也比较个名字，这样不会有什么问题。
3 前面说到我是提前维护这个map,这个map其实就是要变量与注解的关系
呃，看了一下，构建annotation需要一个继承即可
４ 顺便说第一句，第一次玩这玩意，日志是需要的吧
client端我翻了一下源码，在这里可以看到原始请求,服务端的由于时间关系，我随意用了一个interceptor,不知道是不是最佳方案
com.googlecode.jsonrpc4j.JsonRpcClient#internalWriteRequest
客户端后来也翻代码了，其实也可以加一个Listener就能看到来回的报文了
5 顺便说一句如何过滤thrift转json多余字段的问题。
我直接采用MixIn来完成的。细节不再描述
