“微服务架构”使用Canary版本来简化API版本控制

API提供者可能面临的最大困难之一是如何管理版本和从实例到实例的构建。迭代的持续需求与组织的持续需求相匹配，使得版本控制成为现代API开发中一个有争议且经常被讨论的方面。但是，对于传统的版本控制，有一些替代方法可以带来一些主要的好处。

今天，我们将讨论其中一个解决方案——canary release。Canary已经迅速成为透明API开发的一个巨大组件，对于开放银行来说，它可能是现代金融机构在不破坏基础互操作性的情况下实现透明、有效的版本控制的最佳工具之一。

为什么API版本控制和金丝雀的发布如此重要?

有时，API提供者和API使用者之间可能存在某种紧张关系。API提供者可能希望在他们有新的、更好的想法时改变API。这些想法很有前途，展示了API的新特性、新方法和可能的新方向。

然而，API使用者通常只想要一些稳定的东西。除非使用者对这个新的、很棒的想法感兴趣，否则他们希望API能够以可预见的方式运行。

这就产生了一个明显的问题，这也是版本控制对许多用户来说如此困难的主要原因。不过，对于版本控制最好的争论来自于REST设计之父Roy Fielding。他对实现版本控制的看法是什么?“不要。”

版本是什么?

具体来说,为什么?为什么我们不应该理所当然地进行版本控制呢?让我们看看版本化api的影响。

版本控制是指在向服务添加特性时，从根本上创建现有对象的新版本。这些版本是截然不同的，并且通常具有完全独立的功能，具有不同的目的，因此，被视为完全独立的开发。

在传统的版本化开发中，这些新版本将被标记为用于测试的beta版本，以及用于全面改进的里程碑版本。一旦进行了测试，通常以一种可选择的方式，这些beta版本将慢慢地转向候选版本，然后是实际版本。

这种类型的版本控制有一些主要的好处，主要的好处是在形式和功能上的主要改进得到了明确的划分。这种划分的能力非常重要，特别是在使用不同的硬件版本时，但最终，这本身就是版本化方法的失败之处。许多用户都知道，当他们尝试使用一个设备时，却发现其固件、软件或其他元素不兼容，需要更新。因此，他们不使用该系统，并在以后返回时发现情况更糟。

这最终导致用户群中大量的更新和未更新的划分，并且把太多的重要性放在单个实例上而不是整体系统本身。

什么是金丝雀发布?

金丝雀释放是一种试图减轻许多负面影响的技术。Canary版本通常被定位为版本控制的替代品，就像lite版本控制一样。

在canary版本中，引入新软件的风险是通过先慢慢地将这些变化推广给一小部分用户来减轻的，而不是像经典版本控制中那样通过选择加入和后来的强制发布来推广它们。这些小的用户子集通过动态负载平衡测试新版本，一旦版本控制被验证为符合预期的功能，新版本就成为默认版本。

我们称之为金丝雀释放，因为它的功能类似于井筒中的金丝雀。金丝雀曾经被矿工用来测试矿井里的空气。如果空气有毒，金丝雀就会死掉，这就向矿工发出他们必须立即离开的信号。同样地，如果正在缓慢测试的API实例是坏的，那么检测它的原因将是小子集中的故障，而不是对一般用户的大规模故障。

应用程序正在调用一个绑定到API的服务实例——随着这些请求逐渐暴露给新版本，特定的应用程序、硬件、方法等可以根据新版本动态地进行粒度测试。最终，如果一切顺利，所有内容都将转到新版本，旧版本将被弃用，用户也不会知道。

这里的一个巨大好处是，回滚很容易——最终，您只需停止向新的canary实例发送请求，而只需将其发送到旧的canary实例。

荷兰国际集团(ING)版本

一旦您看到了它的实际应用，这种方法就更容易理解。Patrice Krakow在2017北欧api平台峰会上做了关于canary发布的演讲，他提供了下面的工作流程作为ING银行如何处理canary发布的例子。

构建系统

在ING系统中，大部分API交互是由API网关驱动的。他们认为他们的网络分为两层——外部网络和内部网络，第三层内部网络代表办公室网络。Patrice注意到，API网关功能在外部边界和内部边界上，但他指出，并没有真正的“内部网关”，正如设计所暗示的那样。

就其API而言，包括负载平衡和逻辑寻址在内的一切都主要通过API服务发现来处理。当创建一个服务的实例时，该服务将作为一个实例、一组端点和一个地址通过路由器交付给API服务器发现。现在，我们必须绕一小段路来讨论一下路由器。在ING，它们不把路由器作为外部组件来处理，而是作为客户端的一部分来处理——通过这种方式，客户端代码处理自己的负载平衡。

在ING系统中，服务和端点是两个独立的东西，但是它们被称为manifest的东西链接和控制。这个清单本质上是服务和API端点列表之间定义良好的显式链接，并作为实例本身如何工作的一种指导。

当一个软件包想要调用一个API端点时，它首先声明它的意图。在ING中，这被称为订阅，它的作用是作为软件包(也称为应用程序)和特定API端点之间的关系。当在内部生成对等令牌时，API规范的版本将从创建此订阅时开始存储，并将实例版本作为更大的canary系统的一部分。

利用该系统

有了所有这些组成部分，ING最终通过它的路由器实现金丝雀释放。流程从API和端点开始，这些API和端点在一个Swagger文件中声明，该文件存在于API注册表中。服务被附加到API端点，然后清单被添加到具有特定规范版本的服务中。当启动一个服务的实例时，它会向API服务发现模块提供其物理地址，以及其所有端点的清单。

摘自帕特里斯·克拉科夫的演讲 幻灯片。

当应用程序想要调用一个端点时，它订阅一个可以调用的端点列表以及它想要与之对话的特定版本。路由器，不管是在代码内部还是在代码外部，然后传递注册对等令牌和信息，并使用端点的物理地址调用API服务发现。如果特定的API规范版本匹配，则可以将代码定向到基础实例或与该版本兼容的向后兼容版本。

通过这种方式，系统可以开始卸载到向后兼容旧实例的新实例，并且一旦测试了整个子集，就可以动态地增加用户基数。最后，当100%的用户基被透明地迁移后，旧的实例id就会被弃用，而新实例将成为清单中的默认实例。

结论:许多行业都能从金丝雀发布中受益

最终，API提供者选择合并canary版本还是坚持传统的版本控制完全取决于API开发人员自身的具体用例。虽然canary的发布确实使版本控制变得更加容易，但如果API每隔几年就只有一个或两个主要版本，那么它有时可能会付出更多的努力。但是，如果一个API不断地移动、不断地迭代，canary release可能是管理这种移动的最强大、最有效的方法之一。

这一概念在各种行业中都有许多应用。我们可以只看一个来看看这个潜在的概念是多么强大。例如，开放银行业运动正在鼓励金融机构远离旧的标准方法。因此，释放金丝雀的想法不仅是一种技术手段——它是一种新的风气，为银行在金融交易和架构构造方面的功能提供了范式转变。

虽然这是一个非常具体的应用程序，但canary版本控制的使用适用于各种函数和目的。由于这个原因，它仍然吸引着许多开发人员。你觉得放金丝雀怎么样?你认为它比它的价值更复杂，还是你认为它像一些人声称的那样是一个有前途的解决方案?请在下面的评论中告诉我们。

本文：http://jiagoushi.pro/node/1209

谢谢大家关注，转发，点赞和在看。