spring-cloud-tencent
spring-cloud-tencent copied to clipboard
Tencent
元数据路由功能实现多环境隔离有一定局限性,后续有拓展计划吗
元数据路由功能实现多环境隔离和我们公司一套环境隔离工具思想基本是一致的. 但是功能上好像有局限,只能隔离微服务调用,没有办法隔离一些中间件,如mq,定时任务场景. 以mq举例: 同一个服务的两个实例A和A-test1都是集成了mq的consumer, 这时与A-test1同一个环境中另外一个服务的实例B-test生产的消息,同时还是会被A和A-test消费到,没发做到彻底隔离
At present, at the metadata routing, SCT focus is still on the East-West flow control level.
The route you mentioned is more inclined to the full-link grayscale, involving databases, caches, message queues, etc.
好吧,我看你们最佳实践里面写的是多特性环境,以为还有什么我没注意到的. 但是从实际的使用场景而言,多特性环境的目的就是为了流量近可能隔离,仅仅是rpc调用隔离可能还不够 希望后面可以集成一些基本的如mq隔离等,或者提供一些拓展点出来
Mark，学习大佬们全链路路由MQ和定时任务怎么通过元数据隔离的方案~
初步想到一个砖头： 元数据下发，使得A和A-test1按照元数据指引的环境reblance消费不同的Topc（+Tag？）
Mark，学习大佬们全链路路由MQ和定时任务怎么通过元数据隔离的方案~
初步想到一个砖头： 元数据下发，使得A和A-test1按照元数据指引的环境reblance消费不同的Topc（+Tag？）
消息有一种简单的方案： A 和 A-test1 是不同的 consumer-group， broker 两边都都投递，consumer 消费的时候，判断消息里的tag，是不是属于自己的分组，如果是的话就消费，不是的话就丢弃。
相当于在客户端侧处理，而不是broker端，处理起来简单很多。
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，是不是属于自己的分组，如果是的话就消费，不是的话就丢弃。 相当于在客户端侧处理，而不是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包上做增强，不会侵入业务。
我们使用的场景是用于多套隔离的研测环境,用于在不明显增加资源消耗的情况下,可以有多套隔离环境供开发和测试同学使用。改动了哪几个服务，直接在一个测试环境中部署这几个服务就行，其他服务公用，这个其实和灰度环境有区别的。一般db,redis这种是公用的,不需要隔离,但是rpc调用和mq生产和消费是要隔离的。
你说的这种方案有些场景无法满足:
1.只修改生产者:测试环境test-a的生产者产生的消息没法被回归环境test消费，只能被test-a下的消费者消费。这种如果test-a环境中没有改动消费者，就不会部署消费者,这样就会导致test-a环境中产生的消息一直没有办法被消费。
2.只修改消费者:测试环境test-a的消费者没法消费回归环境test发出的消息,
引用网上的一种方案:http://blog.itpub.net/31562044/viewspace-2638789/
如果可以只增强生产者和消费者,不改动服务端就完美了
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包上做增强，不会侵入业务。
我们使用的场景是用于多套隔离的研测环境,用于在不明显增加资源消耗的情况下,可以有多套隔离环境供开发和测试同学使用。改动了哪几个服务，直接在一个测试环境中部署这几个服务就行，其他服务公用，这个其实和灰度环境有区别的。一般db,redis这种是公用的,不需要隔离,但是rpc调用和mq生产和消费是要隔离的。
你说的这种方案有些场景无法满足: 1.只修改生产者:测试环境test-a的生产者产生的消息没法被回归环境test消费，只能被test-a下的消费者消费。这种如果test-a环境中没有改动消费者，就不会部署消费者,这样就会导致test-a环境中产生的消息一直没有办法被消费。 2.只修改消费者:测试环境test-a的消费者没法消费回归环境test发出的消息, 引用网上的一种方案:http://blog.itpub.net/31562044/viewspace-2638789/ 如果可以只增强生产者和消费者,不改动服务端就完美了
简单，topic_grey只是一个举例，泛化_grey为环境标签，比如：topic_fat, topic_fat001, topic_fat002 , topic_fat003等。
1、如果只是改producer，让修改的生产者生产topic_fat001的消息，只是修改其中1个consumer消费的topic配置为topic_fat001，消费者重新reblance后就可以消费掉消息。
2、如果只是改了消费者consumer，你让producer给你造一条单独给你的数据，不就OK啦？