灰度升级方案
首要目的：利用线上服务器、线上数据，做系统的测试（主要是功能测试）。
其他目的：利用线上服务器、线上数据，做一个特殊用途的应用（只是客户端不一样，内部处理流程都和正式系统一样）。
必要原则：
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后再将灰度环境无缝切换成正式环境。