背景：一场典型的依赖冲突

最近业务方在生产环境中遇到了一个典型的多方依赖冲突问题：

  • 业务服务同时依赖中台的多个API包（platform-a-api、platform-b-api、platform-c-api）
  • 这些API包又共同依赖platform-component作为基础组件
  • 业务方只升级了platform-c-api，其他API包保持旧版本
  • 由于platform-component版本不一致，导致类缺失和依赖冲突

最终解决方案是业务方将三个API包全部升级到最新版本。这个看似简单的版本冲突问题，实际上反映出了中台在与业务方协作中的深层次问题。

中台视角：对兼容性的理解与挑战

作为中台团队，在日常开发中确实投入了精力保证高版本对低版本的兼容性，但在实践中发现几个关键问题：

  1. 隐式的版本要求：即使中台API表面兼容旧版，但可能依赖的底层组件版本有隐式要求

  2. 跨API包的版本关联：当多个API包共同依赖同一个基础组件时，版本一致性成为必须

  3. 升级通知机制缺失：缺乏系统化的渠道通知业务方必要的版本升级

值得反思的是，中台可能过于专注技术实现，而忽视了依赖关系的显式表达和升级策略的明确沟通。

业务方视角：版本管理的懒惰与技术债积累

从业务方的角度来看，这种问题也反映了：

  1. 被动版本管理：业务方往往等到出现问题才考虑升级，而非有意识地定期评估依赖版本

  2. 依赖透明度不足：对复杂的传递依赖关系缺乏全面了解

  3. “能用就不动”的心态：只要系统正常运行就不想冒险升级，导致技术债积累

业务方需要认识到，在现代微服务架构中，依赖管理已成为开发者的核心职责之一。

根本解决方案探讨

引入BOM

确实，BOM文件能解决版本一致性问题，但解决不了自动升级问题。但是BOM的价值不容忽视：

1
2
3
4
5
6
7
8
9
10
11
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.company.platform</groupId>
            <artifactId>platform-bom</artifactId>
            <version>2.0.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

BOM确实不能完全消除升级的需要，但它能够：

  1. 统一所有关联组件的版本
  2. 提供清晰的依赖矩阵
  3. 减少版本冲突的可能性

自动化依赖检查

可以考虑集成工具链来实现部分自动化：

  1. Maven Versions插件：定期检查依赖更新

    1
    mvn versions:display-dependency-updates

  2. Dependabot/GitHub依赖机器人：自动创建Pull Request更新依赖

  3. CI/CD流水线中的依赖检查：在CI阶段加入依赖健康检查

组织流程改进

技术方案需要配合流程改进：

  1. 中台发布通知机制：通过邮件、内部Wiki通知必要的升级

  2. 季度性依赖审查：业务方定期(如每季度)审查和升级依赖

  3. 跨团队依赖治理会议：定期讨论跨团队的依赖关系

结论：共同治理是答案

从根本上解决这类问题，需要中台和业务方共同承担责任：

  • 中台应：

    • 提供清晰的依赖管理方案
    • 建立及时的升级通知机制
    • 维护严格的语义化版本控制

  • 业务方应：

    • 积极参与依赖治理
    • 建立定期升级机制
    • 理解依赖关系的重要性

依赖管理不是一次性任务，而是需要持续关注的工程实践。只有双方共同努力，才能构建健康的软件生态系统。

通过这次事件，深刻认识到：健康的依赖关系不是偶然发生的，而是通过明确规范、持续维护和跨团队协作精心设计出来的。中台与业务方的关系，本质上是一种需要共同维护的”技术契约”。