缘起：
今天介绍一下支撑可用性目标的一个实践，即灰度。
给客户交付需求过程，最担心的是交付需求时，系统问题导致不可用，宕机造成事故的情况出现。
造成事故的问题可能有很多，配置问题、代码问题、服务器问题等，任意环节都有可能出现的问题。
如何在这个过程中保证质量常规的方式可能是配置自动化、增加内建质量加强系统的稳定性、增加服务器冗余等等策略。
这些措施确实可以缓解事故出现的可能性，但不能彻底解决问题，特别是SAAS系统，上万客户如何保证使用的稳定是每个SAAS企业需要解决的问题。
既然无法保证没有问题，那就让问题出现时影响变得小一些，接受度可控一些，灰度机制是一个不错的选择。
行业灰度机制：
行业内提得比较多的灰度机制有蓝绿部署和金丝雀部署。
蓝绿部署即使用2套隔离环境，发布时更新到蓝环境，没问题则直接切换为正式环境，有问题时切换到绿环境进行回滚操作。
蓝绿部署优点是复杂度低，成本高。
拿到软件领域，即在一套环境中通过先部署部分机器集群，做流量切换进行部分验证，如果没问题，则做稳步的更新和流量切换，直至100%完成。
金丝雀优点是复杂度高，成本低。
我们的选择：
选择的标准，主要还是复杂度和成本。
整体来看，没有选择任何一种，而是一个混合体，更准确地说不是蓝绿部署的简单粗暴的方式，更倾向于金丝雀模式，但不完全是金丝雀。
具体是有一套环境，分几个集群，在这几个集群间做几种流量的切换，集群在运行过程中是隔离的。
可以理解为灰度环境和正式环境，具体的灰度过程大致如下：
灰度环境：每天的需求都会部署到灰度环境，日常没有正式租户，只是测试、演示租户，灰度周期内会切换流量到灰度环境进行验证。
正式环境：灰度环境验证没有问题后，则进行流量切换全量发布。
所以在正式环境全量发布时，会在灰度环境上进行少部分租户的验证，以确保本迭代内容的稳定可靠。
在灰度过程中解决掉所有问题再全量发布，则出现事故的概率将会大大降低，也就达到了提升可用性的目标。
后续的方向：
以上说的灰度，是系统级的灰度，针对不同租户进行灰度。
还有几个级别的灰度，包括产品级灰度，模块级灰度、功能级灰度。
产品级灰度是比较困难的，产品的依赖关系，调用关系很难处理，也是一大难题，目前需求不是很强烈，暂时未兑现。
模块级灰度，是可以通过配置完成的，即通过在数据库中设置灰度记录，进行代码级的灰度控制。
功能级灰度，一般通过功能界面的配置来解决，也可以采取模块级的处理方法，不管哪种，都是代码级灰度控制，只是开不开放给客户自己控制而已。
针对几上几类灰度，产品级灰度终归是需要迈过去的一道坎，争取早日实现突破。
以上介绍了系统级的灰度选型标准和最终方案，重点考虑的是发布过程中如何让BUG产生时不宕机，系统不挂，对于客户的影响最小。
除了发布机制上的灰度，提升可用性，个人认为从内建质量上发力，让系统不产生BUG才是根本的解决之道，但这是道阻且长，价值非常大的一件事，唯有继续努力，才能实现理想。
声明：本站部分文章内容及图片转载于互联 、内容不代表本站观点，如有内容涉及侵权，请您立即联系本站处理，非常感谢！