dubbodubbox 和dubbo 的区别

dubbo禁用服务，但消费者还是能访问，为什么会这样，求解

直连加不发布服务 DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。

这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。

下面我例举出通过哪些配置可以实现这种方案： 服务消费端: DUBBO在消费端提供了一个url的属性来指定某个服务端的地址 默认的方式是从注册中心发现接口.alibaba.dubbo.demo.HelloWorldService的服务，但是如果需要直连，可以在dubbo.properties下面配置dubbo.reference.helloWorldService.url=dubbo://ip:.alibaba.dubbo.demo.HelloWorldService可以通过配置dubbo.reference.url=dubbo://ip:port/来让某个消费者系统的服务都指向制定的服务器地址（关于配置信息可以参考《DUBBO配置规则详解》）

请教Dubbo 如何解决分布式事务

目前比较多的解决方案有几个： 一、结合MQ消息中间件实现的可靠消息最终一致性 二、TCC补偿性事务解决方案 三、最大努力通知型方案 第一种方案：可靠消息最终一致性，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。

即需要通过业务系统控制MQ的消息状态 第二种方案：TCC补偿性，分为三个阶段TRYING-CONFIRMING-CANCELING。

每个阶段做不同的处理。

TRYING阶段主要是对业务系统进行检测及资源预留 CONFIRMING阶段是做业务提交，通过TRYING阶段执行成功后，再执行该阶段。

默认如果TRYING阶段执行成功，CONFIRMING就一定能成功。

CANCELING阶段是回对业务做回滚，在TRYING阶段中，如果存在分支事务TRYING失败，则需要调用CANCELING将已预留的资源进行释放。

第三种方案：最大努力通知xing型，这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。

这种方案也是结合MQ进行实现，例如：通过MQ发送http请求，设置最大通知次数。

达到通知次数后即不再通知。

具体的案例你也可以参考下这篇博客，它上面有完整的电商系统分布式事务实现案例：/article/detail/124243

webservice和dubbo区别

1、是否在spring mvc的controller中调用dubbo的service？ 如果是从springmvc 的controller调用service，在service中调用dubbo，存在的一个好处是，可以单元测试，并且比较容易，如果不需要在service中单元测试，

dubbox 和dubbo 的区别

dubbo和dubbox都是流行的服务治理框架， dubbox是当当网的技术团队对dubbo框架的扩展，针对dubbo的一些问题进行扩展处理： 主要扩展的功能是支持REST风格远程调用（HTTP + JSON/XML)和支持基于Kryo和FST的Java高效序列化实现