服务交付方案_先进的连续交付方案

服务交付方案

我们都听说过“ 持续交付”这个术语。 我们通常会发现它与诸如DevOps和不可变基础架构之类的术语结合在一起。

连续交付的简单示例并不难，但是在尝试将这些技术应用于复杂的实际应用程序时，您可能会发现自己比答案更多的问题。

在本文中，我们将介绍一些用于连续交付的高级用例，以及一些使之平稳运行的最佳实践。

定义连续交付

在开始探索高级连续交付方案之前，我们应该首先花时间定义连续交付并建立一些最佳实践。

一口气从零交付到连续交付非常困难。 采用分阶段的方法更容易，更有效。 这些阶段是：

• 部署方式
• 自动部署
• 持续交付

让我们看看这些阶段中的每个阶段。

阶段1：部署

第一步涉及定义系统部署的外观。 需要构建和部署哪些组件？ 你有数据库吗？ API服务器？ 前端网？ 您是否正在部署后端和移动应用程序？

您必须首先定义可部署的工件。 这些是部署需要构建或组装的软件包。 定义工件后，您可以设置构建服务器和构建过程以根据需要创建工件。

阶段2：自动部署

既然您已经定义了构建工件并设置了一个构建服务器来创建它们，那么该开始对部署的各个部分进行自动化了。 不要想太多这一步； 它可以像编写bash脚本一样简单，以捕获工件并将其移至目标环境。

在构建脚本和工具来为您处理部署时，您将需要看一下对这些脚本进行标记化，以便它们可以接受构建工件的版本和将要部署到的环境的参数。 这将有助于创建可以连续部署的过程。

将这些脚本与正在部署的代码一起保留在源代码管理中也是一个好主意。 这允许脚本与代码同步自然地版本化，以便它们随时间一起发展。 这一点很重要，因为如果您需要部署系统的较旧版本，则部署脚本仍将与设计要部署的系统状态相匹配。

阶段3：持续交付

现在，您已经自动化了部署步骤，是时候在没有直接干预的情况下实现这一目标了。 连续交付系统由触发器组成，这些触发器将基于开发和测试过程中发生的事件启动构建和部署过程。

首先定义何时应进行构建。 在每次签入master分支时？ 也许每个功能分支都可以签到？ 接下来，定义触发器以自动部署工件。 选择符合您的部署业务目标的触发器。 您可能希望将每个签入功能分支部署到演示环境，以便在sprint结束会议上进行展示。

当在master分支上发生构建时，您可能需要将其部署到登台区域进行测试，然后再将其发送到生产环境。 由于我们标记了部署脚本，因此我们可以轻松地建立一个系统，当功能分支上签入时将其部署到测试和演示环境，并将构建从主分支发送到生产环境。

最佳实践：语义版本控制

我们倾向于认为版本控制仅对发布供外部使用的系统（例如Twitter的公共API）非常重要。 但是，内部系统的版本控制对于成功的连续交付系统至关重要。

通过遵循语义版本控制系统 ，我们可以自动决定可以一起部署组件的哪个版本。 例如，在构建和部署微服务体系结构时，每个微服务都应履行与系统其余部分的合同。 如果服务引入了重大更改，我们可以阻止其部署，直到依赖于该服务的系统已更新。

连续交付方案

版本控制在系统其他部分使用的内部库和API中特别有用。 维护正确的语义版本使我们能够设置高级连续交付方案，例如下面概述的零停机时间部署策略和稳定架构部署策略。

零停机时间部署策略

在这种情况下，我们将研究如何在不停机的情况下实现分阶段部署我们的部署。 此方案基于以下n层体系结构：

用于零停机时间部署的n层体系结构。

在这种体系结构中，我们有一个Web应用程序，该服务器由负载平衡器后面的六个Web服务器场在www.myapp.com提供。 负载平衡器配置为粘性会话，以便来自给定客户端的请求将继续发送到同一Web服务器（只要可用）。 Web服务器通过循环DNS条目向API服务器发出请求，该DNS条目包含位于1–2–1.api.myapp.com上的应用程序版本（v 1.2.1）。

