在大多数情况下，我们使用的部署策略会导致当前版本被新版本替换。旧版本将停止，而新版本将在其所在位置部署。这样一组操作会导致停机。在很短的时间内（希望如此），两个版本都没有运行。因此，在一毫秒、一秒、一分钟甚至更长的时间内，我们的服务无法访问。在今天的市场上，这样的策略是不可接受的。如果我们的软件不能运行，我们的用户会去别的地方。即使没有，停机也会产生其他各种不良影响。金钱损失，支持团队的电话不堪重负，声誉受损，等等。我们预计将是uo，全天候运行。这就是过去迭代时间长的部分原因。如果新版本的部署会导致停机，最好不要经常这样做。然而，今天我们不能不经常做发布软件。我们的用户期望不断改进。即使他们没有，我们也会。短迭代证明了它在各个层次上的价值。今天，我们看到了对"短"的含义的不断重新定义。不久前，short意味着几个月或几周，而今天它意味着一天多次。最终目标是什么？部署到生产中的每个提交。如果部署产生停机时间，那么前一句话可以翻译为"每次提交造成停机"。我们不想那样。那么，我们如何避免部署停机？或者，换句话说，我们如何实现零停机部署？随着时间的推移，有两种方法被证明是实现零停机部署的最可靠方法：蓝绿和滚动更新。在其本质是，蓝绿部署背后的思想是，在任何给定的时刻至少有一个版本在运行。过程是跟着。我们部署第一个版本（我们称之为蓝色）并配置代理以将所有请求重定向到它。当时机成熟时，我们将与前一个版本（蓝色）并行部署第二个版本（我们称之为绿色）。此时，代理仍在将所有请求重定向到蓝色版本。一旦我们新部署的服务开始运行，我们就可以继续进行自动化测试（生产中）或任何其他类型的部署验证。当我们确信新版本不仅在运行，而且也如预期的那样工作时，我们可以重新配置代理以将所有请求重定向到它。只有当这个过程完成，并且所有先前启动的请求都收到了响应，我们才能停止旧的（蓝色）发布。在每一个新版本中，相同的过程会被反复重复。第三个版本是蓝色的，第四个版本是绿色的，等等开。那个滚动更新背后的想法是逐步升级版本，一个或几个实例在时间。让假设我们有五个服务实例在生产环境中运行。在部署新版本时，我们将替换以前版本的一个实例，大数据视频，并在一段时间内监视结果。因此，我们将有一个新版本的实例和四个旧版本的实例。稍后，如果没有检测到异常，我们将重复这个过程，最终有两个实例运行新版本，三个实例运行旧版本。我们将继续使用相同的过程，企业应用管理，直到所有实例都运行新版本。如果检测到异常（不希望的行为），运行新版本的实例将停止，大数据是什么意思，旧版本将被滚动回来。那个需要注意的是，这两个过程都假定新版本至少与前一个版本兼容。这在api中最为明显。由于这两种方法都假定两个版本将同时运行，因此我们无法保证用户将访问哪个版本。数据库也是如此。模式更改需要以一种方式进行，即它们不仅要处理新的，物联网平台，而且要处理当前的释放。不需要换句话说，当体系结构面向微服务时，这些过程最容易实现。这并不意味着蓝绿部署和滚动更新不能与其他类型的体系结构一起工作。是的。主要区别在于服务越小，处理速度越快。而且，较小的服务需要更少的资源。这尤其适用于蓝绿色部署的情况，即在短时间内重复资源使用方法我们可以先测试一下绿色部署的优势。另一方面，如果一个服务被扩展到大量的实例，并且并行运行两个版本会带来太多的需求，数据分析工具有哪些，那么滚动更新可能更合适资源。现在不会因为部署过程而导致停机，为实现连续性而敞开大门部署如果你喜欢这篇文章，您可能对devops2.0toolkit感兴趣：使用容器化微服务自动化连续部署管道书。那个这本书讲述的是不同的技术，这些技术帮助我们以更好、更有效的方式构建软件，将微服务打包成不可变的容器，经过测试并持续部署到自动配置配置管理工具。它是关于快速、可靠和连续的部署，无停机时间和回滚能力。它涉及到可扩展到任意数量的服务器，设计能够从硬件和软件故障中恢复的自愈系统，以及集中记录和监视群集。输入换句话说，这本书包含了使用一些最新和最好的实践和工具的完整的微服务开发和部署生命周期。我们将使用Docker、Ansible、Ubuntu、Docker Swarm和Docker Compose、Consul、etcd、registor、confd、Jenkins、nginx等等。我们会经历很多练习，甚至更多，工具这本书可以从亚马逊上买到(亚马逊网站以及其他全球网站）和LeanPub。