在我的项目迭代的过程中，不可避免须要”上线“。上线对应着部署，或者重新部署；部署对应着批改；批改则意味着危险。目前有很多部署公布的技术, 这儿将常见的做一个总结。
下面所说不免有些形象, 举一个情景例子, 退出你是微博我的项目负责人员, 当初新版本较原来的老版本有很大的扭转, 这设计到服务架构、前端 UI 等等, 通过测试性能没有阻碍, 那么这时候如何让用户切换到新的版本呢?
不言而喻, 第一次公布的利用是没有所谓的这个问题的, 这种如何公布的思考只会呈现在前面的版本迭代中。
蓝绿公布
蓝绿部署中，一共有两套零碎：一套是正在提供服务零碎(也就是下面说的旧版)，标记为“绿色”；另一套是筹备公布的零碎，标记为“蓝色”。两套零碎都是功能完善的，并且正在运行的零碎，只是零碎版本和对外服务状况不同。正在对外提供服务的老零碎是绿色零碎，新部署的零碎是蓝色零碎。
蓝色零碎不对外提供服务，用来做啥？
用来做公布前测试，测试过程中发现任何问题，能够间接在蓝色零碎上批改，不烦扰用户正在应用的零碎。
蓝色零碎通过重复的测试、批改、验证，确定达到上线规范之后，间接将用户切换到蓝色零碎, 切换后的一段时间内，仍旧是蓝绿两套零碎并存，然而用户拜访的曾经是蓝色零碎。这段时间内察看蓝色零碎（新零碎）工作状态，如果呈现问题，间接切换回绿色零碎。
当确信对外提供服务的蓝色零碎工作失常，不对外提供服务的绿色零碎曾经不再须要的时候，蓝色零碎正式成为对外提供服务零碎，成为新的绿色零碎。原先的绿色零碎能够销毁，将资源释放出来，用于部署下一个蓝色零碎。
蓝绿公布特点
- 蓝绿部署的目标是缩小公布时的中断工夫、可能疾速撤回公布。
- 两套零碎没有耦合的时候能力百分百保障不烦扰
蓝绿公布注意事项
蓝绿部署只是上线策略中的一种，它不是能够应答所有状况的万能计划。蓝绿部署可能简略快捷施行的前提假如是指标零碎是十分内聚的，如果指标零碎相当简单，那么如何切换、两套零碎的数据是否须要以及如何同步等，都须要认真思考。
当你切换到蓝色环境时，须要得当解决未实现的业务和新的业务。如果你的数据库后端无奈解决，会是一个比拟麻烦的问题；
- 可能会呈现须要同时解决“微服务架构利用”和“传统架构利用”的状况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务进行。
- 须要提前思考数据库与利用部署同步迁徙 / 回滚的问题。
- 蓝绿部署须要有基础设施反对。
- 在非隔离基础架构（VM、Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被捣毁的危险。
滚动公布
个别是取出一个或者多个服务器进行服务，执行更新，并从新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。
公布流程:
绝对于蓝绿公布须要一套齐备的机器不同, 滚动公布只须要一台机器(这儿这是为了了解, 理论可能是多台), 咱们只须要将局部性能部署在这台机器上, 而后去替换正在运行的机器, 如上图, 将更新后的性能部署在 Server1 上, 而后 Server1 去替换正在运行的 Server, 替换下来的物理机又能够持续部署 Server2 的新版本, 而后去替换正在工作的 Server2 , 以此类推, 直到替换完所有的服务器, 至此 , 服务更新实现。
滚动公布特点
- 这种部署形式绝对于蓝绿部署，更加节约资源——它不须要运行两个集群、两倍的实例数。咱们能够局部部署，例如每次只取出集群的 20% 进行降级。
- 回滚艰难
滚动公布注意事项
- 滚动公布没有一个确定可行的环境。应用蓝绿部署，咱们可能清晰地晓得老版本是可行的，而应用滚动公布，咱们无奈确定。
- 批改了现有的环境。
- 回滚艰难。举个例子，在某一次公布中，咱们须要更新 100 个实例，每次更新 10 个实例，每次部署须要 5 分钟。当滚动公布到第 80 个实例时，发现了问题，须要回滚，这个回滚却是一个苦楚，并且漫长的过程。
- 有的时候，咱们还可能对系统进行动静伸缩，如果部署期间，零碎主动扩容 / 缩容了，咱们还需判断到底哪个节点应用的是哪个代码。只管有一些自动化的运维工具，然而仍然令人大惊失色。
- 因为是逐渐更新，那么咱们在上线代码的时候，就会短暂呈现新老版本不统一的状况，如果对上线要求较高的场景，那么就须要思考如何做好兼容的问题。
灰度公布
灰度公布, 也叫金丝雀公布。是指在黑与白之间，可能平滑过渡的一种公布形式。AB test 就是一种灰度公布形式，让一部分用户持续用 A，一部分用户开始用 B，如果用户对 B 没有什么拥护意见，那么逐渐扩大范围，把所有用户都迁徙到 B 下面来。灰度公布能够保障整体零碎的稳固，在初始灰度的时候就能够发现、调整问题，以保障其影响度，而咱们平时所说的金丝雀部署也就是灰度公布的一种形式。举荐：基于 Nginx 实现灰度公布与 AB 测试
具体到服务器上, 实际操作中还能够做更多管制，譬如说，给最后更新的 10 台服务器设置较低的权重、管制发送给这 10 台服务器的申请数，而后逐步进步权重、减少申请数。一种平滑过渡的思路, 这个管制叫做“流量切分”。
17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体非常敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会进行歌唱；而当瓦斯含量超过肯定限度时，尽管鲁钝的人类毫无觉察，金丝雀却早已毒发身亡。过后在采矿设施绝对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险情况下紧急撤退。
过程
- 筹备好部署各个阶段的工件，包含：构建工件，测试脚本，配置文件和部署清单文件。
- 将“金丝雀”服务器部署进服务器中, 测试。
- 从负载平衡列表中移除掉“金丝雀”服务器。
- 降级“金丝雀”利用（排掉原有流量并进行部署）。
- 对利用进行自动化测试。
- 将“金丝雀”服务器从新增加到负载平衡列表中（连通性和健康检查）。
- 如果“金丝雀”在线应用测试胜利，降级残余的其余服务器。（否则就回滚）
A/ B 测试
A/ B 测试和蓝绿公布、滚动公布以及金丝雀公布，齐全是两回事。
蓝绿公布、滚动公布和金丝雀是公布策略，指标是确保新上线的零碎稳固，关注的是新零碎的 BUG、隐患。
A/ B 测试是成果测试，同一时间有多个版本的服务对外服务，这些服务都是通过足够测试，达到了上线规范的服务，有差别然而没有新旧之分（它们上线时可能采纳了蓝绿部署的形式）。
A/ B 测试关注的是不同版本的服务的实际效果，譬如说转化率、订单状况等。
A/ B 测试时，线上同时运行多个版本的服务，这些服务通常会有一些体验上的差别，譬如说页面款式、色彩、操作流程不同。相干人员通过剖析各个版本服务的实际效果，选出成果最好的版本。
作者：等不到的口琴
链接：cnblogs.com/Courage129/p/14498788.html