Albumen Kevin
Albumen Kevin
这个是整体打包的问题，只要用了 fatjar，所有类都会多一份，所以除非全部都变成 optional 不然没法处理
https://dubbo.apache.org/zh/docs/advanced/set-host/
2.6.x 版本已经 EOL 了，不再继续发版本了
> > 2.6.x 版本已经 EOL 了，不再继续发版本了 > > 以后只能使用3.x版本了么，可是我们的spring-boot使用的2.1.x系列 Dubbo 2.7、3.x 支持从 1.5.x 开始的所有版本 spring-boot
[可以看下apisix](https://apisix.apache.org/zh/docs/apisix/plugins/dubbo-proxy/)
1. 可以强制走接口级先饶过 2. setProtocol 方法会在 https://github.com/apache/dubbo/pull/10256 中修复 3. hessian 协议兼容版 jar 会在https://github.com/apache/dubbo-spi-extensions/pull/125 中提供
能提供一个简单的 demo 不，我这边尝试复现下
 看了下 sofa 切换了 beanFactory，然后这个 beanFactory 没有触发 org.apache.dubbo.config.spring.context.DubboSpringInitializer#initialize，导致有些数据没注入。这个得看下是不是 sofa 那边创建 beanFactory 的时候缺少了触发的环节。
check if #10451 fixed
事务的上下文传递不是 Dubbo 直接去做的，Dubbo 本身不会去直接耦合事务的状态。Dubbo 做的只是将 invocation 里面的参数都传递给服务端，至于服务端拿到后如何开启事务那是事务框架的事情。 另外，在异步调用场景下，Dubbo是提供 onResponse 异步调用的，也就是 invoke 是一个同步过程，onResponse 在异步结果返回后再触发。也即是如果服务端处理很慢，消费端快速返回后 onResponse 也会等到服务端处理完才触发。（Seata有没有使用这个机制需要和 Seata 社区确认下） 按照我的理解，对于异步场景下，调用端的事务不应该在请求快速返回后就被关闭的，因为都还不知道服务端是否真实处理完成，这里能返回只能说明 RPC 框架没问题，并不能保证服务端的真实实现没报错。那假设服务端报错了，即使在异步调用下，事务也应该被回滚的。