cheese8

> > Mark，学习大佬们全链路路由MQ和定时任务怎么通过元数据隔离的方案~ > > 初步想到一个砖头： 元数据下发，使得A和A-test1按照元数据指引的环境reblance消费不同的Topc（+Tag？） > > 消息有一种简单的方案： A 和 A-test1 是不同的 consumer-group， broker 两边都都投递，consumer 消费的时候，判断消息里的tag，是不是属于自己的分组，如果是的话就消费，不是的话就丢弃。 > > 相当于在客户端侧处理，而不是broker端，处理起来简单很多。 这样多一套判断逻辑，侵入业务：consumer端始终要订阅生产topic和灰度topic，同时还要做判断。 我们目前的做法是： 1、1个Topic, 1个tag，当该tag需要灰度时，tag_grep作为灰度tag 2、非灰度时，2个producer往topic+tag投递，2个consumer从topic+tag消费 3、灰度时，某个producer(2个producer其中之一，往其中之一下发灰度元数据)识别到灰度元数据时，往topic+tag_grey投递，某个consumer(2个consumer其中之一，往其中之一下发灰度元数据)识别到灰度元数据时，自动reblance后消费topic+tag_grey tag加_grey后缀是约定逻辑，所以可以从mq client包上做增强，不会侵入业务。

> > > > Mark，学习大佬们全链路路由MQ和定时任务怎么通过元数据隔离的方案~ > > > > 初步想到一个砖头： 元数据下发，使得A和A-test1按照元数据指引的环境reblance消费不同的Topc（+Tag？） > > > > > > > > > 消息有一种简单的方案： A 和 A-test1 是不同的 consumer-group， broker 两边都都投递，consumer 消费的时候，判断消息里的tag，是不是属于自己的分组，如果是的话就消费，不是的话就丢弃。 >...

我这么理解的： 1、如果能注入拿到apollo key所在对象，那么可以调用ReflectionTestUtils.setField()反射给apollo key赋值，这是同步的，很方便。 2、如果拿不到apollo key所在对象，这是apollo-mock-server的用武之地了，模拟web页面修改apollo的值，并热更新到spring容器了。 问题来了，热更新到spring容器是个异步过程，实际情况中，spring context肯定比demo复杂，那么在调用addOrModifyProperty方法后，肯定得等待一段时间（这个时间不好计算），好让apollo热更新到spring容器中。 参考下面测试代码，调用addOrModifyProperty方法，keySwitch更新为WHITELIST并不是实时同步的，如果不等待一段时间的话，会导致下面代码的断言不稳定（其实到底等待多久，需考虑不同spring容器的复杂程度，所以也会导致断言不稳定）。 ``` @Test public void test_getUser_ok_WHITELIST() throws Exception { /** 重复代码 Config otherConfig = ConfigService.getConfig("application"); final SettableFuture future = SettableFuture.create(); otherConfig.addChangeListener(new ConfigChangeListener()...

I will take a look.

> Hi @cheese8 Can this issue be done in 5.1.3? Sorry, quite busy recently, maybe 5.1.4