在互联网软件的生产过程中有一环是必不可少的，那便是部署、发布。通过把代码部署在特定环境中，再对外向用户发布新功能。早期的时候互联网刚刚发展起来，涌入互联网的网民还比较少，服务器资源也比较昂贵、紧张，这时候的发布一般就是把旧版本下掉，然后再部署新版本，在发布期间，服务不可用。这样的体验其实不太好，因为发布期间我在这个应用上无法进行任何操作。

但随着互联网的快速发展，尤其是云计算起来之后，服务器资源变得不再昂贵了，互联网企业们也更加的看重用户体验，要求7*24小时不停服提供服务，于是发布的方式也在演变，典型的发布方式包含蓝绿发布、滚动发布、灰度发布（金丝雀发布）。我们今天就来看看这些发布方式吧～

·蓝绿发布

在蓝绿发布中，部署服务的机器包含绿组机器、蓝组机器。在新版本上线之前，先将旧版本的代码部署在绿组机器上，然后把流量指向绿组机器，之后再把新版本代码部署在蓝组机器上，把指向绿组机器的流量再指回蓝组，发布过程如果出现问题，则回滚绿组机器或蓝组机器即可。在整个发布过程中，应用一直在对外提供服务，因此用户是无感的。蓝绿发布的缺点就是资源会有点浪费，在开始发布之前，需要申请出等量的机器进行服务部署。

比如我们去餐馆吃饭，点了红烧排骨、土豆牛腩、西红柿蛋汤，先上了红烧排骨。在上新的菜土豆牛腩时，传统发布是直接把红烧排骨下掉，换上土豆牛腩。蓝绿发布则是保留红烧排骨，并同时把土豆牛腩端上来，让我们都去吃土豆牛腩的同时，再把红烧排骨下掉。在整个就餐的过程中，蓝绿方式让我们一直保持有菜可吃。

·滚动发布

在滚动发布过程中，我们是把原有部署服务的机器挑选出来1台或多台机器在这些机器上部署新的版本，部署成功后，又挑剩下的机器继续部署新版本，如此循环往复，直到所有的机器都部署了最新的版本。这种部署方式的好处首先是不需要申请新的服务资源、节省成本，其次是在发布过程中并非所有的用户都会受影响、一定程度保障了用户体验。但是也存在一些缺点，如果发布过程出现了问题，回滚很麻烦，要逐台找到机器并且回滚。

滚动发布的方式就像是我们在餐馆吃饭时，上了红烧排骨之后、又上土豆牛腩、西红柿蛋汤，在整个上菜的过程中，有的人吃到的是红烧排骨，有的人是土豆牛腩，直到服务员确认所有的土豆牛腩都上齐后，才会把红烧排骨下掉。如果服务员上错菜了，那就呵呵了，需要去找到上错菜的桌子，一盘盘的撤下，用户会很莫名其妙，服务员也会很辛苦。

·灰度发布

灰度发布也称为金丝雀发布，是在互联网中比较常用的一种发布方式，尤其是C端产品。ABtest就是一种灰度发布方式，在新产品上线之后，让一部分用户用A，剩下的用户用B，如果用户对A没有什么反对意见，则把剩下的用户都切换A版本。

在灰度发布中，我们先把要发布的代码版本准备好，然后选择一台或一组服务器，切除掉流量（在负载均衡中把该台或该组机器去掉），在该组机器部署新的版本，然后再在负载均衡中把该台或该组机器加上，这时候就会有用户访问了，如果用户使用都还不错，则把剩下的机器按照刚刚的流程进行操作即可，直到线上的所有服务都是使用新版本。

灰度发布的方式就像是我们在餐馆吃饭时，上了红烧排骨之后，服务员先选择某几桌用户把红烧排骨下掉、上土豆牛腩看看用户反馈，如果都吃的还不错，就把剩下的所有餐桌的红烧排骨下掉、换成土豆牛腩。

事实上，蓝绿发布、滚动发布、灰度发布本质上还是一种部署行为，只不过是由于业务增加了对外周知用户的环节，因此变成了发布。从部署这个角度看，它们不仅是在生产环境可用，在测试环境也可以使用。再从DevOps持续集成交付角度看，开发的代码不断集成到代码库，也需要不断的部署在测试环境、生产环境中，因此它们仍然发挥着最大的价值。作为技术人员，可结合自己的企业情况，选择最合适的发布策略～