全链路灰度方案设计

流量染色

服务规模越来越大，增加速度越来越快，需求指数性增加，大家都需要一个环境。比如一个集群一千个容器，如果三个小组各开发一个项目，想并行开发，每个人都需要一个环境，一下子需要三千个容器。这时候就需要中间件的灰度发布和流量染色的能力。

在最外层的网关上，可以做两个环境之间流量的分发，以及在微服务的Agent里面也可以做一个分发。最终，我们会有一个基准环境，就是Master对应的环境。

两个小组，一组开发了五个服务，另外一组开发了六个服务，他们部署的时候不需要一千个全部布一遍，只需要布五个，布六个。在请求调用的时候，从这五个里面互相调，不在这五个里面，在基准环境调，另外六个也是。这样就把三千个变成一千零十几个，环境大幅度减少。

这个时候环境的合并怎么办？环境合并和代码合并逻辑一致，统一在发布平台管理，谁后合并谁负责Merge。这是我们的一个效果，我们节省了非常多的机器。

QA组测试v1.2和v2.0链路
- v2.0 + v1.2链路
v1.1组仅关注v1.1的版本开发
- v1.1 + master链路
v1.2组在v1.1开发新版srv-2服务
- v1.2 + v1.1 + master链路
v2.0组仅关注v2.0的版本开发
- v2.0 + master链路

灰度发布

有了流量染色功能，就可以做线上的灰度发布。这里我们会有几个环境，一个是预发类的环境，一个是小流量环境，还有一个主流的环境，测试的时候是可以进行染色。

我们以一天的整个开发周期举例子，每天早上初始化预发环境和小流量环境＞＞开启引流，进入持续发布周期＞＞代码发布到预发环境进行回归，预发环境为单节点部署＞＞预发通过后发布到小流量环境，小流量环境三节点部署，滚动发布＞＞小流量环境，开发测试及时跟进，观察异常情况，一旦碰到问题，第一时间关闭流量入口。相关问题定位debug可以在预发环境上进行＞＞所有发布到小流量环境的版本合集，通过一个晚高峰的检测后，发布到线上环境。第二天同样是做此循环，每天都是这样的发布模式。

普通用户
- Pro链路
灰度测试用户
- Gray + Pro链路
QA
- Pre + Pro链路

多机房染色

有了流量染色以后，还可以得到单元化和多机房的染色。如果我们做高可用，至少需要两个机房，那么就存在一个问题，当一个机房完全挂了怎么办？微服务框架可以把它引流到另外一个机房。服务请求之后，还应该回来，因为应该本机房优先，毕竟本机房的容量大得多。所以我们建议整个部署模式，总分总的部署模式。

首先第一个总，要有统一的发布平台，无论发布到哪个Kubernetes，都应该通过一个平台。其次，你应该有一个多Kubernetes统一的管理，有多个机房，就有多个Kubernetes，我们并不建议跨机房。然后，我们建议应用层要有统一的视图，即使Kubernetes出现了问题，应用层可以把流量切到另外一个环境。就是这样一个总分总的模式。

另外Kubernetes也面临升级的问题，它更新比较快，经常升级。虽然业界有各种平滑的最佳实践，但是很难保证它升级的时候不出事。一旦Kubernetes出现状况，你也不想停里面的应用，可以采用分流的方式。