项目迭代过程中，上线是不可避免的。上线对应部署或重新部署，部署对应修改，修改意味着风险。部署的技术有很多种，有的简单，有的复杂，有的需要停机，有的可以不停机部署。本文将对目前常用的部署方案做一个简单的总结。Blue/GreenDeployment（蓝/绿部署）1.蓝绿部署定义为保留旧版本，部署新版本，然后测试。确认OK后，流量会切换到新版本，然后旧版本也会升级到新版本。2.特点蓝绿部署，无需停机，风险更小。3.部署流程部署版本1的应用（初始状态），所有外部请求流量都打到这个版本。部署应用程序的版本2版本2具有与版本1不同的代码（新功能、错误修复等）。将流量从版本1切换到版本2，如果版本2测试正常，删除版本1正在使用的资源（如实例），然后正式使用版本2。4.总结从流程上看，不难发现我们的应用在部署过程中一直在线。并且在推出新版本的过程中，没有对旧版本的内容进行修改。部署时不会影响老版本的状态，风险很小。而且只要不删除旧版本的资源，理论上我们可以随时回滚到旧版本。5、蓝绿发布注意事项切换到蓝环境时，需要妥善处理未完成的业务和新增业务。如果你的数据库后台处理不了，那就是个麻烦的问题。可能会出现微服务架构应用和传统架构应用需要同时处理的情况。如果两者在蓝绿部署中没有协调好，服务仍然可能停止。需要提前考虑数据库和应用部署的同步迁移/回滚问题。蓝绿部署需要基础设施支持。在非隔离基础设施（VM、Docker等）上进行蓝绿部署，蓝环境和绿环境存在被破坏的风险。六、优缺点优点升级切换和回滚速度非常快。切换不够充分，如果V2版本出现问题，将直接影响用户体验。需要两倍的机器资源。7、适用场合对用户体验有一定的宽容度。机器资源是备用的，也可以按需分配（AWS云，或者自建容器云）。灰度发布1.定义灰度发布是指一种能够在黑白之间平滑过渡的发布方式。ABTest是一种灰度发布方式，让一部分用户继续使用A，一部分用户开始使用B，如果用户对B没有异议，然后逐步扩大范围，将所有用户迁移到B。灰度发布可以保证整个系统的稳定性，可以在初始灰度阶段发现问题并进行调整，保证其影响。灰度发布结构图2.A/B测试A/B测试是用来测试应用程序的功能性能的方法，如可用性、流行度、可见性等。A/B测试经常用在APP的前端，当然也需要后端的支持。A/B测试与蓝绿部署的区别在于，A/B测试的目的是通过科学的实验设计、样本代表性、流量细分和小流量测试，获得具有代表性的实验结论，并确定结论的可信度。蓝绿部署的目的是安全稳定地发布新版本的应用程序，并在必要时回滚。3、金丝雀发布我们通常所说的金丝雀部署，也是灰度发布的一种方式。当原始版本可用时，将应用程序的新版本部署为“金丝雀”服务器以测试新版本。性能和性能，以保证整个系统的稳定性，及早发现和调整问题。矿井中的金丝雀：17世纪，英国矿工发现金丝雀对甲烷气体很敏感。即使空气中有极少量的气体，金丝雀也会停止歌唱；当气体含量超过一定限度时，虽然迟钝的人类还没有察觉，但金丝雀已经中毒身亡。当时，在采矿设备相对简单的条件下，工人们每次下矿都会带一只金丝雀作为瓦斯检测指标，以便遇到危险时可以撤离。Canaryrelease/金丝雀发布包括以下步骤：准备各个阶段部署的工件，包括：构建工件、测试脚本、配置文件和部署清单文件。从负载平衡器列表中删除“金丝雀”服务器。升级“金丝雀”应用程序（排出原始流量并部署它）。自动测试应用程序。将“金丝雀”服务器添加回负载均衡器列表（连接和健康检查）。如果“金丝雀”在线使用测试成功，升级剩余的其他服务器（否则回滚）。此外，灰度发布还可以设置路由权重，动态调整不同的权重来验证新旧版本。4.优缺点优点用户体验影响不大，灰度发布过程中出现的问题只影响小部分用户。发布自动化不够，发布过程中可能会造成服务中断。滚动更新部署（RollingUpdateDeployment）是基于金丝雀发布的进一步优化和改进。是一种自动化程度高、用户体验流畅的发布方式。是目前成熟技术组织采用的主流发布方式。1、定义滚动发布：一般是取出一台或多台服务器停止服务，进行更新，再重新投入使用。如此反复，直到集群中的所有实例都更新到新版本。2.特点与蓝绿部署相比，这种部署方式更节省资源——不需要运行两个集群和两倍数量的实例。我们可以分段部署，比如每次只取出20%的集群进行升级。3.部署过程滚动发布一般从1台服务器开始，或者比例很小，比如2%的服务器，主要是做流量验证，类似于金丝雀（Canary）测试。滚动发布需要更复杂的发布工具和智能LB，支持平滑的版本更换和流量拉入拉出。每次发布，先从LB中移除旧版本V1流量，然后清除旧版本，释放新版本V2，将LB流量接入新版本。这样可以确保尽可能不影响用户体验。一个滚动发布一般由多个发布批次组成，每个批次的数量一般是可配置的（可以通过发布模板定义）。比如第一批1个单位（金丝雀），第二批10%，第三批50%，第四批100%。每批之间有一个观察间隔，人工验证或者监控反馈保证没有问题再发送下一批，所以整体滚动发布过程比较慢（金丝雀时间一般比后续批时间长，例如金丝雀为10分钟，后续间隔为2分钟）。回滚是发布的逆过程。新版本流量从LB中移除，新版本清除，旧版本发送，LB流量接入旧版本。和发布过程一样，回滚过程一般比较慢。4.优缺点优点对用户体验影响小，体验更流畅。发布不足和回滚时间很慢。发布工具比较复杂，LB需要平滑的流量移除和拉取能力。其他发布方式以上是比较传统的发布方式，可以覆盖大部分应用发布场景。对于一些关键新功能的上线，或者一些特定的场景，也有一些特殊的发布方式。特性开关发布在代码中使用特性标志（FeatureFlag/Toggle/Switch）来控制发布逻辑。一般不需要复杂的发布工具和智能LB的配合。它是一种成本相对较低且简单的发布方式。这种方式也支持现代DevOps的理念，开发者可以自己灵活定制和发布。功能开关的原理如下图所示：1.部署流程功能开关的发布需要配置中心或者开关中心等服务支持，比如携程的Apollo配置中心或者开源的FF4J，都支持开关释放。业界也有专门的功能切换SaaS服务，比如LaunchDarkly。通过配置中心，运维或研发人员可以在运行时动态配置功能开关的值。当然，功能开关发布只是配置中心的一种使用场景，配置中心还可以支持很多其他的动态配置场景。功能切换服务一般会提供客户端SDK，方便开发者集成。在运行期间，客户端SDK会同步最新的switch值，该技术可以采用推方式（push）、拉方式（pull）或者推拉结合的方式实现。新功能（V2newfeature）和旧功能（V1oldfeature）住在同一套代码中，新功能隐藏在开关后面。如果开关没有打开，则使用旧的代码逻辑，如果开关打开，则使用新的代码逻辑。技术实现可以理解为一个简单的if/else逻辑。应用上线后，先不开启开关，运维或研发人员通过开关中心开启新功能。经流量验证，新功能没有问题，发布完成；如果出现问题，可以随时通过切换中心切换回旧的功能逻辑。2.优缺点优点升级切换和回滚速度非常快。与复杂的发布工具相比，实现起来比较简单，成本也比较低。研发可灵活定制发布逻辑，支持DevOps自助发布。切换不够充分，如果V2版本出现问题，将直接影响用户体验。如果代码被入侵，代码逻辑会变得复杂，需要定期清理旧版本的逻辑，增加维护成本。影子测试对于一些涉及核心业务的遗留系统的升级改造，为了确保万无一失，有一个大招叫影子测试，它是通过使用更复杂的流量复制、回放和比对技术来实现的。以下是影子测试的示例架构图：1.部署过程影子测试一般适用于遗留系统的等价重构和迁移，比如.net转Java，SQLServer数据库升级MySQL等，应该有不要有太多的外部依赖。否则需要开发很多mock，测试部署成本高，比对比测试更复杂，更不稳定。目标是将旧的遗留服务迁移和升级到新的实验服务。测试开始前，需要在测试环境部署一个遗留服务和一个实验服务，并将生产数据库复制两份到测试环境。同时需要收集生产请求日志，一般可以通过kafka队列收集，然后使用goreplay之类的工具在kafka中消费请求日志，复制回放，分发请求到遗留服务和实验服务，并在收到响应后进行比对，如果所有响应比对都成功，则可以认为遗留服务和实验服务在功能逻辑上是等价的；如果出现响应失败，则认为两者在功能逻辑上不等价，需要修复并重启实验服务。执行阴影测试，直到所有比较都成功。根据系统的复杂程度和关键程度，短的对比测试可能需要数周，长的可能长达半年。影子测试不会对生产流量产生影响，因为旁路是在独立的测试环境中执行的。2.优势和劣势优势对生产用户体验绝对没有影响。您可以使用生产实际流量进行测试（复制比较）。缺点搭建复杂度很高，技术门槛高，数据库导出复制困难。外部依赖不能太多，否则测试部署成本高，比对比测试更复杂，更不稳定。
