蓝绿红黑灰|经常使用的发布方式

1 发布之痛

相信每一个程序员都曾经经历过，或正在经历过发布的痛苦，每一个发布日的夜晚一般是灯火通明。在如今互联网公司较高的发布频率之下更是放大了这种痛苦，多少正值青春年华的程序员为此白了发、秃了头！让程序员经历发布痛苦的缘由有不少，其中之一就是发布方式。
发布形成系统故障影响系统可用性的最大缘由之一。所以大多数的公司会选择在用户量最小的深夜进行发布，这就形成了每到发布日就有一大堆黑眼圈的程序员熬夜坐等发布，但其实有了一些好的发布方式也许就没必要如此。
我曾经带过两家公司，这两家公司团队的对于发布时间的见解则孑然不一样，第一家公司的老是担忧发布会对用用户形成影响，所以每次发布都会选择深夜进行发布。而另外一家公司则认为应该在用户流量最大的时候进行发布，这样系统问题则能够尽早的暴露出来。形成这两种的结果我分析有不少缘由。开发人员信心、交付质量、资源工具、发布方式......咱们今天就来看看一些经常使用的发布方式。

2 经常使用的发布方式

2.1 蛮力发布

顾名思义，这种方式简单而粗暴！直接将新的版本覆盖掉老的版本。其优势就是简单并且成本较低，但缺点一样很明显，就是发布过程当中一般会致使服务中断进而致使用户受到影响，这种方式比较适应于开发环境或者测试环境或者是公司内部系统这种对可用性要求不高的场景，有些小的公司资源稀缺(服务器资源，基础设施等)的时候也会采用这种方式。好比个人第一家公司一开始的规模较小的时候，一般会选择一个夜深人静、访问量小的时候，悄悄地发布。

2.2 金丝雀发布

金丝雀发布是灰度发布的一种。灰度发布是指在黑与白之间，可以平滑过渡的一种发布方式。即在发布过程当中一部分用户继续使用老版本，一部分用户使用新版本，不断地扩大新版本的访问流量。最终实现老版本到新版本的过分。因为金丝雀对瓦斯极其敏感，所以之前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀可否活下来，金丝雀发布由此得名。

发布过程当中，先发一台或者一小部分比例的机器做为金丝雀，用于流量验证。若是金丝雀验证经过则把剩余机器所有发掉。若是金丝雀验证失败，则直接回退金丝雀。金丝雀发布的优点在于能够用少许用户来验证新版本功能，这样即便有问题所影响的也是很小的一部分客户。若是对新版本功能或性能缺少足够信心那么就能够采用这种方式。这种方式也有其缺点，金丝雀发布本质上仍然是一次性的全量发布，发布过程当中用户体验并不平滑，有些隐藏深处的bug少许用户可能并不能验证出来问题，须要逐步扩大流量才能够。

2.3 滚动发布

滚动发布是在金丝雀发布基础上进行改进的一种发布方式。相比于金丝雀发布，先发金丝雀，而后全发的方式，滚动发布则是整个发布过程当中按批次进行发布。每一个批次拉入后均可做为金丝雀进行验证，这样流量逐步放大直至结束。
这种方式的优势就是对用户的影响小，体验平滑，但一样也有不少缺点，首先就是发布和回退时间慢，其次发布工具复杂，负载均衡设备须要具备平滑的拉入拉出能力，通常公司并无资源投入研发这种复杂的发布工具。再者
发布过程当中新老版本同时运行，须要注意兼容性问题。

2.4 蓝绿部署

蓝绿部署，是采用两个分开的集群对软件版本进行升级的一种方式。它的部署模型中包括一个蓝色集群 Group1 和一个绿色集群 Group2，在没有新版本上线的状况下，两个集群上运行的版本是一致的，同时对外提供服务。
系统升级时，蓝绿部署的流程是：

• 从负载均衡器列表中删除集群Group1，让集群 Group2 单独提供服务。
• 在集群 Group1 上部署新版本。
• 集群 Group1 升级完毕后，把负载均衡列表所有指向 Group1，并删除集群 Group2 ，由 Group1 单独提供服务。
• 在集群 Group2 上部署完新版本后，再把它添加回负载均衡列表中。

这样，就完成了两个集群上全部机器的版本升级。
蓝绿部署的优势是升级和回退速度很是快，缺点是全量升级，若是V2版本有问题，对用户影响大再者因为升级过程当中会服务器资源会减小一半，有可能产生服务器过载问题，所以这种发布方式也不适用于在业务高峰期使用。

2.5 红黑发布

与蓝绿部署相似，红黑部署也是经过两个集群完成软件版本的升级。当前提供服务的全部机器都运行在红色集群 Group1 中，当须要发布新版本的时候，具体流程是这样的：

• 先申请一个黑色集群 Group2 ，在 Group2 上部署新版本的服务；
• 等到 Group2 升级完成后，咱们一次性地把负载均衡所有指向 Group2 ；
• 把 Group1 集群从负载均衡列表中删除，并释放集群 Group1 中全部机器。这

这样就完成了一个版本的升级。能够看到，与蓝绿部署相比，红黑部署得到了两个收益：一是，简化了流程；二是，避免了在升级的过程当中，因为只有一半的服务器提供服务，而可能致使的系统过载问题。但一样也存在全量升级对用户的影响问题，也带来了一个新的问题，就是发布过程当中须要两倍的服务器资源。

2.6 功能开关

这种发布方式是利用代码中的功能开关来控制发布逻辑，是一种相对比较低成本和简单的发布方式。研发人员能够灵活定制和自助完成的发布方式。这种方式一般依赖于一个配置中心系统，固然若是没有，可使用简单的配置文件。

应用上线后，开关先不打开，只待一声令下，能够全量打开开关，也能够按照某种维度(公司ID，用户ID等)分批打开开关进行流量验证，若是有问题，则随时关闭开关。
这种方式的优点在于升级切换和回退速度很是快，并且相对于复杂的发布工具，成本较为低廉。可是也有很大的不足之处，就是开关自己也是代码，并且是与业务无关的代码，对代码的侵入性较高，也必须按期清理老版本的逻辑，使得维护成本增长。

3 小结

这篇文章介绍了目前经常使用的一些发布方式，每种发布方式各有其优缺点。但其实在真正实践过程当中这些发布方式每每是根据具体的状况来结合使用的。主要能够经过升级回退速度、成本、对用户影响三个方面来考虑。 好比在我最开始的小型公司里，公司业务小，服务器资源也不足，甚至连最基础的负载均衡服务器都没有，这个时候咱们的发布一般是选择一个流量小的时候进行蛮力发布的，这个时候也许会对用户形成短暂的影响，但那个时候的咱们是没有人力物力财力......去搞后面那些复杂的方式的。 然后来的某厂里有着充足的资源，咱们有着多服务器群组，各类强大的发布工具......，一般咱们是结合具体场景来选择合适的发布方式的。最经常使用的其中就是金丝雀发布和滚动发布。而在有些时候因为集群中的请求是随机分发的你并不能保证同一个用户的上一个请求和下一个请求还在同一个服务器上，这时若是旧的版本不能兼容新的版本的时候，若是是在业务流量低的时候，咱们会考虑采用蓝绿部署的方式，若是在流量高峰期则会采用红黑发布的方式来避免服务器过载。 而针对一些特殊的功能也常常会采用滚动发布+功能功能开关的方式。新版本发上去以后，逐步打开开关验证。 总之，各类发布方式的本质目的都是为了提升咱们的发布效率，保持系统可用性，减小对用户的影响可以让用户平滑的过渡到新的版本。