issueBlog icon indicating copy to clipboard operation
issueBlog copied to clipboard
verified publisher icon sdcuike

灰度发布

Open sdcuike opened this issue 10 years ago • 0 comments

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

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

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

  1. 期望达到什么效果 不管是那种变更，我们都希望特定的请求能够路由到我们的变更版本（灰度版本），以便观察和验证。
  2. 灰度策略 其实就是什么的请求应该路由到我们的灰度版本（灰度机器）上来。这个往往是业务强相关的。比如对于API来说，一般有如下几个需求：

特定用户（比如测试帐号） 特定的App（比如测试app或者合作App） 特定的模块、接口（只有某些接口需要灰度，这种一般是API Container的修改，拿一些不是很重要的API做灰度测试。） 特定的机器（某些请求IP转发到灰度机） 4. 灰度方案探讨 方案一、代码级别通过对约定好的flag判断，动态的进行新老切换——Amazon的做法 实现：

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

优点

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

对代码有倾入性。 分支逻辑，带来复杂性。 这种方式笔者曾经应用过，就是在阿里的时候把商品的数据库从Oracle切换到MySql，使用了一个状态变量进行控制。从而打到平滑迁移的效果。

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

优点

简单 缺点

浪费一台机器（这个可以预先发布完成之后投入正式环境，预发布的时候从nginx摘除，不过需要运维支持。） 不够灵活 只能针对接入层机器，IDL服务灰度需要另外考虑。 方案三、SET部署

  1. 按照业务隔离部署 比如现在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

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

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

优点

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

灰度的粒度取决于隔离部署的粒度，一般会偏大。 相对于集中部署比较浪费机器。 各个业务线版本可能不一致，不利于统一管理。 有一定的实现和部署成本 方案四、动态路由 方法：采用一个可以灵活配置的灰度策略，影响Load Balance的行为，让其根据灰度策略，返回灰度服务的IP和端口。

适合与后台IDL的服务灰度。

优点

灵活，可控。 缺点

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

灰度发布一般有三种方式 nginx+lua，nginx根据cookie分流，nginx 根据权重来分配： nginx+lua根据来访者ip地址区分，由于公司出口是一个ip地址，会出现访问网站要么都是老版，要么都是新版，采用这种方式并不适合 nginx 根据权重来分配，实现很简单，也可以尝试 nginx根据cookie分流，灰度发布基于用户才更合理

https://github.com/pintsized/ledge

https://github.com/moonbingbing

http://blog.csdn.net/dyllove98/article/details/9673825

http://jinnianshilongnian.iteye.com/blog/2186448

http://jinnianshilongnian.iteye.com/blog/2190344 跟我学Nginx+Lua开发目录贴

http://www.codesec.net/view/198476.html

http://www.poluoluo.com/server/201310/247001.html Nginx+Lua+Redis构建高并发Web应用

http://www.open-open.com/lib/view/open1439889185239.html

https://github.com/SinaMSRE/ABTestingGateway http://www.oschina.net/translate/augment-your-api-without-touching-it

http://wiki.jikexueyuan.com/project/nginx-lua/

http://luajit.org/luajit.html

http://luabinaries.sourceforge.net/

http://www.lua.org/manual/5.1/manual.html

http://luadist.org/

http://rudamoura.com/luaonmacosx.html

https://www.gitbook.com/book/moonbingbing/openresty-best-practices/details

http://outofmemory.cn/code-snippet/14396/nginx-and-lua

https://github.com/openresty/lua-nginx-module

https://github.com/SinaMSRE/ABTestingGateway

http://stackoverflow.com/questions/18356489/installing-openssl-on-os-x

http://mac-dev-env.patrickbougie.com/openssl/

http://apple.stackexchange.com/questions/126830/how-to-upgrade-openssl-in-os-x mac安装ssl nix需要

http://mikeferrier.com/2011/05/14/my-beautiful-dark-twisted-reverse-proxy-LRU-cache/

http://sosedoff.com/2012/06/11/dynamic-nginx-upstreams-with-lua-and-redis.html

http://getawesomeness.com/get/openresty

http://dev.af83.com/2013/08/13/nginx-redis-lua.html

http://www.slideshare.net/VictorWelling/nginx-lua-43850373

lua 学习

http://tylerneylon.com/a/learn-lua/

lud ide https://studio.zerobrane.com/download.html

http://lua-users.org/wiki/TutorialDirectory

http://www.tutorialspoint.com/lua/

http://www.csdn123.com/html/mycsdn20140110/56/561927ea09bad27cb9558b75119c2609.html

http://www.staticshin.com/programming/definitely-an-open-resty-guide/

https://github.com/eBay/fabio

https://www.nginx.com/resources/wiki/modules/lua/ https://github.com/idevz/vanilla https://github.com/pintsized/lua-resty-http

开源的

https://github.com/sourcelair/ceryx

https://github.com/JamesPan/orz-ops

http://sosedoff.com/2012/06/11/dynamic-nginx-upstreams-with-lua-and-redis.html

http://httpd.apache.org/docs/trunk/mod/mod_lua.html

http://openresty.org/#DynamicRoutingBasedOnRedis

https://www.textrazor.com/blog/2013/03/scaling-textrazor-in-the-cloud-with-nginx-and-lua.html

https://t37.net/the-good-the-bad-and-the-ugly-of-virtual-hosting-with-nginx.html

https://github.com/openresty/lua-resty-core/issues/16 balancer_by_lua*

https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/balancer.md

http://tengine.taobao.org/book/

http://blog.csdn.net/zhangskd/article/details/50242241 Nginx的负载均衡 - 最少连接 (least_conn)

https://github.com/mindreframer/nginx-lua-stuff

https://github.com/bungle/awesome-resty

https://www.nginx.com/resources/wiki/modules/lua/

http://www.lua.org/gems/ http://www.lua.org/gems/sample.pdf

lua其它框架

https://github.com/luvit

sdcuike avatar Dec 08 '15 13:12 sdcuike