关于linux:常用项目部署方案和区别

我的项目部署类型和区别

一 市场罕用我的项目部署计划

市场罕用我的项目服务部署分为：蓝绿部署、滚动部署、灰度部署（金丝雀部署）、性能开关公布等

依据 2017 年的 DevOps 倒退报告，高效能组织和低效能组织在软件交付的效率上有数量级上的差别。技术组织的软件交付能力是一种综合能力，波及泛滥环节，其中公布是尤为重要的环节。

以后支流的公布策略，每个的优劣，适用性，让开发人员特地是架构师对古代公布技术有一个更为清晰全面的意识，让大家可能依据本人的企业上下文，对公布策略做出正确的选型和实际。

产品或我的项目不可能一步到位，一次性推向用户，故而有版本的存在。在 app 版本更新或者我的项目迭代的过程中，不可避免须要公布。公布就是部署；部署就是批改；批改则意味着危险。

二 单服务器组公布

先解释下单服务器组的概念，新近咱们机器资源比拟缓和，不像当初云计算和虚拟化（包含容器技术）这么发达，所以利用机器根本是事后动态调配好的（个别由运维负责调配），原来利用 A 住在这 n 台机器上，那么下次降级公布的利用 A 也住在这 n 台机器上，所以称为单服务器组公布形式。

2.1 蛮力公布

如下图所示，这种公布形式比较简单粗犷，有点像咱们传统的软件降级形式，次要靠手工实现，先将老版本 V1 全副下掉，再将新版本发到机器下来。这种形式会引入服务中断（停机），在开发测试环境是可行的，但对于生产环境公布，其会间接影响用户的应用体验，这种形式个别是不倡议的。

公布前:

公布后:

劣势和实用场合

劣势：

• 简略成本低
• 有余：
• 服务中断用户受影响，出了问题回退也慢

实用场合：

• 开发测试环境
• 非关键利用（用户影响面小）
• 初创公司什么都缺，找夜深人静用户访问量小的工夫干

流量模式

蛮力发布会引入服务中断工夫

2.2 金丝雀公布（单服务器组）

在蛮力公布根底上的一种简略改良公布形式，目前依然是不少成长型技术组织的支流公布形式。单服务器组下的金丝雀公布的简化步骤如下图所示：

公布前:

先发一台金丝雀:

全副发完:

实际要点

• 1、金丝雀公布个别先发 1 台，或者一个小比例，例如 2% 的服务器，次要做流量验证用，也称为金丝雀 (Canary) 测试（国内常称灰度测试）。以前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀是否活下来，金丝雀公布由此得名。简略的金丝雀测试个别通过手工测试验证，简单的金丝雀测试须要比较完善的监控基础设施配合，通过监控指标反馈，察看金丝雀的健康状况，作为后续公布或回退的根据。
• 2、如果金丝测试通过，则把残余的 V1 版本全副降级为 V2 版本。如果金丝雀测试失败，则间接回退金丝雀，公布失败。

劣势和实用场合

劣势：

• 用户体验影响小，金丝雀公布过程呈现问题只影响大量用户

有余：

• 公布自动化水平不够，公布期间可引发服务中断
• 实用场合：
• 对新版本性能或性能不足足够信念
• 用户体验要求较高的网站业务场景
• 不足足够的自动化公布工具研发能力

流量模式

大量金丝雀先承受流量，再全量公布

2.3 滚动式公布（单服务器组）

滚动式公布国外术语通常叫 Rolling Update Deployment

在金丝雀公布根底上的进一步优化改良，是一种自动化程度较高的公布形式，用户体验比拟平滑，是目前成熟型技术组织所采纳的支流公布形式。单服务器组下的滚动公布的简化步骤如下图所示：

公布前:

公布中，先发一台金丝雀

公布中，再发若干台

直到全副发完:

实际要点

