hessian序列化优缺点（Hessian2序列化支持这一点，让重构dubbo接口更容易了）
先看如下Hessian2序列化的测试代码 。
我要说什么呢？
我要说的是MyDto的num属性 。当num是Integer时 ，我们得到hessian2序列化结果 ，然后 ，修改num为Long ，前面的序列化结果可以正常反序列化 。反之 ，num先是Long ，然后修改成Integer ，亦能正常反序列化 。这一点对我们的工作有什么帮助呢？
我们的系统中 ，服务商的主属性--服务商id ，在不同子系统里 ，这个id字段的类型不统一 ，varchar/int/bigint ，这就致使程序里对应的这个服务商id属性 ，有的是String ，有的是Integer ，有的是Long ，这给我们的系统迭代（开发&运维）带来了许多麻烦 。系统不断升级迭代 ，服务越来越多 ，重构的工作量以及风险就加剧 ，产生系统熵增 。
这几天的北京 ，市民陆续“阳 ”起来 ，我们公司也不例外 ，2/3的伙伴们都居家养病了 。非常时期 ，一些开发需求就暂缓 。我已阳康 ，趁此机会 ，take action！决定动手重构一把 。
其中 ，中台通道系统的channel-provider里有一个dubbo服务LevyMerchantRelationService ，它依赖一个数据传输对象LevyMerchantRelationDTO ，LevyMerchantRelationDTO里的服务商id类型是Integer 。从dubbo控制台来观察 ，LevyMerchantRelationService的消费者有14个应用共8个java工程 。
那么 ，我们要变更LevyMerchantRelationDTO里的服务商id类型为Long ，这些工程的代码 ，涉及到这个属性的 ，都要跟着做调整 。大好的消息是 ，有了上面hessian2序列化的这个优势（dubbo RPC默认序列化方式是Hessian2） ，我们在上线的时候 ，就不用把14个消费者应用都同时上线 ，这将极大节省跨小组沟通和上线工作量 ，更重要的是 ，dubbo服务正常调用 ，丝毫不影响系统稳定 。
这一点 ，增强了我这次重构的自信！
那么 ，我立马想到 ，如果dubbo接口方法的参数列表里有Integer的服务商id ，是不是也能直接改成Long而不影响dubbo消费者的调用呢？经自测验证 ，这个是行不通的！
创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！