公司 RPC 使用 map 进行传输，怎么干掉它

[zwMuZhi]

公司规模也不小，但是创建公司后一直都是使用 map 当对象，导致自研 RPC 框架也是基于 map 去传输，想转换为对象进行开发。 目前的想法是在调用 RPC 前把 Bean 转为 Map，返回结果再把 Bean 转化为 Map，但是这样如果传入或者返回的是 List，加一层转换的操作肯定会降低性能，数据量比较大的时候容易出问题，有没有什么比较好的建议或者方案可以解决呢

[billlee]

没理解 Bean 转 Map 和传入返回 List 有什么关系？

[zwMuZhi]

@billlee 确实是我没描述清楚，这里是指 List<Map>这种结构，如果需要做转化，就需要遍历一遍 List，去 Map 中取值生成对象

[billlee]

我觉得可以先试试直接用 jackson 做 bean 和 map 之间的转化，可能性能没有你想象的那么差？

如果不行，再通过代码生成或 asm 的方式生成 bean 和 map 之间转化的方法，以避免反射开销。

如果还想进一步提升，可以分析 RPC 框架使用的序列化协议，绕过 map 直接实现从 bean 序列化成对应数据流的方法

[luban]

用 map 是为了方便修改 Bean 结构吗

[potatowish]

没有必要，你们这自研的 rpc 传输的数据结构就是基于 map 对象，又加一层 bean 的转换，没方便多少，性能也下降了，要么把框架升级了要么就不要折腾

[ipwx]

根据我的经验，List<T> 的序列化最容易优化了。因为有哪些字段都是固定的。

很简单的方法：把 List<T> 变成 {"fields": [field names...], "items":[ [field1,field2,...], ... ] }

其中 fields 用来记录 T 有哪些字段，field1, field2 之类的是每个对象的对应字段。然后你就算转换成 JSON 进行传输都不会太慢，而且还跨语言。甚至你可以在 json 上加一层 snappy compression，说不定能达到 50% 的压缩率。