灰度升级方案
2016年11月09日


首要目的:利用线上服务器、线上数据,做系统的测试(主要是功能测试)。

其他目的:利用线上服务器、线上数据,做一个特殊用途的应用(只是客户端不一样,内部处理流程都和正式系统一样)。


必要原则:

1、灰度系统的主要程序流程和正式环境一样,否则灰度系统没有测试和验证的意义。
2、从灰度环境,不用再次上线,能够快速地切换到正式环境。


关键思路:

1、把少部分数据引入灰度系统,数据的结果不影响正式系统。
    限定这一部分数据,只能由某些服务器处理。
filter端:比如有5台服务器,其中2台为灰度用。这两台灰度filter只处理指定的部分数据,其他数据交给非灰度filter服务器去处理。这种方案有严重的性能问题。假如每台filter每秒处理2000条数据,那么这种方案下,灰度filter的2000条数据就要通过http转发给正式filter去处理,每秒都会发送2000条数据,kafka是高性能的消息处理系统,但是filter不是,kafka有能力每秒钟给filter传2000条数据,但是filter不是专业的MQ,它没办法有效的保证每秒把2000条数据传给另一个系统。
所以要换种思路:filter做灰度的意义何在?filter本来就是一个简单系统,一旦做好之后,核心功能很少会有变更。唯一变更得可能多一点的是筛选逻辑,而这个逻辑,只需要一个类实现一个接口就搞定。也就是说,filter的上线,基本上就是更新这个接口的实现类。


再说一种更好的思路:filter不是数据的入口,filter的上游数据源才是。我们目的是限制某台filter只处理特定数据,换种思路,我们只给这台filter特定数据那不就完了。只是数据源变了,filter内部逻辑全都不变。


再换一种思路:切换一下filter的配置,让灰度filter只处理某些app的数据,而非灰度filter不处理这些app的数据。则只需要灰度filter跟非灰度filter的kafka groupId不一样即可。


2、最终数据流出可控。

单独拿一台push做灰度用,monitor控制指定app固定分配到这台push上。这台push不加入push集群,单独存在,它也不在monitor监控范围,没有负载均衡、故障转移等功能。
这台push在monitor做任务分配时,需要特殊处理。其他地方都和正常的push一样对待。


3、monitor升级方案

minitor如果要做灰度升级也可以,但是比较麻烦。关键是,monitor值不值得做灰度升级,有没有必要?
-- monitor的核心功能稳定之后,应该不会有大的改动,如果要改,多半也涉及集群,很难将单台monitor独立工作。
monitor灰度升级方案如下:
首先,需要push服务器做配合,因为monitor主要是用来管理push,没有push的支持,也很难测试monitor的功能。
比如有5台push服务器,那么拿出2台push配合monitor做灰度升级。
如果有4台monitor服务器,拿出其中2台monitor做灰度升级。
拿出来的2台push和2台monitor组成一个灰度环境集群。剩下的3台push和2台monitor继续提供正常服务。
等灰度环境的monitor和push验证OK后,再无缝切换成正式服务,切换方法:
    将灰度环境的monitor和push停掉,然后启动monitor和正常服务的另外两台组成4台monitor的集群(此时leader仍在旧monitor上)。然后启动push,然后关闭另外两台没有更新的monitor(此时leader转移到新monitor上),然后更新停掉的这两台monitor并启动重启。


最终方案:

分步实现,在第一期的方案里面,我们只实现filter的灰度升级。具体如下:
一期方案:实现filter的灰度升级,保证filter的逻辑可以通过灰度环境去验证,灰度的控制级别是appId级别。
二期方案:实现push的灰度升级,特定app的数据可以固定到灰度push服务器去处理。同时monitor做配合改造。
三期方案:实现monitor的灰度升级,以及monitor+push的同时升级。push做配合改造,(kop做配合测试)。


一期方案内容:

首先,filter数据筛选模块,做成组件化,甚至热加载,新增数据筛选项,只需要在原有filter的基础上增加一个jar包即可。这样对filter改动小,且不影响已有功能。
其次,定义一台灰度filter,灰度filter跟非灰度filter的kafka groupId不一样,各消费各的,但是让灰度filter只处理某些app的数据,而非灰度filter不处理这些app的数据。


二期方案内容:

定义一台灰度push,控制monitor只给灰度push分配特定appId的数据。需要在monitor分配app任务时,加一个类似于AOP的拦截,在统一配置中心里面配置。


三期方案内容:

定义一组monitor和push组成灰度环境集群,与正常服务的monitor和push在不同的集群下面。人工或者利用灰度KOP给灰度monitor引入特定的测试APP,验证OK后再将灰度环境无缝切换成正式环境。