兼容是被广泛讨论的问题,大量开发者也关注 ServiceComb 的兼容性如何。 写这篇文章的触发点是在 ServiceComb 中 回答了一个关于兼容的问题 。 在 这个问题中, 开发者为了隐藏系统内部的变化,需要在代码中额外增加特殊逻辑,以保障使用者不感知这个变化。 这个问题 反映了兼容问题的两面性:(1)保持兼容可以屏蔽使用者对于变化的感知,维持现有功能的稳定性,降低引入新版本的成本, 减少对现有系统功能的影响;(2)保持兼容需要在代码中增加复杂性,这些复杂性可能并不是实现现实业务逻辑必须的,继而 给现有系统功能的可靠性带来间接影响;从开发者的角度,做不兼容性重构通常是不得已而为之,或者由于现有接口设计不 合理影响扩展,或者存在某些未考虑的缺陷,不期望使用者继续使用。如果保持兼容,使用者不能感知到这个变化, 直到该功能在实际环境出现问题,增加了问题发现时间。
软件不可能一开始就被设计的完美,因此兼容性问题会一直存在。需要结合兼容性的场景和兼容性的影响,综合评估兼容策略, 使得既保持引入新版本的效率,又能够在每次升级新版本的时候,修复已知问题,让版本升级变得更有价值。
为了评估兼容性的影响,需要细化兼容性的场景和分类。
运行时兼容。考虑一压缩文件的程序 zip.exe
, 这个程序在老版本的 windows 里面可以正常运行,然后将这个 程序拷贝到新版本的 windows 里面,如果仍然可以执行,那么认为是运行时兼容;再考虑使用老版本 JDK 执行的 程序 hello.jar
, 使用新版本 JDK ,如果仍然可以执行,那么认为是运行时兼容的。 运行时兼容通常 适用于操作系统,运行容器等基础软件平台,或者实现标准协议的运行环境,如 JSP/Servlet 的实现 Tomcat。 在早些时候,这些基础软件平台的兼容性一直做的不错,随着技术发展越来越快,用户对于体验要求越来越高, 基础软件平台在保持兼容性的方面越来越放开,兼容版本越来越少。比如 windows 10 的版本并不兼容部分老的 执行程序,JDK 12 也不再兼容部分 jar 包,苹果的平台一直采取的是一种积极的向前看的策略,多数新版本 平台的推出,都要求应用使用新版本平台重新编译后在应用市场发布。
编译时兼容。编译时兼容是组件/模块类软件常见的兼容性类型,比如 ServiceComb, 通常作为运行程序的一部分, 通过编译工具,与业务代码一起编译为可执行的程序。 以 ServiceComb 为例,使用它的应用程序采用 maven 工具 进行编译,如果能够通过修改依赖的 pom 的版本号,编译通过,并且功能没有变化,那么就认为是编译时兼容。 编译可以认为是开发 过程的一部分,不兼容导致的编译失败,通常不会给最终用户带来影响,组件使用者通过修改编译不通过的模块,使用 新提供的 API,就能够编译通过。编译不兼容的修正会涉及接口的替换,如果新替换的接口与老接口功能不一致,而 开发者又没有针对这些变更的功能进行测试,则可能将问题遗漏到最终用户。 修正编译不兼容问题需要有替换的接口,如果 没有可替换的接口,那么开发者没法使用新版本,这个不会给最终用户带来影响,开发者需要联系组件提供者提供对应的 解决方案满足要求。组件的编译时兼容做的比较好的一般是一些算法类、协议类组件,比如 JDK 的数据结构库,jackson 的 JSON 解析库,越是面向应用层,编译不兼容的情况越是发生频繁,比如 spring cloud 相关的库。
服务接口兼容。 服务接口是应用服务化以后出现的概念,通常表示为应用对外提供的 REST 接口。 服务接口由于都是 在线使用,一旦接口变化,就可能对使用者的业务系统产生影响。服务接口的兼容性问题,使用者也无法通过离线编译 发现,所有的问题都是对用户产生影响后才被发现,因此服务接口的兼容显得尤其重要。
根据上面的兼容性场景,可以按照兼容性符合度,分为下面几类。
ServiceComb 存在多个不同的组件,对于中间件类服务,比如 servicecomb-service-center 的兼容性策略是 服务接口兼容。 对于开发 SDK 类,比如 servicecomb-java-chassis 的兼容性策略是恰当的编译时兼容
。
相对于实际情况,上面的策略描述仍然比较简单,因为实际情况比设想的情况要复杂的多。本文关于兼容性场景的描述, 并不能概况所有的兼容性场景,比如对于 SDK 类,也可能存在运行时兼容的要求,特别是有些业务系统是基于老的构建 工具,比如 ANT 的情况,业务可能需要替换 jar 的方式满足兼容性要求。 SDK 类也存在服务接口兼容的要求,比如 通过 SDK 的 HIGHWAY
发布接口,如果 HIGHWAY
底层的通信协议或者编解码方式发生变化,则可能导致服务 接口不兼容。
为了对各种复杂的兼容性场景进行有效管理,java-chassis 使用 3 位版本号(major.minor.patch)适当区分:
wong
重命名 为 wrong
。2.0.0
版本的 HIGHWAY
协议的修改。 因为运行时兼容出现的时候,只要使用了该功能的所有微服务都需要一并升级,工作量从单个服务提升 到整个应用,视应用的规模大小,工作量会差别很大。当然并不意味着 major 版本升级一定非常复杂,实际上没有 使用 HIGHWAY
的情况,2.0.0 升级的工作量仍然不超过一般的 minor 版本。针对 major 版本, ServiceComb 会提供相关的升级指导,帮助开发者评估兼容性影响。java-chassis 自身也使用了大量的三方件,为了更好的平衡升级效率和项目的持续高质量发展,下面总结了一些 兼容性管理的优秀实践以及对于开发者的建议:
Handler
和 Invocation
核心模型,以及不同的模块提供的配置项等。RegistryUtils
的接口。 不用担心这些 API 变化而不敢使用, 先针对使用这些 API 的场景或者直接针对这个 API 写一些自动化测试用例。升级版本的时候,这些 API 的 原型变化甚至语义变化,都能够及时被发现。