• 滚动式公布个别先发 1 台，或者一个小比例，如 2% 服务器，次要做流量验证用，相似金丝雀 (Canary) 测试。
• 滚动式公布须要比较复杂的公布工具和智能 LB，反对平滑的版本替换和流量拉入拉出。
• 每次公布时，先将老版本 V1 流量从 LB 上摘除，而后革除老版本，发新版本 V2，再将 LB 流量接入新版本。这样能够尽量保障用户体验不受影响。
• 一次滚动式公布个别由若干个公布批次组成，每批的数量个别是能够配置的（能够通过公布模板定义）。例如第一批 1 台（金丝雀），第二批 10%，第三批 50%，第四批 100%。每个批次之间留察看距离，通过手工验证或监控反馈确保没有问题再发下一批次，所以总体上滚动式公布过程是比拟迟缓的 (其中金丝雀的工夫个别会比后续批次更长，比方金丝雀 10 分钟，后续距离 2 分钟)。
• 回退是公布的逆过程，将新版本流量从 LB 上摘除，革除新版本，发老版本，再将 LB 流量接入老版本。和公布过程一样，回退过程个别也比较慢的。

劣势和实用场合

劣势：

• 用户体验影响小，体验较平滑

有余：

• 公布和回退工夫比拟迟缓
• 公布工具比较复杂，LB 须要平滑的流量摘除和拉入能力

实用场合：

• 用户体验不能中断的网站业务场景
• 有肯定的简单公布工具研发能力；

流量模式

滚动式公布，流量平滑过渡

三 双服务器组公布

随着云计算和虚拟化技术的成熟，特地是容器等轻量级虚拟化技术的引入，计算资源受限和申请迟缓问题曾经逐渐解决，能够做到弹性按需分配。为一次公布调配两组服务器，一组运行现有的 V1 老版本，一组运行待上线的 V2 新版本，再通过 LB 切换流量形式实现公布，这就是所谓的双服务器组公布形式。

3.1 蓝绿公布（双服务器组）

蓝绿公布仅实用于双服务器组公布，能够认为是对蛮力公布的一种简略优化公布形式。简化过程如下图所示：

公布前:

公布后:

实际要点

• V1 版本称为蓝组，V2 版本称为绿组，公布时通过 LB – 一次性将流量从蓝组间接切换到绿组，不通过金丝雀和滚动公布，蓝绿公布由此得名；
• 呈现问题回退也很间接，通过 LB 间接将流量切回蓝组。
• 公布初步胜利后，蓝组机器个别不间接回收，而是留一个待观察期，视具体情况观察期的工夫可长可短，观察期过后确认公布无问题，则能够回收蓝组机器。

劣势和实用场合

劣势：

• 降级切换和回退速度十分快

有余：

• 切换是全量的，如果 V2 版本有问题，则对用户体验有间接影响；
• 须要两倍机器资源；

实用场合：

• 对用户体验有肯定容忍度的场景
• 机器资源有充裕或者能够按需分配（AWS 云，或自建容器云）
• 暂不具备简单滚动公布工具研发能力；

流量模式

蓝绿公布一次实现流程切换

3.2 金丝雀公布（双服务器组）

对蓝绿部署的一种简略优化，公布时先从绿组拉入 1 台金丝雀，待金丝雀验证通过再发全量。比照蓝绿公布，该公布形式的劣势是有一个生产流量的金丝雀验证过程，能够加重 V2 可能有问题的危险和影响面。简化公布过程如下图所示：

公布前:

公布中，先发一台金丝雀:

全量公布:

3.3 滚动式公布（双服务器组）

滚动式公布是对下面的蓝绿和金丝雀公布的进一步优化，按批次增量滚动公布，提供更平滑的用户体验。

公布前:

公布中，先发一台金丝雀:

公布中，再发若干台:

直到全副发完:

实际要点

• 公布前先申请一批新服务器，数量个别和 V1 版本雷同，将 V2 版本利用公布到新服务器上。例如如果在 AWS 云上，则能够间接调用 API 申请一批新 VM，如果用容器云 Kubernetes，则能够间接启动一批新容器（应用 V2 版本容器镜像）。
• 个别会先通过 LB 拉入 1 台 V2 版本的机器，这台机器也相当于金丝雀，用于流量验证。
• 逐渐按批次实现公布，每批只须要通过 LB 拉入 V2 版本，再拉出对应数量的 V1 版本。批次之间留有察看距离，通过手工或监控反馈确保没有问题再持续公布。
• 公布有问题回退很快，间接通过 LB 将流量切回 V1 即可。
• 实现公布后，个别 V1 版本要保留察看以备万一，比方留 1 天，1 天后没有问题则回收 V1 机器资源。

劣势和实用场合

