升级那点事情-升级接口包所引起的一些问题

最新推荐文章于 2021-12-03 19:12:53 发布

bxyz1203

最新推荐文章于 2021-12-03 19:12:53 发布

阅读量3.8k

点赞数 5

分类专栏： java 文章标签：消息中间件 server jboss json java mina

本文链接：https://blog.youkuaiyun.com/bxyz1203/article/details/6919859

版权

java 专栏收录该内容

20 篇文章

订阅专栏

本文讲述了在升级接口包时遇到的各种问题，包括DTO兼容性、序列化反序列化、消息协商不一致、方法重载、线上的消息被线下消费等，并给出了相应的解决方案。重点关注类加载冲突、接口版本管理以及公共部分升级的向下兼容性问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、概述

笔者本文会讲述升级接口包所引起的一些问题。这些问题都在真实的项目遇到到。有的在线上已经出现重大的故障。这些问题被大部分同学在开发的时候忽视了。掌握这些要点，将使你在以后的开发中避免类似的问题。

二、背景知识（MOM\RPC）

我们知道，在互联网中，可靠情况下，进程(线程)需要通信基本基于TCP/IP连接。连接连上需要三次握手，断开需要四次握手。应用层通信基本就有了RPC连接与MOM消息中间件。在java中，慢慢发展出来了：JMS、MDB、RMI、EJB等通信技术。

RPC技术的基本模型是：我们知道RPC有的时候会带一个注册中心，一般是管理服务器的。他是一个中心，一般也不会成为瓶颈。RPC就是client调用server端。其实我们很多应用都是基于这个。如：传统的浏览器，大多数的CS程序（IM等）一般开源的软件有：Hessian、Mina、Netty等。一般要求有接口，与接口参数DTO。这些都需要定义在接口包中，因为要两边共享。这些一般定义在二方包中。

MOM，消息中间件。一般也是基于RPC的，不过从client到server中间有一个消息中间件。消息中间件接受client传输的消息，把消息存储下来，再把消息给server。也就是说如果server消费失败，那么消息就会持久化在消息中间件中。这个就是MOM的核心，存储转发模式。一般要求有队列，message有效负荷的约定（一般可以是json字符串，也可以二方包中的DTO。建议用 JSON字符串。）

三、升级接口包遇到的问题（此些问题笔者与同事都有遇到过，有的还在线上出现过故障）

DTO或者参数有兼容性问题
- 序列化反序列化的问题：序列化最主要的问题是一方序列化的流到另一方不能正确反序列化，可以参考笔者另外一遍文章：序列化
- MESSAGE协商不一致：如果采取是 JSON形式（有点相当于自定义的格式），那么解析的时候，就要注意字段的位置关系。要确保向下兼容等。
同时发布，新老接口不一致。我们一般建议保留老的接口，待到没有用的时候，再把老的接口移除下来。
方法重载的问题。我们建议接口最好不要重载方法。因为RPC调用接口的时候，都是用反射的机制的，有的可能没有做到方法参数这个层面。只是简单地用方法名称来查找服务。有的RPC框架就禁止方法重载。
线上的消息被线下的消费。因为是队列模式，经常出现线上的消息被线下的服务消费。这个最好是运维部同事做好访问限制。不要让线上的消息路由到线下，避免出现悲剧。
类名重复，容器加载的问题。导致方法调用失败。
- 这个是一个老的问题。在应用中经常出现。一般是由于类的全路径相同，DEV想用A类，jboss或者tomcat初始化了B类。B类没有这个方法出错，如果有，那么还真的悲剧了。所以我们最好要保证，不要写全路径相同的两个类。最容易出现这种情况就是改包名称。例如：google.guava被改成了google.google-collections。如下图所示，在APP中，一包间接引用了一个google的集合包。正好APP用了一个方法 A.f()在google.google-collections有，在guava没有。但是A类两者都有。不巧地是：传统类加载与jboss的类加载不一致。所以悲剧了。
- 接口包有多个版本，两个版本肯定有些差异，如果打包脚本打入接口包的两个版本，那么也可能悲剧了。原因与上面的情况差不多。
公用的部分升级(加密签名等)，版本不向下兼容又没有通知相关系统升级。例如
- 从上图看出A系统用的接口包是1.2，网站是用1.2正常通信。计费中心用了1.1，出了问题。原因就是1.2升级的时候没有向下兼容。解决地办法：要看有多少系统用了这个接口包。如果是许多的系统，那么做好做一个路由，A系统提供多版本服务，再逐渐升级到1.2版本。如果是少量，最好是通知相关系统统一升级。