当我们准备部署应用程序的1.3.0版本时，我们将从1–2–1.api.myapp.com的循环DNS条目中提取API服务器1–2–1.api.myapp.com ，并将它们移至位于以下位置的新条目1–3–0.api.myapp.com 。 这将使我们的系统处于如下所示的状态：

我们的一半API服务器已删除，并准备升级到1.3.0版。

如您所见，所有Web服务器仍在向我们的API v1.2.1发送请求，因此用户可以继续使用我们的应用程序。 现在，我们可以将API服务器6–9升级到v1.3.0。

完成此操作后，我们需要部署前端应用程序的v1.3.0与新的API服务器通信。 我们将耗尽来自Web服务器4–6的连接，以便所有前端流量都将被定向到Web服务器1–3。 现在，我们可以部署前端应用程序的1–3–0.api.myapp.com该应用程序被配置为使用1–3–0.api.myapp.com URL进行API调用。 这将使我们的系统处于以下状态：

我们一半的Web和API服务器现在正在运行应用程序的v1.3.0。

现在，我们有一堆完整的服务器，可以为我们的应用程序v1.3.0提供服务。

在这一点上，明智的做法是在连续交付管道中内置一些自动烟雾测试，以测试运行v1.3.0的服务器并确保它们已准备好为公共流量服务。 如果一切顺利，我们可以将这些服务器重新带入负载平衡器，以使部分用户开始使用该应用程序的新版本。 现在我们的系统将处于以下状态：

现在，我们一半的基础架构正在为我们的应用程序v1.3.0提供服务。

请记住，我们的负载均衡器是为粘性会话配置的，因此连接到v1.2.1 Web服务器的用户将继续获得该应用程序的版本，而其他用户将连接至v1.3.0服务器。

您不必一次用一半的基础架构来完成此操作。 您可能希望做较小的部分，例如10％。 这使您可以暂停发布，并查看应用程序对系统中实际用户的表现。 如果一切顺利，您可以继续应用此策略，直到整个基础架构都部署了新的v1.3.0应用程序。

稳定的架构部署策略

版本控制对持续交付真正有帮助的另一个领域是跨部署管理数据库架构。

虽然应用程序部署通常是不可变的，但是数据库中却包含一些有价值的东西：所有数据。 这意味着对模式进行更改需要做更多的计划，并制定适当的策略来处理模式更改。

假设我们已经构建了应用程序的v1.0.0，并且我们决定要跟踪用户最喜欢的每种颜色是什么。 我们创建一个架构和API来支持这一点，如下所示：

我们的一半API服务器已删除，并准备升级到1.3.0版。

大！ 现在，我们正在跟踪用户最喜欢的颜色。 但是随后，我们的初创公司开始以具有更好的网络效果的方式来破坏一个新空间，因此，我们不再关心跟踪用户喜欢的颜色。

因此，对于最新的热门应用程序/users/{id}/fav_color ，我们删除了/users/{id}/fav_color终结点，并且希望从表中删除该字段。 但是还记得我们的零停机时间部署策略吗？ 我们将同时运行v1.0.0和v2.0.0的应用程序。 因此，我们不想只删除该列。 因此，我们为v2.0.0部署了一个如下所示的架构：

我们删除了fav_color的api端点，但未删除表列。

现在，我们可以愉快地为应用程序的v1.0.0和v2.0.0提供服务。 一旦我们完全部署了v2.o.0并完全淘汰了v1.0.0，就可以在以后的更新中自由删除不需要的列，如下所示：

在v2.1.0中，我们从表中删除未使用的列。

该原理不只是简单地删除列。 例如，如果我们需要更改列的数据类型，则可能需要添加一个新列，该新列在部署时从现有列复制数据，并针对新列编写新代码。 然后，一旦我们完全部署了新代码，就可以随意删除旧列。

这显然是过分简化，但是它说明了在应用程序的整个生命周期中发展数据库架构时，进行一些预先计划和正确应用版本控制会如何行之有效。

结论

在本文中，我们定义了计划连续交付系统所需的内容。 我们还探索了一些最佳实践，以确保我们的系统成功。

在考虑规划应用程序的连续交付管道时，请记住对您的过程进行迭代，并确保在此过程中应用良好的语义版本控制。

翻译自: https://www.javacodegeeks.com/2015/11/advanced-continuous-delivery-scenarios.html

服务交付方案