劣势：

• 用户体验影响小；
• 降级切换和回退（rollback）速度比单服务器组滚动公布要快，LB 切流量即可；

有余：

• 须要两倍机器资源；
• 公布工具比较复杂，LB 须要流量切换能力

实用场合：

• 用户体验不能中断的网站业务场景
• 机器资源有充裕或者能够按需分配（AWS 云，或自建容器云）
• 有肯定的公布工具研发能力；

流量模式

滚动式公布，流量平滑过渡

四 其它公布形式

上述都是偏传统的公布形式，能笼罩大部分利用公布场景。针对一些要害新性能的上线公布，或者一些特定的场景，还有一些非凡的公布形式。

4.1 性能开关公布

利用代码中的性能开关（Feature Flag/Toggle/Switch）来管制公布逻辑，个别不须要简单的公布工具和智能 LB 配合，是一种绝对比拟低成本和简略的公布形式。这种形式也是反对古代 DevOps 理念，研发人员能够灵便定制和自助实现的公布形式。性能开关的原理如下图所示：

性能开关公布

实际要点

• 性能开关公布须要一个配置核心或者开关核心这样的服务反对，例如携程的 Apollo 配置核心，或者开源的 FF4J，这些都反对开关公布，业界还有专门的性能开关 SaaS 服务，例如 LaunchDarkly。通过配置核心，运维或研发人员能够在运行期动静配置性能开关的值。当然，性能开关公布只是配置核心的一种应用场景，配置核心还能反对其它很多动静配置场景。
• 性能开关服务个别提供客户端 SDK，不便开发人员集成。在运行期，客户端 SDK 会同步最新的开关值，技术实现有推形式 (push)，也有拉形式 (pull)，或者推拉联合形式。
• 新性能（V2 new feature）和老性能（V1 old feature）住在同一套代码中，新性能暗藏在开关前面，如果开关没有关上，则走老代码逻辑，如果开关关上，则走新代码逻辑。技术实现上能够了解为一个简略的 if/else 逻辑。
• 利用上线后，开关先不关上，而后运维或研发人员通过开关核心关上新性能，通过流量验证新性能没有问题，则公布实现；如果有问题，则随时能够通过开关核心切回老性能逻辑。

劣势和实用场合

劣势：

• 降级切换和回退速度十分快
• 绝对于简单的公布工具，施行比较简单，老本绝对低廉
• 研发可能灵便定制公布逻辑，反对 DevOps 自助公布

有余：

• 切换是全量的，如果 V2 版本有问题，则对用户体验有间接影响；
• 对代码有侵入，代码逻辑会变简单，须要定期清理老版本逻辑，保护老本变高

实用场合：

• 对用户体验有肯定容忍度的场景
• 已有配置核心或开关核心服务
• 暂不具备研发简单公布工具能力；

流量模式

通过性能开关一次实现流量切换

4.2 A/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 须要可能通过某种条件做流量路由，例如通过 client ip，设施类型，浏览器类型，甚至是定制的 HTTP Header 或查问字符串。
• 高级的 A/B 测试须要专门的平台撑持，wasabi 就是 intuit 开源的一个反对高级 A/B 测试的平台，这类平台能够细粒度到针对某类用户做 A/B 测试，例如针对某个地区的用户，某个年龄段的用户，公司外部用户等等。举了例子，假如一个要害业务的新性能上线，为了升高危险采纳 A/B 测试，能够做到先只让公司外部员工能拜访到新性能，待新性能验证过，再全量放开给内部用户应用。
• 性能开关和 A/B 测试有点类似，但性能开关个别是无状态和全量的，无奈做到针对某类特定用户进行测试，而 A/B 测试个别是有状态的，可能跟踪事务和用户级别的状态，能够实现针对某类特定用户进行测试。

劣势和实用场合

劣势：

• 用户体验影响小；
• 能够应用生产流量测试；
• 能够做到针对某类特定指标用户进行测试；

有余：

• 搭建复杂度绝对高，有肯定技术门槛

实用场合：

• 外围要害业务，比方波及资金的
• 具备肯定的 A/B 测试平台研发能力

流量模式

针对某类指标用户进行 A/B 测试

4.3 影子测试

