大家好，我是猿java。
作为一名 Java程序员，部署生产环境的服务器是一项基本能力要求，那么，如何部署才能做到业务无感？选择什么样的部署策略，才能将生产事故降到最低？今天我们就来一起聊聊五种常用的部署策略。
定义
Big Bang Deployment，中文翻译为：大爆炸部署，也就是我们通常说的全量部署。它是指在一个较短的时间内将新系统或新版本全部部署并替换旧系统，使其立即对所有用户生效。
原理
Big Bang Deployment的原理很简单，如下图，只需要把服务器全量部署，部署前为服务V1.0，服务部署后就全量变成了V2.0。
优点
- 快速部署：Big Bang Deployment可以在较短的时间内完成整个系统的部署，从而迅速推出新功能或更新。这种快速部署有助于满足紧迫的业务需求，让用户尽快获得新功能的好处。
- 突破点：将新系统一次性部署可以带来一个重大的突破点。一旦部署成功，所有用户都能立即使用新系统，从而为企业带来显著的商业价值和竞争优势。
- 零停机时间：由于所有用户都在同一时间切换到新系统，旧系统可以在部署后立即停用，从而减少了整个过程中的停机时间。
- 简化维护：在部署后，维护人员只需关注新系统的运行和维护，而无需再维护旧系统，这简化了维护流程和资源投入。
缺点
适用场景
只有一台服务器：有些使用量比较小的业务，为了成本，只需要部署一台服务器，因此，当需要部署新功能时，就可以采用该策略。
复杂的数据库升级：如果数据库需要进行复杂的业务升级，已经到了不得不使用全量部署策略。
总体而言，Big Bang Deployment是一种迅速推出新系统的方法，适用于紧急的业务需求，但风险较高。在实施前需要充分的计划、测试和备份策略，以减轻潜在的风险。对于一些重要业务功能，采用渐进式的部署策略可能更为保守和安全。
定义
Rolling Deployment，中文翻译为：滚动部署。与 Big Bang Deployment 相对，它指的是在部署新系统或新版本时，逐步将新版本部署到一部分用户或服务器上，然后再逐步扩大范围，直至所有用户或服务器都更新到新版本。
原理
如下图：在所有的服务器中，我们将 2台部署成新服务V2.0，当用户的请求到达新服务上得不到响应时，可以快速回滚到V1.0，快速止损。当用户请求到达新服务V2.0能收到预期响应，则可以继续下一批服务的发布。
优点
缺点
适用场景
Rolling deploy是一种较为稳健和逐步的部署策略，适用于对风险敏感且需要更好控制部署过程的情况。它可以减少系统故障的风险，但需要更多的时间和资源来确保顺利完成部署，并在整个过程中维持系统的稳定性和用户体验。
定义
Blue-Green Deployment，中文翻译为：蓝绿部署，它允许在生产环境中同时维护两个相同的系统版本：一个为当前生产版本（蓝色），另一个为新版本（绿色）。
原理
如下图：Blue为老环境，提供正常服务；Green为新环境，部署新的服务，不对实际用户提供服务，因此，QA 团队可以在 Green环境中测试新版本，如果发现任何错误或问题都可以快速修复它们。
如果 Green环境验证OK，达到上线条件，就可以把 Blue环境的流量慢慢切到 Green环境，假如 Green环境出现任何异常，又可以快速回滚到 Blue环境，如下图：
总的来说，Blue-Green Deployment 的原理是通过在两个相同的环境中进行部署，逐步切换流量，实现零宕机和无缝切换新版本应用程序的目标。
优点
缺点
适用环境
Blue-Green 部署策略通常用于大规模应用程序或关键系统，以确保在部署过程中用户不会受到影响，同时提供快速回滚机制以应对可能出现的问题。
定义
Canary Deployment，中文翻译为：金丝雀部署，其实就是灰度发布。它允许在生产环境中逐步将新版本应用程序推送给一小部分用户或服务器，然后根据实时性能和用户反馈逐步增加新版本的比例，直到最终将所有用户或服务器都切换到新版本。这种部署方法得名于金丝雀鸟（Canary），它是用来检测气体中有毒物质的早期指示器。
原理
如下图：首先会部署出一个新版本的小集群，然后将小部分真实用户切换到小集群上，如果在小集群上验证业务OK，则可以服务全部部署成V2.0，如果小集群上出现任何问题，只需要把用户切换到V1集群上，然后对小集群进行修复。
优点
缺点：
适用环境
Canary Deployment 特别适用于大型和复杂的系统，它可以帮助团队在更新时最小化风险，并及时发现和解决潜在问题，提供更好的用户体验和服务质量。但它也需要较高的部署复杂性和实时监控要求。
在实际生产中，Canary Deployment 通常不是一个独立的策略，它通常与Rolling deploy相结合，以创建一种将两全其美的方法结合在一起的方法。
定义
Feature Toggle，中文翻译为：功能开关，它允许开发团队在运行时控制应用程序的功能可见性，即通过开关来启用或禁用特定功能。这种技术的核心原理是将特定功能的开启状态从代码中解耦出来，使得在不修改代码的情况下，可以在运行时灵活地切换功能的开启状态。
原理
如下图：在服务部署的代码中设置开关，控制真实的逻辑
优点
缺点
适用环境
Feature Toggle 适用于代码存在多套逻辑的场景，可以帮助团队更灵活地开发和部署功能，减少部署风险，支持逐步发布和A/B测试。然而，使用Feature Toggle 需要慎重考虑，确保在长期维护过程中不会导致过多的技术债务和复杂性增加。
本文分别讲解了 Bing Bang deploy，Rolling Deploy，Blue-Green Deploy，Canary Deploy，Feature Toggle 5种策略的原理和优缺点，适用场景。名字看起来很高深，似乎都没有听过，但仔细了解一下都是日常部署常用的方法。下面再通过一家电商公司的发展历程来总结描述这几种部署策略：
初创时期，快速搭建产品，没有真实用户，只需要部署一台服务器，每次新功能的迭代可以采取 Bing Bang deploy 这种全量部署策略 。
随着业务的发展，产品已经积累了少部分用户，需要部署多台服务器，每次新功能的迭代，我们可以采用 Rolling Deploy部署策略，先部署一台，验证OK了，再以此类推部署剩余的服务。
因为业务摸索过程，难免有web端需要整体改版，因此可以采用 Blue-Green Deploy策略，部署一套全新环境（UI 和后端，测试等等），等验收 OK后，再把原服务（Blue环境）切换到新的服务（Green环境）。
再随着业务的发展，服务集群已经发展到 几十台机器，用户群体也已经上千万，为了考虑更多的用户体验，我们就需要采用 Canary Deploy策略，每次新功能迭代都会先让小部分用户使用，如果出现问题可以及时回滚。
电商领域，商品搜索是用户高频操作，显然 MySQL不太适合，因此，需要引入Elastic Search 来做全文检索，这时可以采用 Feature Toggle策略，服务代码中存在 Mysql 和 Es两套环境，通过开关来灵活切换流量走哪一种方式。
当然，实际生产中的部署可能会更复杂，但万变不离其宗，有这 5种策略的加持，可以帮助我们更好地适应更复杂的环境部署。
到此这篇服务器部署方式有哪几种（服务器部署方式有哪些）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/haskellbc/64667.html