简述四种线上环境建设思路

发布时间 2023-12-18 14:45:54作者: 诗里刻画的影子

转载于:https://blog.csdn.net/key_3_feng/article/details/129759225

内容来源于极客时间《赵成的运维体系管理课》

由线下正式交付到线上之前,我们仍然会做很多的验证和稳定性保障工作。就生产环境、 灰度环境、预发环境、办公网生产环境这四种线上环境的建设进行分析。

1、生产环境
随着业务量增大和业务复杂度升高,我们的软件架构、部署模式、集群规模等等也相应变得复杂和庞大起来。同时,业务产品在用户和业界的影响力也在变得越来越大。

这个时候,任何一个小的变更或一个不起眼的小问题,都有可能导致非常严重的故障,从而造成公司资损甚至是恶劣的产品口碑影响。

这里涉及一个用户和业务场景的概念,就是线下和线上的用户场景是完全不同的:线下是我们模拟出来的,线上却是真实的用户场景,这两者之间会存在巨大的差异,有差异,系统的表现状况就会不一样。

线下我们只能尽可能地确保业务功能和业务流程是正常的,但是没法百分之百模拟线上场景,特别是一些异常特殊场景方面。

即使有影响,也要把它控制在小范围内,或者是在萌芽状态时就发现。这样就可以提前处理,而不是全量发布到生产环境后才发现问题,影响全局。

2、灰度环境
针对应用,就是再建立一个分组,独立出一个集群出来,但是这个集群中服务器数量 1-2 台即可,主要还是针对小规模真实业务流量。如何做到小规模呢?这就要在负载均衡策略上做工作了,主要两种方式:

调用 RPC,在服务化框架的复杂均衡策略中,将其权重或者流量配比降低;
调用 HTTP,在四层 VIP 或者七层权重上,将权重降低。
这个环境同样不会全量建设,通常只针对核心应用,比如交易链路上的各个应用。同时,除了承担的流量比重不同外,其他与生产环境的应用没有任何差别。针对核心应用,必须要经过灰度发布环节,才允许正式发布到生产环境。

但是在灰度环境上我们仍然会有两个问题无法很好的解决:

影响范围再可控,其实也已经影响到了部分真实用户,特别是当访问量特别大的时候,即使是千分之一、万分之一,也是不小的数量。
之前经历的线下环境毕竟是一个模拟环境,一方面,在数据规模、分布特点、多样性以及真实性方面,跟生产环境的数据场景还是会有很大的区别,所以有很多跟业务逻辑相关性不大,但是跟数据相关性特别强的场景功能,在线下环境就很难验证出来;另一方面,对于一些第三方的系统,特别是商家、支付和物流这样的体系,在线下环境极有可能是 Mock 出来的,所以验证的时候并不能代表真实场景,但是等到了线上再去发现问题,就可能就会造成真实的业务影响。业务访问失败可以重试,但是造成商家真实的销售数据错误,或者用户真实的支付资金错误,这样就会非常麻烦了。所以,从线下直接进入 灰度环境,还是会给生产环境,特别是数据层面造成影响。
当业务复杂度和系统规模发展到一定程度后,上面两个问题就会非常突出,所以单纯的灰度环境是无法满足要求的。

3、预发环境
预发环境在建设上,有以下几个规则要求:

状态基础服务共用,如 DB、KV、文件存储以及搜索类的数据服务。这里基本就是真实的生产环境的基础了,我们上述的问题在这个基础上就可以很好地解决了。除有状态服务外,其他都需要在预发环境上进行全套建设,但是资源使用上,一般是一个应用部署一个实例即可,所以规模比生产环境要小很多。
网络隔离上,预发环境做独立网段的划分,不承担线上真实流量,独占一个 B 段,同时在网络上进行逻辑隔离。业务调用必须本环境内闭环,预发不允许跨环境进行应用服务调用,如预发应用调用生产环境应用,反之亦然。
要保证一定的稳定性。预发环节就是基于线上真实环境进行功能和业务流程的最终验证,所以对于版本质量要求是要高于线下环境,所以不允许反复频繁地变更部署,出现异常或警告也必须要以较高优先级处理。
预发环境正式使用后的另一用途,就是在生产环境出现问题,但是线下复现不了时,就可以在预发环境上复现,这样对于问题定位会带来很大帮助。如果是在生产环境上做调试和问题定位,有时候会影响到正常用户访问,但是预发环境的影响就可控一些。

4、办公网生产环境
办公网生产环境建设的技术方案与预发环境一致,但是在要求上又有所不同:

访问用户是办公网内的员工用户,所以必须连接指定的办公网 wifi 接入点。于是,员工会通过 wifi 被劫持到这个环境上,这时用户就可以在这个环境中提前体验新版本软件的功能。
稳定性要求上,办公网生产环境相当于生产环境,虽然不是外部用户访问,但是一个公司内的员工也算是真实用户了,他们发现的问题等同于线上问题,但是级别上会降低一级处理。
建设规模上,公司有上千、上万名员工,他们的频繁访问行为,也产生一定的业务量,所以综合上述稳定性要求,办公网生产环境在规模上会根据应用容量进行相应的资源分配,这里至少每个应用应该以两个实例做冗余。所以这个环境,从建设规模和稳定性要求上,就相当于一个小号的生产环境,所以我们内部又把它简称为“小蘑菇”环境。
环境建设是一项异常繁琐复杂的工作,这些工作不是一蹴而就,而是根据实际的场景和问题催生出来的,所以是个逐步渐进的过程。而且,因为不同的业务类型和场景,以及业务发展的不同阶段,场景和问题可能都是不一样的,而且其建设需求也不一样,所以在实际操作中,一定要切合具体情况进行建设。

环境管理是复杂的,多一个环境就多一份管理成本。所以环境并不是越多越好,反而是越精简越好。这个时候也需要各位读者能够有一定的 ROI 评估,毕竟能带来最大价值的投入才是有意义的,而不是盲目地建设和投入。