API 版本管理成本

阅读数:1359 2013 年 12 月 4 日

话题:REST语言 & 开发架构

对于基于 SOA 的系统而言,契约版本管理和 API/ 服务版本管理一直是一个必须考虑的因素。不管是因为它对可组合性的影响,还是因为客户端服务治理,它都仍然是一门艺术而非一门科学。团队分享版本管理经验的例子有许多(例如,围绕 REST的版本管理就非常热门)。不过,Jean-Jacques Dubray 最近写了一篇文章,试图将一定的科学客观性注入到这一问题域:

最近,有人要求我为 API(或者 Web 服务)版本管理成本建立一种估算方法。我想分享这一估算,因为我觉得许多人还不清楚 API/ 服务版本管理对成本的影响。

据 JJ 说,他们在工作过程中发现,创建 API 的成本取决于随后使用的版本管理方法:

[开发人员需要] 了解的一个关键点是,即使服务消费者的成本在他看来很小,它也不只是单纯的成本问题,它是风险,它扰乱项目计划,并使预算不可用……由于变更常常不能为现有消费者带来直接的商业价值,所以他们不希望 API 有任何变更。

文章接下来将 API 版本管理方法分成三个不同的类别(读者可以查看全文来了解针对每一个类别的更深入讨论,包括 JJ 如何定义成本测量方法):

  • “结(The Knot)”:“所有 API 消费者都连接到 API 的同一个版本,当 API 变化时,所有消费者都需要跟着变,实际上,这产生了一个横跨整个消费者集合 / 生态系统的巨大连锁反应。”

  • 点对点:“服务的每个版本都留在生产环境中运行,当需要某个版本时,消费者需要自己进行迁移。运维成本会随着生产环境中版本数量的增加而增加。”

  • 兼容性版本管理:“所有客户端都与 API/ 服务的同一兼容性版本进行对话。”

  • 有了这些定义和使用 JJ 所描述的公式计算出的相关成本,就可绘制相对成本图,如下所示(y 轴是成本,x 轴是版本数量):

正如 JJ 所言:

[……] 当 API 发生变化时,单一版本会迫使每个消费者都进行升级,对于生态系统而言,这是一种成本最高的方法。第二种方法需要维护版本的多样性,这样会好一些,但如果开发人员试图保持每个版本的升级或者交替运行旧版本,那么成本还是相当高。兼容性版本管理策略似乎最高效。

那么,其他人有什么想法?这一 API 版本管理成本计算方法在 JJ 和其团队研发该方法的环境之外是否适用?结合读者的个人经验,相对成本的解释是否合理?还有其它 JJ 和其团队没有涉及到的类别吗?

查看英文原文:The Costs of Versioning an API