前面几期我们分享了一些线下环境建设方面的内容,我们可以感受到,整个线下环境的建设是比较复杂的,那经过线下环境的验证,是不是就可以直接发布到线上生产环境了呢?答案同样是否定的,由线下正式交付到线上之前,我们仍然会做很多的验证和稳定性保障工作。
今天我们就一起来看一下线上环境是如何建设的。
下面,我们就生产环境、Beta 环境、预发环境、办公网生产环境这四种线上环境分别展开讨论。
生产环境
我们还是进入到现实场景中。最初我们的软件代码开发完成后,就可以发布到生产环境,也就是可以正式接入用户流量,承载真实的业务场景。
在最早期,我们业务复杂度不高,用户量不大,集群规模小,软件架构也相对简单。在这种情况下,其实这一个环境就足够了,真有问题,也可以快速回退掉。退一步讲,即使有问题也回退不了的话,影响范围也有限。
所以,这个时候,线上环境 = 生产环境。
我们知道,随着业务量增大和业务复杂度升高,我们的软件架构、部署模式、集群规模等等也相应变得复杂和庞大起来。同时,业务产品在用户和业界的影响力也在变得越来越大。
这个时候,任何一个小的变更或一个不起眼的小问题,都有可能导致非常严重的故障,从而造成公司资损甚至是恶劣的产品口碑影响。
比如,我们假想一下,如果国内某个大型电商平台不可用,或者某即时通讯软件不可用,会造成何等严重的后果,就不难想象了。
所以,这时就需要我们非常严肃而谨慎地应对生产环境的变更。
我想你可能跟我一样,会想到一个问题:就是我们不是已经在线下环境经过了很多轮不同形式的验证测试环节,为什么到了生产环境还会有验证不到的严重问题?
这里涉及一个用户和业务场景的概念,就是线下和线上的用户场景是完全不同的:线下是我们模拟出来的,线上却是真实的用户场景,这两者之间会存在巨大的差异,有差异,系统的表现状况就会不一样。
所以线下我们只能尽可能地确保业务功能和业务流程是正常的,但是没法百分之百模拟线上场景,特别是一些异常特殊场景方面。这一点后面的文章我们还会再分享,这篇文章我们只要知道存在差异即可。
这个时候,我们的第一个思路就是:即使有影响,也要把它控制在小范围内,或者是在萌芽状态时就发现。这样就可以提前处理,而不是全量发布到生产环境后才发现问题,影响全局。
所以,线上的第二个环境,Beta 环境就产生了。这个环境也可以叫作灰度环境,包括我们常提到的金丝雀发布,也是基于这个环境的发布模式。
Beta 环境
这个环境的建设,我们简单理解,就是从生产环境的集群中,再建立一个独立集群。看过我们之前介绍 CMDB 应用和服务分组的文章的读者应该不难理解,针对应用,就是再建立一个分组,独立出一个集群出来,但是这个集群中服务器数量 1-2 台即可,主要还是针对小规模真实业务流量。如何做到小规模呢?这就要在负载均衡策略上做工作了,主要两种方式:
调用 RPC,在服务化框架的复杂均衡策略中,将其权重或者流量配比降低;
调用 HTTP,在四层 VIP 或者七层权重上,将权重降低。
这个环境同样不会全量建设,通常只针对核心应用,比如交易链路上的各个应用。同时,除了承担的流量比重不同外,其他与生产环境的应用没有任何差别。
后面的部署发布环节,我们会看到,针对核心应用,必须要经过 Beta 发布环节,才允许正式发布到生产环境。
有了 Beta 环境之后,上面说到的影响范围的问题从一定程度上就可控了。但是在 Beta 环境上我们仍然会有两个问题无法很好的解决:
影响范围再可控,其实也已经影响到了部分真实用户,特别是当访问量特别大的时候,即使是千分之一、万分之一,也是不小的数量。
之前经历的线下环境毕竟是一个模拟环境,一方面,在数据规模、分布特点、多样性以及真实性方面,跟生产环境的数据场景还是会有很大的区别,所以有很多跟业务逻辑相关性不大,但是跟数据相关性特别强的场景功能,在线下环境就很难验证出来;另一方面,对于一些第三方的系统,特别是商家、支付和物流这样的体系,在线下环境极有可能是 Mock 出来的,所以验证的时候并不能代表真实场景,但是等到了线上再去发现问题,就可能就会造成真实的业务影响。业务访问失败可以重试,但是造成商家真实的销售数据错误,或者用户真实的支付资金错误,这样就会非常麻烦了。所以,从线下直接进入 Beta 环境,还是会给生产环境,特别是数据层面造成影响。
当业务复杂度和系统规模发展到一定程度后,上面两个问题就会非常突出,所以单纯的 Beta 环境是无法满足要求的。