蓝绿部署-解决99%的发布问题(APISIX)

如何使用APISIX网关进行蓝绿部署

背景

名人名言：99%的问题都是发布导致的。

无论在测试环境测试的多么充分，在上线正式环境时依然有可能发生问题。

目前我们发布线上新版本后发现问题主要有两种途径：

1. 灰度发布。一次发布一部分机器，然后观察监控是否有异常
2. 线上验证。人工到线上通过app或接口进行测试，观察结果是否符合预期。

但这两种方式存在一定的问题，因为线上验证必须等到全量发布后才能进行，不然灰度期间无法预知请求会路由到哪台机器。一旦灰度期间监控发现不了问题，等到全量发布后线上验证不通过，此时受影响的必定是全部用户，风险很高。

那么，鱼(灰度发布)和熊掌(熊掌)能不能兼得？我们能不能在灰度期间就进行线上验证，从而提前发现问题，杜绝发布导致的事故？

答案是能。

蓝绿部署

在蓝绿发布过程中，有两套生产环境：蓝环境和绿环境。蓝色是当前版本并拥有实时流量，绿色是包含更新代码的环境。无论任何时候，只有一套环境有实时流量。 要发布一个新版本，需要先将代码部署到没有流量的环境中，这是执行最终测试的地方。当IT人员确认应用程序已经准备就绪，就会将所有流量都将路由到绿色环境。那么绿色环境就已经生效，并且执行发布。

在我们验证过程中，我们需要将验证人员的uid路由到指定的灰度机器上，其他用户的uid则路由到未更新的机器上，从而新版本不干扰正常用户，降低影响范围。

如何使用蓝绿部署

我们目前的路由方式有两种：

1. NGINX。
2. apisix网关

nginx是非常传统的代理软件，根据我们的业务特点进行路由难度很高，故不做调研。

网关是开源的APISIX，玩法比较丰富，功能比较强大，一些小公司一般会选择它。

下面介绍两种方案实现根据uid路由，从而实现蓝绿部署。

一、路由-高级匹配条件方案

此方式需要在网关新建一个接口的路由，并配置高级匹配条件

Step 1: 新建灰度上游信息

新建一个上游，节点信息填写灰度机器的IP信息。

Step 2: 修改原路由信息

此时要修改原先的路由。修改包括两部分：

1. 高级匹配条件填写信息和step3要相反，打开非开关
2. 上游服务修改。需要踢掉灰度机器的流量，如何踢流量请参考后续说明

Step 3: 新建路由，填写匹配条件

新建灰度接口的路由信息，注意：之前肯定有一个路由，此处是新建，不是修改。

高级匹配条件这里可以填写要路由到灰度机器的uid，支持uid列表。上游服务选择step1新建的上游。点击确认提交。

此时路由已经生效，175884的uid就会被路由到指定机器上，观察access日志也符合预期

二、路由-流量分割插件方案

此方案相对比较复杂，坑也比较多，优点是可拓展性相当高，虽然大部分特性都用不到。

Step 1: 新建灰度上游信息

此步骤和方案一step1一致，不再赘述，但需要记录下上游ID，后续配置要用到。

Step 2: 修改原路由信息

在插件配置这里选择traffic-split(流量分割)插件，点击启用，输入如下配置。

配置规则请参考： 匹配规则

这里需要注意的点：

1. 这里需要配置两个rule,后面一个是默认rule,即正常用户走的rule。
2. 上游ID就是step1的上游ID和原路由的上游id,一定要是字符串，int类型貌似有bug
3. 点击提交后，再次编辑会神奇发现刚提交的配置都不见了，不要像我一样怀疑人生，这是平台的bug，bug链接。
4. 匹配规则这里需要带“http_”前缀，带前缀才会从请求头里面进行匹配，apisix文档没提到这点。

点击提交后，效果如下：

配置模板

{
    "rules": [
        {
            "match": [
                        {
                            "vars": [["http_uid","==","175884"]]
                        }
                    ],
            "weighted_upstreams": [
                {
                    "upstream_id": "442749053659253914"
                }
            ]
        },
        {
            "match": [
                        {
                            "vars": []
                        }
                    ],
            "weighted_upstreams": [
                {
                    "upstream_id": "437680081112925035"
                }
            ]
        }
    ]
}

发布流程规范

Step 1: 踢流量

踢流量的方式取决于上游服务的配置方式。

nacos服务发现类型

如果你的原服务配置是nacos服务发现类型，如下图所示

那么你需要在阿里云上修改权重，将要发布的机器权重调为0，此后线上用户将不会路由到灰度机器

节点类型

如果原上游服务是直接配置的节点类型，如下图，那么直接修改要灰度的机器权重即可。

Step 2: 新建灰度环境

按照以上两种方式建立起灰度路由，将指定uid路由到要灰度的机器上。

个人感觉方案一要比方案二简单不容易出错，推荐方案一。

Step 3: 灰度发布

通过jenkins发布新版本到灰度机器上。

Step 4: 灰度验证

此时可进行验证，观察结果是否符合预期

Step 5: 回滚或继续发布

如果验证结果 符合预期，那么可继续发布其他机器。新建的灰度路由也可进行删除。

如果验证结果不符合预期，那么此时不会影响到正常用户，可选择回滚或发布修复版本到灰度机器上继续验证。

剩下的1%问题

如果灰度验证发布后，还是有bug。那么可能有以下原因：

1. 测试不充分。
2. 测试充分，但还是有未覆盖的小众场景。

测试不充分确实是人为的问题，后续需要多加注意。

如果是第二种情况，那么此时影响范围是可控的，无需惊慌，发布修复版本修复即可。