灰度发布入门

为什么需要灰度发布？

我们的产品是个比较典型的互联网产品，产品升级采用“小步快跑”的方式，一般采用保持每周或每两周一次的发布频率，同时，每周会有数次bug上线。系统上线总是伴随着风险，系统重大bug的风险，新旧版本兼容的风险，用户使用习惯突然改变而造成用户流失的风险等等，因为这些风险的存在，很多次上线都是通宵达旦、小心翼翼，RD和QA都搞提很疲惫。为了不再如此疲惫，同时避免重大事故的发生，我们决定采用灰度发布的策略，其主要思想就是化大为小，逐渐发布，将风险引起的影响控制在最小范围。

如何进行灰度发布？

1, 首先，我们将系统分成两个集群，集群A和集群B，每个集群有一个nginx,在两个集群之上，有一个大的集群C，也有一个nginx。
2, 在发布时，挑选在线用户比较小的时间点（如深夜），将小的集群B下线
3, 将在PL环境测试通过的程序包部署到下线的小集群B，使用独立的账套在线进行关键流程的测试（以避免污染真实用户的线上数据）。
4, 小集群测试通过之后，将小集群B上线，即，将小集群的nginx挂到大集群C的nginx下，上线试运行。
5-1，如果新上线的小集群B运行稳定，则将新程序包发到集群A，从而完成整个集群的发布。
5-2，如果新上线的小集群B有重大bug，则进行回滚。

以上步骤看起来很简单，但在实际落地过程中需要注意以下问题:
1，集群A与B在应用层完全隔离，dubbo注册中心zk与mq是非共享的，但在数据层是共享的。即db,redis,mongodb,redis这些资源是由集群A&B共享的。因此，数据的schema对于新旧版本需要兼容。
2，以上方案中，新旧版本是并行的，用户请求被随机分配到新旧版本的两个集群中。如果需要限定只有特定的用户才可以访问新系统（一般是铁粉用户），则需要增加路由规则。
对于简单的路由规则，可以通过nginx+lua脚本的方式实现, 可参考：
https://pingan.im/201503/nginx-lua-redis
对于复杂路由规则相关的方案请参考：
http://blog.csdn.net/hunter_1990s/article/details/43733349