对于一些波及外围业务的遗留零碎的降级革新，为了确保十拿九稳，有一种称为影子测试的大招，采纳比较复杂的流量复制、回放和比对技术实现。上面是影子测试的一个样例架构图，

实际要点

• 指标实现老的 legacy 服务迁徙降级到新的 experimental 服务。
• 测试开始前，须要在测试环境部署一份 legacy 服务和 experimental 服务，同时将生产数据库复制两份到测试环境。同时须要将生产申请日志收集起来，个别能够通过 kafka 队列收集，而后通过相似 goreplay 这样的工具，生产 kafka 外头的申请日志，复制回放，将申请散发到 legacy 服务和 experimental 服务，收到响应后进行比对，如果所有响应比对胜利，则能够认为 legacy 服务和 experimental 服务在性能逻辑上是等价的；如果有响应比对失败，则认为两者在性能逻辑上不等价，须要修复 experimental 并从新进行影子测试，直到全副比对胜利。依据零碎复杂度和关键性不同，比对测试工夫短的可能须要几周，长的可达半年之久。
• 影子测试因为旁路在独立测试环境中进行，能够对生产流量齐全无影响。
• 影子测试个别实用于遗留零碎的等价重构迁徙，例如.net 转 Java，或者 SQLServer 数据库降级为 MySQL 数据库，且内部依赖不能太多，否则须要开发很多 mock，测试部署老本会很高，且比对测试更加简单和不稳固。
• 当当网有一个比拟胜利的交易系统.NET 转 Java 迁徙我的项目，采纳了影子测试技术，值得参考借鉴。

劣势和实用场合

劣势：

• 对生产用户体验齐全无影响
• 能够应用生产实在流量进行测试（复制比对）

有余：

• 搭建复杂度很高，技术门槛高，数据库的导出复制是难点
• 内部依赖不能太多，否则测试部署老本很高，且比对测试更加简单和不稳固

实用场合：

• 外围要害业务，比方波及资金的
• 具备肯定影子测试平台研发能力，包含流量复制、数据库导出复制和散发比对系统。

流量模式

影子测试对生产流量无影响

五 各种公布策略比照

六 论断和倡议

上面是对公布策略的一些选型倡议，供不同阶段公司参考：

1、蛮力公布个别是不倡议采纳的，除非是开发测试环境，用户体验不敏感的非关键利用，或者是守业期什么都缺时候的无奈之举。

2、如果临时还不具备研发较简单的滚动公布工具和配套智能 LB，则性能开关是一种不错的轻量级公布技术，投入绝对较小的老本，能够让研发人员灵便定制公布逻辑。

3、金丝雀公布通过大量新版本服务器接管生产流量的形式去验证新版本，能够显著升高危险。金丝雀公布实用于大部分场景，个别成长型公司就能够采纳。

4、对于达到肯定业务体量的公司，思考到用户体验对业务的关键性，则须要投入研发资源开发反对滚动式公布的工具和配套的智能 LB，实现自动化和零停机的公布。滚动式公布个别和金丝雀公布配合，先发一台金丝雀去验证流量，再按批次增量公布。

5、随着轻量级虚拟化（例如容器）的遍及，双服务器组公布形式具备更快的公布和回退速度，是值得投入的高级公布技术。蓝绿部署仅实用于双服务器组，滚动式公布既能够在单服务器组上实现，也能够在双服务器组上实现。

6、对于波及要害外围业务的新性能上线，采纳 A/B 测试，能够显著升高公布危险，A/B 测试是惟一一种反对针对特定用户组进行生产测试的高级公布技术。当然 A/B 测试的投入不低，倡议有肯定研发能力的组织采纳。

7、对于要害外围业务的迁徙重构，为确保十拿九稳，最初的一个大招是影子测试，影子测试对生产流量和用户齐全无影响。当然这个大招的投入老本和门槛都高，倡议有足够业务体量和研发能力的组织投入。

上述的各种公布策略并不是非此即彼的，一个公司经常会综合采纳多种公布技术作为互补，实现灵便的公布能力。例如支流的公布伎俩是金丝雀 + 滚动式公布，某些业务线可能依据业务场景须要采纳性能开关公布，还有一些业务线则可能采纳高级的 A/B 测试公布伎俩。

转载文档:

• [1] 杨波. 极客工夫: https://mp.weixin.qq.com/s?__…