ons问题咨询 about easytransaction HOT 24 CLOSED

恩，CID和PID是唯一的， topic使用appId是在哪里看到的？

from easytransaction.

EasyTransMsgInitializer 这里的init方法。那就是框架不支持多topic的？那测试环境和生产环境怎么区分？

from easytransaction.

框架是支持多TOPIC的，支持发布到多个TOPIC，也支持监听多个TOPIC的数据。

EasyTransMsgInitializer里的appId并不指代应用自身的appId,而是指代各个需要监听的消息对应的appid

from easytransaction.

CID是唯一的，怎么监听不同的topic？

from easytransaction.

CID只是消费者ID呀，一个消费者可以消费多个不同TOPIC

from easytransaction.

这样不会出现订阅关系不一致的情况？你这边只有一个CID，然后用来监听不同的topic。
阿里云文档：https://help.aliyun.com/knowledge_detail/29641.html

from easytransaction.

不同的服务用不同的CID，同一个CID订阅的都是同一批TOPIC，与文档没有冲突

from easytransaction.

明白了，之前陷入误区了。非常感谢。

from easytransaction.

还是有一个问题需要咨询下。EasyTransMsgInitializer中的consume方法，里面获取filterChain的时候使用的是applicationName，这个applicationName是服务提供方的应用名，EasyTransFilterChain filterChain = filterChainFactory.getDefaultFilterChain(applicationName/*should use consumer's appId*/, businessIdentifer.busCode(), EasyTransFilterChain.MESSAGE_BUSINESS_FLAG); 但是这里有个备注（should use consumer's appId），我现在可靠消息上@BusinessIdentifer中指定的appid和服务提供方applicationName不一致，导致有filterChain在执行invoke的时候出现空指针。请问@BusinessIdentifer中指定的appid是消息需要监听的topic，但是这里的applicationName是什么意思？为什么调试下来是服务提供方的applicationName？

from easytransaction.

导致空指针是一个BUG，由引入级联事务导致的，我今晚看下如何修复

applicationName这里的含义原来是RPC的接收方，也就是RPC的PROVIDER。但引入了队列后，队列的消费者收到的消息的APPID与消费者自身的APPID可能不一致，因此就有（should use consumer's appId），这里也有点不恰当，违反了单一职责原则，我也看看一并怎么改掉吧

from easytransaction.

想和你在确定下，服务提供方接收到的消息的APPID，就是有@BusinessIdentifer指定的，是需要监听topic对吧？

from easytransaction.

其实在队列里，不应该叫服务提供方，叫消费者。因为有可能，一个消息是多个consumer来消费的，发出消息的服务仅仅只是告知而已，叫服务提供方不太合适。

是的，BusinessIdentifer里指定的APPID在ONS里就是TOPIC，businessCode就是tag。（KAFKA里并不是这样，其只有TOPIC没有TAG，因此会有不同）

from easytransaction.

空指针抛出的位置贴一下？

from easytransaction.

已修复，再试下？

from easytransaction.

通过BusinessIdentifer指定topic是不是还存在一个弊端？比如，我生产环境和测试环境希望使用不同的topic，利用你这种方法没办法区分吧？

from easytransaction.

测试环境和生产环境的KAFKA/ONS不应该不一样么？

from easytransaction.

是应该不一样，但是你这里@BusinessIdentifer(appId = Constant.APPID_TEST, busCode = ReliableMessage.BUSINESS_CODE)不是写死了使用的topic了，annotion没有办法通过加载配置文件实现不同环境使用不同环境的topic吧。

from easytransaction.

嗯，annotation的值不能运行时修改.同一业务不同环境用不同名称TOPIC名称的原因是？

from easytransaction.

就像生产环境用生产的数据库，测试环境用测试环境的数据库一样。消息队列我们也希望能够区分开，感觉实际使用过程中这种需求也是比较正常的。有没有其他办法？不行的话我只能改你这个方法了com.yiqiniu.easytrans.util.ReflectUtil#getBusinessIdentifer每次获取注解的时候动态修改下topic名称或者加上环境变量前缀。

from easytransaction.

我感觉这还是有点区别的

• 首先数据库通常是服务独占的，但是TOPIC通常都是跨服务协作的
  • 其服务之间的协作关系可能是一对多，多对一，甚至于多对多，如果你有一个动态配置来映射这个业务在特定环境里的TOPIC名的话，那么所有的服务都需要获得这个动态TOPIC名（也就是说所有的服务都需要修改这个配置）
• 然后个人认为，数据库名在不同环境里名称也一致是更好的
  • 这样配置能减少变动，调整的只是环境的IP

如果实在不行也欢迎你这边提出PR，使其可以动态地获得运行时的TOPIC名

from easytransaction.

正常名字统一是比较好。但是ons有这个特性——全局topic必须唯一，既然你通过@BusinessIdentifer指定了topic和tag，也就相当于同一份代码固定死了topic和tag，所以同一份代码没办法在不同环境使用了。

from easytransaction.

恩...想起来了，ONS确实有这个恶心的地方，在以前公司里用的版本也并不是写死用那个TOPIC的，只是放出来后感觉没必要就改掉了，这个我周末提供个方法吧

from easytransaction.

好的，非常感谢。

from easytransaction.

已提供方法，添加一个Bean QueueTopicMapper即可实现自定义的appid/busCode到 topic/tag 映射

from easytransaction.