项目部署类型及区别一、市场常见项目部署方案市场常见项目部署方案分为：蓝绿部署、滚动部署、灰度部署（金丝雀部署）、功能切换发布等。根据2017年DevOps发展报告，高性能组织和低绩效组织在软件交付效率上存在数量级差异。一个技术组织的软件交付能力是一个涉及很多环节的综合能力，其中发布是一个特别重要的环节。目前主流的发布策略，各自的优缺点和适用性，让开发者，尤其是架构师，对现代发布技术有更清晰、更全面的认识，让大家根据自己的企业背景做出正确的发布策略。选择和实践。一个产品或者项目不可能一步到位，一次性推送给用户，所以才有版本。在APP版本更新或者项目迭代的过程中，发布是不可避免的。发布即部署；部署即修改；修改意味着风险。第二个单机群的发布首先解释了单机群的概念。早期我们的机器资源比较紧张，不像现在云计算和虚拟化（包括容器技术）那么发达，所以应用机器基本上都是预先静态分配的（一般都是运维负责分配），原来应用A驻留在这n台机器上，那么下次发布的应用A也驻留在这n台机器上，所以称为单服务器组发布方式。2.1暴力破解如下图，这种破解方式比较简单粗暴，有点像我们传统的软件升级方式，主要是手动完成。首先把旧版本V1全部下载下来，然后把新版本发到机器上。这种方式会引入服务中断（宕机），在开发测试环境是可行的，但是对于生产环境的发布，会直接影响用户体验，一般不推荐这种方式。发布前：发布后：优点及适用场合优点：简单、成本低不足：服务中断影响用户，出现问题回滚慢适用场合：开发测试环境非关键应用（用户影响小）启动公司缺一不可2.2金丝雀发布（单机群）是一种基于暴力发布的简单改进发布方式，目前仍是很多成长性大型技术组织的主流发布方式。单个服务器组下金丝雀发布的简化步骤如下图所示：发布前：先发一个金丝雀：全部发布后：练习要点1.一般是先发布一个金丝雀发布，或者一小部分，例如，2%的服务器主要用于流量验证，也称为金丝雀测试（国内常称灰度测试）。以前，矿工进矿前，都会放一只金丝雀进去，看看有没有毒气，看金丝雀有没有活下来，因此得名金丝雀放生。简单的金丝雀测试一般通过人工测试来验证。复杂的金丝雀测试需要相对完善的监控基础设施。通过监控指标反馈，观察金丝雀的健康状态，作为后续发布或回滚的依据。2、如果金线测试通过，则剩余的V1版本全部升级为V2版本。如果金丝雀测试失败，金丝雀直接回滚，发布失败。优点及适用场合优点：对用户体验影响小，金丝雀发布过程中的问题只影响小部分用户不足：发布自动化程度不够，发布时可能造成服务中断适用场合：对新版本功能信心不足或性能用户体验要求较高的网站业务场景缺乏足够的自动化发布工具研发能力流量模式少量金丝雀先接受流量，然后全量发布2.3Rollingrelease（单服务器组）Rollingrelease外文通常叫RollingUpdate金丝雀部署在release的基础上进一步优化和改进，是一种自动化程度高，用户体验相对流畅的发布方式。是目前成熟技术组织采用的主流发布方式。单个服务器组下滚动发布的简化步骤如下图所示：发布前：发布时，先发布一个金丝雀发布，然后发布多个发布，直到全部发布：实用要点滚动发布一般发送一个发布首先，或者是一小部分，比如2%的服务器，主要用于流量验证，类似于金丝雀测试。滚动发布需要更复杂的发布工具和智能LB，支持平滑的版本更换和流量拉入拉出。每次发布，先从LB中移除旧版本V1流量，然后清除旧版本，释放新版本V2，将LB流量接入新版本。这样可以确保尽可能不影响用户体验。一个滚动发布一般由多个发布批次组成，每个批次的数量一般是可配置的（可以通过发布模板定义）。比如第一批1个单位（金丝雀），第二批10%，第三批50%，第四批100%。每批之间有一个观察间隔，人工验证或者监控反馈保证没有问题再发送下一批，所以整体滚动发布过程比较慢（金丝雀时间一般比后续批时间长，例如金丝雀为10分钟，后续间隔为2分钟）。回滚是发布的逆过程。新版本流量从LB中移除，新版本清除，旧版本发送，LB流量接入旧版本。和发布过程一样，回滚过程一般比较慢。优点及适用场合优点：对用户体验影响小，体验更流畅不足：发布和回滚时间慢发布工具比较复杂，LB需要平滑的流量去除和拉取能力适用场合：不能中断用户体验的网站业务场景某些复杂的发布工具研发能力；流量模式滚动发布，流量平滑过渡三双服务器组发布随着云计算和虚拟化技术的成熟，特别是容器等轻量级虚拟化技术的引入，计算资源有限的应用和应用缓慢的问题逐渐得到解决，可以实现按需灵活分配。一次发布分配两组服务器，一组运行现有的旧V1版本，另一组运行即将上线的新V2版本，然后通过LB切换流量完成发布。这就是所谓的双服群发方式。3.1蓝绿发布（双机组）蓝绿发布只适用于双机组发布，可以认为是一种简单优化的暴力发布方式。简化过程如下图所示：发布前：发布后：练习要点V1版本称为蓝色组，V2版本称为绿色组。释放时，流量直接通过LB-once从蓝组切换到绿组，不经过金组。金丝雀和滚动发布，蓝绿发布就是以此命名的；如果有问题，回滚也很直接，直接通过LB将流量切回蓝组。初步发布成功后，蓝组机器一般不会直接回收，而是留一个等待期。观察期可长可短，视具体情况而定。观察期过后，确认放行没有问题，即可回收蓝组机器。优点及适用场合优点：升级、切换、回滚速度非常快。不足：开关已满。如果V2版本出现问题，将直接影响用户体验；它需要两倍的机器资源；适用场合：对用户体验有一定的容忍度在机器资源丰富或者可以按需分配的场景（AWS云，或者自建容器云），目前还没有复杂的滚动发布工具开发能力；流量模式蓝绿发布一次完成进程切换3.2金丝雀发布（双服务器组）是对蓝绿部署的简单优化。发布时，先从绿色组拉一个金丝雀，金丝雀验证通过后全额释放。与蓝绿发布相比，这种发布方式的优势在于对生产流量有一个金丝雀验证过程，可以降低V2可能出现问题的风险和影响。简化发布流程如下图：发布前：发布过程中，先发布一个金丝雀：完整发布：3.3滚动发布（双机组）滚动发布是对上述蓝绿和金丝雀发布的进一步改进优化，分批增量滚动发布，提供更流畅的用户体验。发布前：发布时，先发一个金丝雀：发布时，再发几个：直到全部发布：练习点在发布前申请一批新服务器，数量一般与V1版本，发布V2版本应用到新服务器。比如你在AWS云上，可以直接调用API申请一批新的VM。如果使用容器云Kubernetes，可以直接启动一批新容器（使用V2版本容器镜像）。一般会先通过LB拉入一台V2机器，这台机器也相当于金丝雀做流量校验。分阶段分批完成发布。每批只需要通过LB拉入V2版本，然后拉出相应数量的V1版本。批次之间有观察间隔，人工或监控反馈确保没有问题才继续发布。如果发布有问题，会很快回滚，只需通过LB将流量切换回V1即可。发布完成后，一般的V1版本要留着观察以备不时之需，比如留1天，如果1天后没有问题，就会回收V1机器资源。优点及适用场合优点：对用户体验影响小；升级切换和回滚（rollback）速度比单服务器组滚动发布更快，LB可以切流量；缺点：需要两倍的机器资源；发布工具比较复杂，需要LB流量切换能力的适用场合：用户体验不能中断，机器资源有余或者可以按需分配的网站业务场景（AWS云，或者自建容器云）有一定的发布工具开发能力；流量模式滚动发布，流量平滑过渡4.其他发布方式以上是比较传统的发布方式，可以覆盖大部分应用发布场景。对于一些关键新功能的上线，或者一些特定的场景，也有一些特殊的发布方式。4.1FeatureSwitchPublishing在代码中使用featureflag/toggle/switch来控制发布逻辑。一般不需要复杂的发布工具和智能LB。它是一种成本相对较低且简单的释放方法。这种方式也支持现代DevOps的理念，开发者可以自己灵活定制和发布。功能切换原理如下图所示：功能切换发布实践要点功能切换发布需要配置中心或者切换中心等服务支持，比如携程的Apollo配置中心，或者开源FF4J，都支持开关发布，业界还有LaunchDarkly等专门的功能开关SaaS服务。通过配置中心，运维或研发人员可以在运行时动态配置功能开关的值。当然，功能开关发布只是配置中心的一种使用场景，配置中心还可以支持很多其他的动态配置场景。功能切换服务一般会提供客户端SDK，方便开发者集成。在运行期间，客户端SDK会同步最新的switch值，该技术可以采用推方式（push）、拉方式（pull）或者推拉结合的方式实现。新功能（V2newfeature）和旧功能（V1oldfeature）住在同一套代码中，新功能隐藏在开关后面。如果开关没有打开，则使用旧的代码逻辑，如果开关打开，则使用新的代码逻辑。技术实现可以理解为一个简单的if/else逻辑。应用上线后，先不开启开关，运维或研发人员通过开关中心开启新功能。经流量验证，新功能没有问题，发布完成；如果出现问题，可以随时通过切换中心切换回旧的功能逻辑。优点及适用场合优点：升级切换和回滚速度非常快。与复杂的发布工具相比，实现起来相对简单，成本也相对较低。研发可灵活定制发布逻辑，支持DevOps。如果出现问题，将直接影响用户体验；如果代码被入侵，代码逻辑会变得复杂，需要定期清理旧版本的逻辑，增加维护成本。中央服务不具备开发复杂发布工具的能力；流量模式可以通过功能切换一次性完成流量切换4.2A/B测试A/B测试主要用于产品功能的对比测试，收集用户反馈和产品功能设计决策的对比数据。事实上，A/B测试也可以作为一种新功能发布技术。下图是一个基于LB实现的A/B测试发布。实践要点上图中，PC端和移动端均接入老版本V1服务（也称A组或控制组）。当新版本的V2（也称B组或实验组）发布时，为了验证V2的功能是否正确，同时为了避免V2出现问题时影响到所有用户，首先将手机上的流量通过LB切换到V2版本，经过一段时间的A/B对比测试和观察（主要通过用户和监控反馈），确保V2正常，将所有流量通过LB切换到V2。要实现基于LB的A/B测试，LB需要能够通过某些条件来路由流量，例如客户端ip、设备类型、浏览器类型，甚至是自定义的HTTP标头或查询字符串。高级A/B测试需要特殊的平台支持。Wasabi是intuit支持的开源平台，支持高级A/B测试。这类平台可以细粒度的针对特定类型的用户做A/B测试，比如针对某个地区。用户、某个年龄段的用户、公司内部的用户等。例如，假设一个关键业务的新功能上线了。为了降低风险，可以使用A/B测试只允许公司内部员工访问新功能。新功能通过验证后，即可全面对外发布。使用。功能开关和A/B测试有些类似，但是功能开关一般是无状态的、全量程的，不能针对特定类型的用户进行测试，而A/B测试一般是有状态的，可以跟踪交易和用户级别的状态，可用于测试特定类型的用户。优点及适用场合优点：对用户体验影响小；可以使用生产流量测试；可以针对特定类型的目标用户进行测试；缺点：搭建复杂度较高，有一定的技术门槛适用场合：核心关键业务，如涉及基金有一定的A/B测试平台研发能力，流量模式，对某些类型进行A/B测试的目标用户。大招是使用更复杂的流量复制、回放和比较技术来实现。下面是影子测试的示例架构图。实践要点是实现旧遗留服务向新实验服务的迁移升级。测试开始前，需要在测试环境部署一个遗留服务和一个实验服务，并将生产数据库复制两份到测试环境。同时需要收集生产请求日志，一般可以通过kafka队列收集，然后使用goreplay之类的工具在kafka中消费请求日志，复制回放，分发请求到遗留服务和实验服务，并在收到响应后进行比对，如果所有响应比对都成功，则可以认为遗留服务和实验服务在功能逻辑上是等价的；如果出现响应失败，则认为两者在功能逻辑上不等价，需要修复并重启实验服务。执行阴影测试，直到所有比较都成功。根据系统的复杂程度和关键程度，短的对比测试可能需要数周，长的可能长达半年。影子测试不会对生产流量产生影响，因为旁路是在独立的测试环境中执行的。影子测试一般适用于遗留系统的等价重构和迁移，比如从.net转Java，或者将SQLServer数据库升级为MySQL数据库，外部依赖不宜过多。测试更复杂和不稳定。当当网有一个比较成功的交易系统.NET到Java的迁移项目，使用了影子测试技术，值得参考。优势及适用场合优势：完全不影响生产用户体验可以使用真实生产流量进行测试（复制对比）不足：建设复杂度高，技术门槛高，数据库导出和复制难度大。外部依赖不能太多，否则测试部署成本高，对比测试更复杂，不稳定。适用场合：涉及资金等核心业务，具有一定的影子测试平台研发能力，包括流量复制、数据库导出复制、分布对比系统等。流量模式影子测试对生产流量没有影响5各种发布策略对比6结论和建议开发测试环境，对用户体验不敏感的非关键应用，或者启动期什么都没有的无奈之举。2、如果你还没有开发更复杂的滚动发布工具和支持智能LB，功能切换是一个很好的轻量级发布技术，可以让开发者以相对较小的投入灵活定制发布逻辑。3.金丝雀发布通过从少量新版本服务器接收生产流量来验证新版本，可以显着降低风险。金丝雀发布适用于大部分场景，一般成长型企业均可采用。4.对于有一定业务量的企业，考虑到用户体验对业务的重要性，需要投入研发资源开发支持滚动发布、支持智能LB的工具，实现自动化零宕机发布。滚动发布通常与金丝雀发布配合使用。先发行金丝雀验证流量，然后分批发布。5、随着轻量级虚拟化（如容器）的普及，双机组发布方式发布和回滚速度更快，是一种值得投资的高级发布技术。蓝绿部署只适用于双机组，滚动发布可以在单服务器组或双服务器组上实现。6、对于涉及关键核心业务的新功能上线，A/B测试可以显着降低上线风险。A/B测试是唯一支持针对特定用户组进行生产测试的高级发布技术。当然A/B测试的投入也不低，推荐有一定研发能力的机构采用。7、针对关键核心业务的迁移重构，为确保万无一失，最后一个大动作是影子测试，对生产流量和用户没有影响。当然，这个大招的投资成本和门槛都很高，建议有足够业务量和研发能力的机构投资。上面提到的各种发布策略不是非此即彼。一个公司往往会使用多种发布技术作为补充来实现灵活的发布能力。比如主流的发布方式是金丝雀+滚动发布。部分业务线可能会根据业务场景采用功能切换发布，部分业务线可能采用高级A/B测试发布方式。转载文献：[1]杨波．极客时间：https://mp.weixin.qq.com/s?__...
