Skip to content

兼容问题和兼容性策略

兼容是被广泛讨论的问题,大量开发者也关注 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 接口。 服务接口由于都是 在线使用,一旦接口变化,就可能对使用者的业务系统产生影响。服务接口的兼容性问题,使用者也无法通过离线编译 发现,所有的问题都是对用户产生影响后才被发现,因此服务接口的兼容显得尤其重要。

根据上面的兼容性场景,可以按照兼容性符合度,分为下面几类。

  • 完美。完美运行时兼容代表老的应用程序,不需要重新编译就可以在新环境执行;完美编译时兼容代表使用新版本编译时 不会出现编译错误,并且运行时行为一致。
  • 恰当。恰当运行时兼容代表老的应用程序,使用新平台提供的编译/打包等工具重新编译修改,如果存在失败,根据相关的指引 修复重新发布,能够继续运行,在新平台运行的效果和老版本一致。恰当编译时兼容指存在编译失败,使用新版本的API替换 老的API编译通过后,应用程序的行为和老版本一致。恰当兼容和修改工作量有关系,比如老版本切换为新版本,如果工作量 能够控制在1人天, 可以认为是恰当兼容。
  • 不兼容。不兼容指修改工作量超过可接纳的限度,或者某个接口没有替换方案。

ServiceComb 的兼容性策略

ServiceComb 存在多个不同的组件,对于中间件类服务,比如 servicecomb-service-center 的兼容性策略是 服务接口兼容。 对于开发 SDK 类,比如 servicecomb-java-chassis 的兼容性策略是恰当的编译时兼容

相对于实际情况,上面的策略描述仍然比较简单,因为实际情况比设想的情况要复杂的多。本文关于兼容性场景的描述, 并不能概况所有的兼容性场景,比如对于 SDK 类,也可能存在运行时兼容的要求,特别是有些业务系统是基于老的构建 工具,比如 ANT 的情况,业务可能需要替换 jar 的方式满足兼容性要求。 SDK 类也存在服务接口兼容的要求,比如 通过 SDK 的 HIGHWAY 发布接口,如果 HIGHWAY 底层的通信协议或者编解码方式发生变化,则可能导致服务 接口不兼容。

为了对各种复杂的兼容性场景进行有效管理,java-chassis 使用 3 位版本号(major.minor.patch)适当区分:

  • patch: 恰当的编译时兼容版本。升级 patch 版本,通常工作量可以控制在1人天以内。patch 版本多数只需要 升级版本号,然后重新编译发布即可。 少量的版本可能存在影响极小的不兼容调整,比如将方法 wong 重命名 为 wrong
  • minor: 恰当的编译时兼容版本。相较于 patch 版本, minor 版本可能存在更多的新特性交付,项目结构存在 一定程度的重构,使用内部 API 的开发者可能需要解决较多的编译问题,使用新的 API 替换老的 API。minor 版本的升级工作量通常控制在3人天以内。
  • major:提供 major 版本,通常是由于某些特性可能导致运行时兼容问题。比如 2.0.0 版本的 HIGHWAY 协议的修改。 因为运行时兼容出现的时候,只要使用了该功能的所有微服务都需要一并升级,工作量从单个服务提升 到整个应用,视应用的规模大小,工作量会差别很大。当然并不意味着 major 版本升级一定非常复杂,实际上没有 使用 HIGHWAY 的情况,2.0.0 升级的工作量仍然不超过一般的 minor 版本。针对 major 版本, ServiceComb 会提供相关的升级指导,帮助开发者评估兼容性影响。

java-chassis 自身也使用了大量的三方件,为了更好的平衡升级效率和项目的持续高质量发展,下面总结了一些 兼容性管理的优秀实践以及对于开发者的建议:

  • 尽可能使用核心 API,减少重构对于产品兼容的影响。区分核心 API 是需要一些开发经验的,java-chassis 并 没有给出核心 API 的范围和独立文档说明。 一个简单的方式是阅读开发指南,开发指南里面提到的使用方法,就是 核心 API 的内容,比如定义服务接口的 JAX RS 标签或者Spring MVC标签, HandlerInvocation 核心模型,以及不同的模块提供的配置项等。
  • 使用非核心 API 的时候,适当增加自动化测试用例。由于业务的需要,使用非核心 API 不可避免,比如有些业务需要 使用服务中心的 API 更新服务状态,调用 RegistryUtils 的接口。 不用担心这些 API 变化而不敢使用, 先针对使用这些 API 的场景或者直接针对这个 API 写一些自动化测试用例。升级版本的时候,这些 API 的 原型变化甚至语义变化,都能够及时被发现。
  • 持续升级新版本是一把双刃剑,但总体来讲,收益远大于问题。如果业务系统需要不断的更新,建议就应该在每个产品 迭代中安排一个任务升级新版本。java-chassis 的每个版本迭代,都固定会安排升级三方件的任务。及时升级版本, 能够快速修复老版本存在的安全漏洞,解决老版本已知的可靠性、性能问题、发现的bug;还能够识别出一些错误的 废弃用法,及时调整为正确的用法,使用新的版本,更容易从社区获得对于新发现问题的帮助。持续升级是一个系统 的工程实践,不单单指升级版本,还包括为了预防升级版本给质量带来风险而采取的其他措施,比如自动化测试的持续 构建,持续集成流水线的构建,定期阅读重要项目的 Release Notes,关注项目发展方向等等。 这种方式是一种主动 质量加固措施,可以免于问题发生。可惜多数决策者看到的是更新版本带来的问题,看不到预防措施的积极效果, 没有把持续升级作为一项重要的能力建设事项纳入计划,这项能力一直得不到提升,当实施升级的时候,更容易引入故障。