Codecov Report

Merging #6104 (3311d82) into develop (357f8e8) will decrease coverage by 0.27%.
Report is 99 commits behind head on develop.
The diff coverage is 67.51%.

@@              Coverage Diff              @@
##             develop    #6104      +/-   ##
=============================================
- Coverage      48.79%   48.53%   -0.27%     
+ Complexity      4176     4166      -10     
=============================================
  Files            743      794      +51     
  Lines          26617    28084    +1467     
  Branches        3327     3426      +99     
=============================================
+ Hits           12989    13630     +641     
- Misses         12225    13014     +789     
- Partials        1403     1440      +37     

If you remove the filtering of the FactoryBean here, the behavior in TCC RemoteFatoryBeanParser will change, and the FactoryBean corresponding to the FactoryBean will be taken out, which needs to be considered globally.

如果去掉这里FactoryBean的过滤，在TCC的RemoteFatoryBeanParser里面的行为将会产生变化，将会取出FactoryBean对应的FactoryBean，和历史行为不一致，需要全局去考虑。

If you remove the filtering of the FactoryBean here, the behavior in TCC RemoteFatoryBeanParser will change, and the FactoryBean corresponding to the FactoryBean will be taken out, which needs to be considered globally.

如果去掉这里FactoryBean的过滤，在TCC的RemoteFatoryBeanParser里面的行为将会产生变化，将会取出FactoryBean对应的FactoryBean，和历史行为不一致，需要全局去考虑。

Previous versions of 2.x do not have RemoteFatoryBeanParser, so non-localTCC cases will generate the TCC proxy twice, A ReferenceBean generates remotingDesc once, and then beans generated by FactoryBean with the same beanName generate TCC agents once, so versions before 2.x are problematic for filtering out FactoryBeans.

2.x 之前的版本没有 RemoteFatoryBeanParser， 所以非LocalTCC的情况会进2次生成TCC代理，一次ReferenceBean生成remotingDesc, 然后通过相同的beanName由FactoryBean生成的Bean在走一次生成TCC代理，所以2.x之前的版本过滤掉FactoryBean是有问题的.

I remembered it wrong. There is no problem here. In addition, I think changing isAT to isTCC seems to be a trick, and maybe there is a better solution.
I have an idea ,The clientId and resourceId are specified in the ChannelManger#getChannel method. clientId and resourceId can be considered as unique identifiers. Why we need the tryOtherApp parameter? I think we maybe from here to optimize it.
Welcome to discuss your ideas.

是我记错了，这里是没问题的。不过我认为isAT修改为isTCC 看起来比较track，或许有更好的解决方案。
我有一个建议：ChannelManger#getChannel方法里面指定了clientId和resourceId，clientId和resourceId可以认为是唯一标识，为什么还需要tryOtherApp参数，或许可以从这里入手优化下。
欢迎讨论你的想法💡

I remembered it wrong. There is no problem here. In addition, I think changing isAT to isTCC seems to be a trick, and maybe there is a better solution. I have an idea ,The clientId and resourceId are specified in the ChannelManger#getChannel method. clientId and resourceId can be considered as unique identifiers. Why we need the tryOtherApp parameter? I think we maybe from here to optimize it. Welcome to discuss your ideas.

是我记错了，这里是没问题的。不过我认为isAT修改为isTCC 看起来比较track，或许有更好的解决方案。 我有一个建议：ChannelManger#getChannel方法里面指定了clientId和resourceId，clientId和resourceId可以认为是唯一标识，为什么还需要tryOtherApp参数，或许可以从这里入手优化下。 欢迎讨论你的想法💡

Since TCC RPC registers branches on the consumer side, but phase 2 needs to be delivered to the server side, the clientId and resourceId in that place are on the consumer side. Since the channel of the server side cannot be obtained, it is necessary to try other apps to find the channel of different apps with the same resouceId. However, it is still very risky for TCC to try other apps. After all, there is no guarantee that the resourceId is unique, and it is easy to send the same resourceId to a completely different app (not the desired one). So it's still under discussion.

因为TCC RPC 是在consumer 端注册分支，但是二阶段需要下发到server端，所以那个地方的clientId和resourceId是consumer端的，并不能取到server端的channel, 就需要通过try other app去找相同resouceId不同app的channel，但是,try other app对TCC来说目前还是很有风险，毕竟现在还不能保证resourceId的唯一性，很容易下发到相同resourceId完全不同的一个app去(并不是想要的那个). 所以目前这个问题还在讨论中.

I found the background for add tryOtherApp parameter : #5153

我找到了增加tryOtherApp parameter的背景：#5153

conclusion： 2.x add isAT (tryOtherApp), develop isAT || isTcc (tryOtherApp).