运维部署/上线/发布的方式

Posted 2021-05-26 卑微小胡

运维部署/上线/发布的方式

文章目录

• 运维部署/上线/发布的方式
• • 运维部署各种发布方式
  • • 蓝绿部署
    • 灰度发布（金丝雀发布）
    • 滚动发布
    • 红黑部署

运维部署各种发布方式

线上平稳发布（部署）手段：
蓝绿部署
灰度发布（金丝雀发布）
滚动发布
红黑部署

蓝绿部署

蓝绿部署，英文名Blue Green Deployment，是一种可以保证系统在不间断提供服务的情况下上线的部署方式。
如何保证系统不间断提供服务呢？
蓝绿部署的模型中包含两个集群，就好比海豚的左脑和右脑。

在没有上线的正常情况下，集群A和集群B的代码版本是一致的，并且同时对外提供服务。

在系统升级的时候下，我们首先把一个集群（比如集群A）从负载列表中摘除，进行新版本的部署。集群B仍然继续提供服务。

当集群A升级完毕，我们把负载均衡重新指向集群A，再把集群B从负载列表中摘除，进行新版本的部署。集群A重新提供服务。

最后，当集群B也升级完成，我们把集群B也恢复到负载列表当中。这个时候，两个集群的版本都已经升级，并且对外的服务几乎没有间断过。

蓝绿部署的优点：
这种方式的好处在你可以始终很放心的去部署inactive环境，如果出错并不影响生产环境的服务，如果切换后出现问题，也可以在非常短的时间内把再做一次切换，就完成了回滚。而且同时在线的只有一个版本。蓝绿部署无需停机，并且风险较小。
(1) 部署版本1的应用（一开始的状态），所有外部请求的流量都打到这个版本上。
(2) 部署版本2的应用，版本2的代码与版本1不同(新功能、Bug修复等)。
(3) 将流量从版本1切换到版本2。
(4) 如版本2测试正常，就删除版本1正在使用的资源（例如实例），从此正式用版本2。
从过程不难发现，在部署的过程中，应用始终在线。并且，新版本上线的过程中，并没有修改老版本的任何内容，在部署期间，老版本的状态不受影响。这样风险很小，并且，只要老版本的资源不被删除，理论上，可以在任何时间回滚到老版本。
蓝绿部署的弱点：
使用蓝绿部署需要注意的一些细节包括：
1、当切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果数据库后端无法处理，会是一个比较麻烦的问题。
2、有可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能导致服务停止；
3、需要提前考虑数据库与应用部署同步迁移/回滚的问题。
4、蓝绿部署需要有基础设施支持。
5、在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。
6、另外，这种方式不好的地方还在于冗余产生的额外维护、配置的成本，以及服务器本身运行的开销。
蓝绿部署适用的场景：
1、不停止老版本，额外搞一套新版本，等测试发现新版本OK后，删除老版本。
2、蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用。
3、蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。
A/B 测试（A/B Testing）
A版本是线上稳定版本，B版本是迭代版本，如果一下子切到B环境，可能用户会难以适应，所以先部署一个B环境，分一部分流量出来，收集用户反馈后逐步改进B版本，知道用户可以完全接受用B版本替换A版本的程度。

蓝绿发布关注的是新版本的发布（目的是安全稳定地发布新版本应用，并在必要时回滚），而A/B 测试关注的是一个测试的过程（目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信），两者是有区别的。
A/B 测试和蓝绿部署可以同时使用。

灰度发布（金丝雀发布）

金丝雀发布（Canary）也是一种发布策略，和国内常说的灰度发布是同一类策略。
蓝绿部署是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统。

譬如说，目标系统是一组无状态的Web服务器，但是数量非常多，假设有一万台。
这时候，蓝绿部署就不能用了，因为你不可能申请一万台服务器专门用来部署蓝色系统（在蓝绿部署的定义中，蓝色的系统要能够承接所有访问）。

可以想到的一个方法是：
只准备几台服务器，在上面部署新版本的系统并测试验证。测试通过之后，担心出现意外，还不敢立即更新所有的服务器。 先将线上的一万台服务器中的10台更新为最新的系统，然后观察验证。确认没有异常之后，再将剩余的所有服务器更新。
这个方法就是金丝雀发布。

实际操作中还可以做更多控制，譬如说，给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数，然后逐渐提高权重、增加请求数。
这个控制叫做“流量切分”，既可以用于金丝雀发布，也可以用于后面的A/B测试。
蓝绿部署和金丝雀发布是两种发布策略，都不是万能的。有时候两者都可以使用，有时候只能用其中一种。

滚动发布

滚动部署，英文Rolling update，同样是一种可以保证系统在不间断提供服务的情况下上线的部署方式。
和蓝绿部署不同的是，滚动部署对外提供服务的版本并不是非此即彼，而是在更细的粒度下平滑完成版本的升级。

如何做到细粒度平滑升级版本呢？
滚动部署只需要一个集群，集群下的不同节点可以独立进行版本升级。比如在一个16节点的集群中，我们选择每次升级4个节点：




以此类推，最终所有的节点都升级了版本。
优势
只需要维护一个集群,成本较低。
劣势
1.上线过程中，两个版本同时对外服务，不容易定位问题，且容易造成数据错乱。
2.升级和回滚以节点为粒度,操作相对复杂。

红黑部署

这是Netflix采用的部署手段，Netflix的主要基础设施是在AWS上，所以它利用AWS的特性，在部署新的版本时，通过AutoScaling Group用包含新版本应用的AMI的LaunchConfiguration创建新的服务器。测试不通过，找到问题原因后，直接干掉新生成的服务器以及Autoscaling Group就可以，测试通过，则将ELB指向新的服务器集群，然后销毁掉旧的服务器集群以及AutoScaling Group。
红黑部署的好处是服务始终在线，同时采用不可变部署的方式，也不像蓝绿部署一样得保持冗余的服务始终在线。