API版本管理成本

对于基于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