公司规模也不小,但是创建公司后一直都是使用 map 当对象,导致自研 RPC 框架也是基于 map 去传输,想转换为对象进行开发。 目前的想法是在调用 RPC 前把 Bean 转为 Map,返回结果再把 Bean 转化为 Map,但是这样如果传入或者返回的是 List,加一层转换的操作肯定会降低性能,数据量比较大的时候容易出问题,有没有什么比较好的建议或者方案可以解决呢
1
billlee 2021-09-08 22:40:15 +08:00
没理解 Bean 转 Map 和传入返回 List 有什么关系?
|
2
zwMuZhi OP @billlee 确实是我没描述清楚,这里是指 List<Map>这种结构,如果需要做转化,就需要遍历一遍 List,去 Map 中取值生成对象
|
3
billlee 2021-09-08 22:58:22 +08:00
我觉得可以先试试直接用 jackson 做 bean 和 map 之间的转化,可能性能没有你想象的那么差?
如果不行,再通过代码生成或 asm 的方式生成 bean 和 map 之间转化的方法,以避免反射开销。 如果还想进一步提升,可以分析 RPC 框架使用的序列化协议,绕过 map 直接实现从 bean 序列化成对应数据流的方法 |
4
luban 2021-09-08 23:15:51 +08:00
用 map 是为了方便修改 Bean 结构吗
|
5
potatowish 2021-09-08 23:52:39 +08:00 via iPhone
没有必要,你们这自研的 rpc 传输的数据结构就是基于 map 对象,又加一层 bean 的转换,没方便多少,性能也下降了,要么把框架升级了要么就不要折腾
|
6
ipwx 2021-09-09 00:42:34 +08:00
根据我的经验,List<T> 的序列化最容易优化了。因为有哪些字段都是固定的。
很简单的方法:把 List<T> 变成 {"fields": [field names...], "items":[ [field1,field2,...], ... ] } 其中 fields 用来记录 T 有哪些字段,field1, field2 之类的是每个对象的对应字段。然后你就算转换成 JSON 进行传输都不会太慢,而且还跨语言。甚至你可以在 json 上加一层 snappy compression,说不定能达到 50% 的压缩率。 |