Kubernetes灰度发布服务路由设计(一)

  • A+
所属分类:Kubernetes

前言

在应用发布与产品迭代中,经常采用灰度发布或分批发布的方式来控制上线风险。常见的发布方式,包括蓝绿部署,灰度发布,滚动部署,A/B测试。

什么是蓝绿发布

蓝绿部署中,一共有两套系统:一套是正在提供服务系统,标记为“绿色”;另一套是准备发布的系统,标记为“蓝色”。两套系统都是功能完善的,并且正在运行的系统,只是系统版本和对外服务情况不同。最初,没有任何系统,没有蓝绿之分。然后,第一套系统开发完成,直接上线,这个过程只有一个系统,也没有蓝绿之分。后来,开发了新版本,要用新版本替换线上的旧版本,在线上的系统之外,搭建了一个使用新版本代码的全新系统。 这时候,一共有两套系统在运行,正在对外提供服务的老系统是绿色系统,新部署的系统是蓝色系统。

蓝色系统不对外提供服务,用来做啥?

用来做发布前测试,测试过程中发现任何问题,可以直接在蓝色系统上修改,不干扰用户正在使用的系统。(注意,两套系统没有耦合的时候才能百分百保证不干扰)

蓝色系统经过反复的测试、修改、验证,确定达到上线标准之后,直接将用户切换到蓝色系统:切换后的一段时间内,依旧是蓝绿两套系统并存,但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统(新系统)工作状态,如果出现问题,直接切换回绿色系统。

当确信对外提供服务的蓝色系统工作正常,不对外提供服务的绿色系统已经不再需要的时候,蓝色系统正式成为对外提供服务系统,成为新的绿色系统。 原先的绿色系统可以销毁,将资源释放出来,用于部署下一个蓝色系统。

蓝绿部署只是上线策略中的一种,它不是可以应对所有情况的万能方案。 蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的,如果目标系统相当复杂,那么如何切换、两套系统的数据是否需要以及如何同步等,都需要仔细考虑。

什么是灰度发布

灰度发布,又叫金丝雀发布,是指在原有部署版本可用的情况下,同时部署一个新版本应用作为金丝雀(金丝雀对瓦斯极为敏感,因此矿工会携带金丝雀进入矿井,以检测瓦斯浓度是否符合安全标准),用来测试新版本的性能和表现,在保证整体系统稳定的情况下尽早暴露问题。

蓝绿发布和灰度发布区别

蓝绿部署是准备两套系统,在两套系统之间进行切换,金丝雀策略是只有一套系统,逐渐替换这套系统。譬如说,目标系统是一组无状态的Web服务器,但是数量非常多,假设有一万台。这时候,蓝绿部署就不能用了,因为你不可能申请一万台服务器专门用来部署蓝色系统(在蓝绿部署的定义中,蓝色的系统要能够承接所有访问)。

可以想到的一个方法是:

只准备几台服务器,在上面部署新版本的系统并测试验证。测试通过之后,担心出现意外,还不敢立即更新所有的服务器。 先将线上的一万台服务器中的10台更新为最新的系统,然后观察验证。确认没有异常之后,再将剩余的所有服务器更新。这个方法就是金丝雀发布。实际操作中还可以做更多控制,譬如说,给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数,然后逐渐提高权重、增加请求数。这个控制叫做“流量切分”,既可以用于金丝雀发布,也可以用于后面的A/B测试。

蓝绿部署和金丝雀发布是两种发布策略,都不是万能的。有时候两者都可以使用,有时候只能用其中一种。

上面的例子中可以用金丝雀,不能用蓝绿,那么什么时候可以用蓝绿,不能用金丝雀呢?整个系统只有一台服务器的时候。

什么是A/B测试

首先需要明确的是,A/B测试和蓝绿部署以及金丝雀,完全是两回事。蓝绿部署和金丝雀是发布策略,目标是确保新上线的系统稳定,关注的是新系统的BUG、隐患。

A/B测试是效果测试,同一时间有多个版本的服务对外服务,这些服务都是经过足够测试,达到了上线标准的服务,有差异但是没有新旧之分(它们上线时可能采用了蓝绿部署的方式)。

A/B测试关注的是不同版本的服务的实际效果,譬如说转化率、订单情况等。

A/B测试时,线上同时运行多个版本的服务,这些服务通常会有一些体验上的差异,譬如说页面样式、颜色、操作流程不同。相关人员通过分析各个版本服务的实际效果,选出效果最好的版本。

JAVA灰度方案

通过Ingress判断客户端Header,请求头中满足正则匹配app_ver=10038的请求,会被路由至后端fgateway-01和show-h5-01

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/server-snippet: |
      location /inner/gateway/getAesKey  {
          allow 127.0.0.1;
          deny all;
      }

    nginx.ingress.kubernetes.io/service-match: 'fgateway-01: header("app_ver", "100040")'
    nginx.ingress.kubernetes.io/service-weight: ''
  creationTimestamp: '2019-05-17T13:44:43Z'
  generation: 4
  name: test
  namespace: test

spec:
  rules:
    - host: test.xxx.com
      http:
        paths:
          - backend:
              serviceName: show-h5
              servicePort: 80
            path: /h5
    - host: test.xxx.com
      http:
        paths:
          - backend:
              serviceName: show-h5
              servicePort: 80
            path: /special
    - host: test.xxx.com
      http:
        paths:
          - backend:
              serviceName: fgateway
              servicePort: 80
            path: /
    - host: test.xxx.com
      http:
        paths:
          - backend:
              serviceName: show-pay
              servicePort: 80
            path: /h8

H5灰度方案

h5灰度与java服务类似,通过请求头app-ver来控制用户请求到不同版本的html,同时不同版本的html引用oss上不同目录下的静态文件(css,js,image,font ...),h5项目构建时可以修改html文件内静态资源的引用路径,该任务构建工具一般都是支持的。

请求头需要由app提供,比如WebView在请求页面时设置app-ver头信息,要注意拦截app内部各类跳转以及时设置app-ver头信息

js进行ajax请求要设置app-ver头信息,该值调用原生提供的方法来获取,不可写死到js内

该方案可以保证新app内访问h5页面都是新版,旧app内和app之外访问h5页面都是旧版

Kubernetes灰度发布服务路由设计(一)

参考

https://help.aliyun.com/document_detail/114499.html?spm=5176.10695662.1996646101.searchclickresult.3cd46f67l5Aj2v

YaLei

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: