精华内容
下载资源
问答
  • 灰度发布

    千次阅读 2016-11-20 09:39:54
    灰度发布

    灰度发布

    A/B test测试在Wikipedia中定义是Web设计(通常指用户体验)中用于区分两种网页设计对收益最大化目标(如点击率)效果支撑程度的一种试验手段”。主要用于比较两种设计的优劣程度。

    灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。
    A/B test就是一种灰度发布方式,让一部用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面 来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。

    为什么要灰度发布

    • 互联网服务变动频繁,发布周期短。速度与质量总是难以双全。
    • 灰度发布能降低发布风险,减少影响范围。
    • 降低对测试的依赖,减少线下自测的数据构造成本。
    • 方便集中监控日志,全量发布由于各层负载均衡的作用,很难跟踪一条完整的调用链路。
    • 可以灰度测试帐号,测试账户通过之后再灰度真实用户帐号,进一步降低发布的风险和影响。
    • 方便回滚。

    不能靠灰度发布解决的问题

    需要强调的是:上文所说的“可以容忍的影响”必须是可恢复的,比如API无法调用一段时间,但是修复之后,就可以成功调用。而永久性地丢失或者破坏用户数据(比如商品信息、订单信息等),则是不能容忍的。因此,互联网企业的架构师有责任通过设计完善的后备措施(比如用户数据的定期备份、写操作的业务流水日志等),在生产系统错乱导致丢失用户数据的情况下,仍能够通过人工干预,根据历史记录(备份数据、流水日志等),把丢失的用户数据修复至不久之前(比如一小时前至一周前)的状态。

    TIPS 先灰度测试帐号的灰度策略,可以降低破坏或者丢失真实用户的数据的风险。

    期望达到什么效果

    不管是那种变更,我们都希望特定的请求能够路由到我们的变更版本(灰度版本),以便观察和验证。

    灰度策略

    其实就是什么的请求应该路由到我们的灰度版本(灰度机器)上来。这个往往是业务强相关的。比如对于API来说,一般有如下几个需求:

    • 特定用户(比如测试帐号)
    • 特定的App(比如测试app或者合作App)
    • 特定的模块、接口(只有某些接口需要灰度,这种一般是API Container的修改,拿一些不是很重要的API做灰度测试。)
    • 特定的机器(某些请求IP转发到灰度机)

    灰度方案探讨

    方案一 代码级别通过对约定好的flag判断,动态的进行新老切换——Amazon的做法

    实现:
    在代码中埋开关,做if-else判断,对于需要灰度的机器,设置开关为on,否则为off。每次版本发布都是有两个版本。

    优点
    快速回滚,不需要重新发布和重启系统。

    缺点
    对代码有侵入。
    分支逻辑,带来复杂性。

    方案二 预发布机——Alibaba的做法

    其实这个不是真正意义上的灰度。因为这个预先发布机器是内部IP,没有对外服务的。需要绑定域名进行验证。但是数据是完全的线上。所以本质上是灰度某些特定用户(可以访问灰度机器的用户,内部测试用户)的一种简单做法。其实API这边也有类似的做法,就是我们的Gamma环境,而且我们还提供了Gamma机器的域名,方便外部合作用户配合测试。

    优点
    简单

    缺点
    - 浪费一台机器(这个可以预先发布完成之后投入正式环境,预发布的时候从nginx摘除,不过需要运维支持。)
    - 不够灵活
    只能针对接入层机器,IDL服务灰度需要另外考虑。

    方案三 SET部署

    按照业务隔离部署

    比如现在API Container的做法,部署的粒度可以到API级别,前端根据nginx进行转发。比如:
    - 微购物 API Container: api.weigou.qq.com
    - 拍拍 API Container:api.paipai.com
    - 易迅 API Container: api.yixun.com
    - 网购 API Container:api.buy.qq.com

    上面是大业务级别的隔离部署。还可以进一步细化到模块级别,比如虚拟服务电商的API,是挂在拍拍下面的一个子业务模块,但是由于他们接入微信之后,访问量大增,为了避免影响拍拍其他业务,也为了避免受其他业务影响,API这里是给他们单独部署了两台机器,nginx配置一下就可以将针对虚拟的API访问引流过来了:

    虚拟API Container:http://api.paipai.com/v2/virbiz

    这样,我们在发布一个版本的时候,可以先选择业务量最小的易迅进行发布,观察没有问题再全量其他平台。

    按照用户隔离部署

    这个对于开放平台来说不是很适合,不过对于SNS这种应用场景就很合适了。比如QQ系统,按照用户号码段分为若干个set,每个set包含连续1亿个号码的用户。假设现在最新的QQ号码接近10亿,则总共有10个set(Set 1到Set 10)。这样每次可以选择其中一个SET进行发布,而且高位QQ往往是不是很重要的用户,所以会先发布SET10。

    优点
    隔离部署,各个业务线影响最小。自动支持灰度发布。

    缺点

    • 灰度的粒度取决于隔离部署的粒度,一般会偏大。
    • 相对于集中部署比较浪费机器。
    • 各个业务线版本可能不一致,不利于统一管理。
    • 有一定的实现和部署成本

    方案四 动态路由

    方法:采用一个可以灵活配置的灰度策略,影响Load Balance的行为,让其根据灰度策略,返回灰度服务的IP和端口。

    优点
    灵活,可控。

    缺点
    - 现在的配置中心和L5本身没有考虑指定路由策略,且不具有扩展性,需要在其外边开发。
    - API的元数据来源比较分散,目前 API和IDL元数据,API等级和频率限制 分布在不同的数据源,现在需要增加一个 灰度路由 数据源。

    最终方案

    • API Container采用预发布机模式灰度

    • IDL服务采用动态路由模式,不过只能支持uin或者IP来源。因为没有appId的概念。


    http://blog.arganzheng.me/posts/gray-release.html

    展开全文

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,033
精华内容 1,213
关键字:

灰度发布