dubbo重试机制原理_dubbo的实现原理是什么？

分布式SOA架构涉及到了dubbo，它有2部分，服务的提供方和服务的消费方，官方推荐用zookeeper作为一个注册中心，具体怎么用呢？首先服务的提供方暴露出他所提供的服务接口，提供给zookeeper注册中心进行注册进行管理，当消费方需要使用的时候，它会到zookeeper中查询相应的服务接口是否存在，如果找到了，那么zookeeper注册中心把服务消息的提供方的具体IP地址返回给服务的消费方，然后由你的服务的消费方直接去服务的提供方上去使用，原理就是这么个过程。但是dubbo是存在问题的，

1事务和异常问题，举个例子，假设它调用了方法A，方法A查询了数据库，他的返回值被方法B使用了，那么方法B又查询了一次数据库，假设我的数据库初始化字段是0，那么方法A中进行加1的处理，然后又调用了方法B,方法B又进行了加2的处理，又回到方法A，又进行了加1的处理，假设都没有异常的话，最终会变成4，那如果进行方法B的时候出现了异常，那异常怎么办？怎么管理？就一直抛出异常。这就是事务和异常的相关管理，事务的管理不明确。是外层管理理论还是内层管理需要定义传播行为。

2代码的耦合性问题，一旦那边的方法接口改变了，这边就失败了，你就必须重新修改你的端口，修改你调用的方法。

3效率问题，比如一个电商平台，商品上架的时候，同时用到了2个技术，保存在solr索引库中和页面静态化。那么此时2个是同步操作， 如果还有其他的操作，它也会一个个执行，先进行solr保存啦，然后freemarker静态化啦、这个时候用的时间很多，这个时候用到消息服务中间件，JMS也就是一个消息服务的消息列，我们还要使用activeMQ技术之类，效率不高。