我要說的是我們改變 num屬性 的類型,無論是由 Integer改成Long,還是由Long改成Integer,只要num的值在Integer取值範圍內,就不會影響hessian序列化。 ...
先看如下Hessian2序列化的測試代碼。
import com.alibaba.com.caucho.hessian.io.Hessian2Input; import com.alibaba.com.caucho.hessian.io.Hessian2Output; import com.alibaba.com.caucho.hessian.io.SerializerFactory; import dubbodemo.dto.MyDto; import org.junit.Test; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.util.Base64; public class TestMain { @Test public void test() throws IOException { MyDto MyDto = new MyDto(); MyDto.setNum(1); byte[] bytes = serialize(MyDto); /** * 通過{@link Base64#getEncoder()}把byte數組序列化成base64串。相應地,利用{@link Base64#getDecoder()}進行字元串的反序列化 */ String base64String = Base64.getEncoder().encodeToString(bytes); //new String(serialize, Charsets.UTF_8); System.out.println("base64串=" + base64String); MyDto myDto2 = (MyDto) deSerialize(bytes); System.out.println(myDto2.getNum()); } @Test public void test2() throws IOException { String s = "QxRkdWJib2RlbW8uZHRvLk15RHRvMZMHaW50ZWdlcgRuYW1lAmlkYOFOTg=="; byte[] bytes = Base64.getDecoder().decode(s); //s.getBytes(Charsets.UTF_8); MyDto myDto2 = (MyDto) deSerialize(bytes); System.out.println(myDto2.getNum()); } public static byte[] serialize(Object obj) throws IOException { ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(); Hessian2Output hessian2Output = new Hessian2Output(byteArrayOutputStream); try { hessian2Output.setSerializerFactory(new SerializerFactory()); hessian2Output.writeObject(obj); } finally { byteArrayOutputStream.close(); hessian2Output.close(); } return byteArrayOutputStream.toByteArray(); } public static Object deSerialize(byte[] bytes) throws IOException { ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(bytes); Hessian2Input hessianInput = new Hessian2Input(byteArrayInputStream); try { hessianInput.setSerializerFactory(new SerializerFactory()); return hessianInput.readObject(); } finally { byteArrayInputStream.close(); hessianInput.close(); } } } @Data @Accessors(chain = true) public class MyDto implements Serializable { private String id; private String name; private Integer num; }
我要說什麼呢?
我要說的是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消費者的調用呢?經自測驗證,這個是行不通的!
當看到一些不好的代碼時,會發現我還算優秀;當看到優秀的代碼時,也才意識到持續學習的重要!--buguge
本文來自博客園,轉載請註明原文鏈接:https://www.cnblogs.com/buguge/p/16988123.html