Dubbo

作者：知乎用户
链接：https://www.zhihu.com/question/52133065/answer/253024031
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

分布式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技术之类，效率不高。
 

 

dubbo是用来跨系统通信的，即使不用集群也可以。
一个系统用作客户端，一个系统则充当服务端。服务端要把自己的接口定义提供给客户端，客户端将接口定义在spring中的bean。客户端可以直接使用这个bean，就好像这些接口的实现也是在自己代码里一样。
客户端和服务端启动的时候都会把自己的机器IP注册到zookeeper上。客户端会把zk上的服务端ip拉到磁盘上，并记录哪些ip提供哪些服务（服务端启动的时候暴露给zk）。然后调用的时候客户端会根据ip调用服务端的服务，这时候即使zk挂掉也没关系。

 

1. 负载均衡是对外提供一个公共地址，请求过来时通过轮询、随机等，路由到不同server。目的分摊压力。
失效备援是发现一台server挂了，就让另外一台去服务了。跟餐馆换个服务员继续招待你一样。

2. Java下的一套RPC框架(soa思想)，作用就是统一管理配置，各个系统服务间的调用。dubbo在淘宝也是解决他们实际问题的，不一定适合其他。 另外各家公司也都有大同小异的实现，所以没多少人用、也就没多少介绍。
原理就是： A系统调用B系统接口服务， 后面就是怎么把这个流程，动态化(zookeeper通知)、权限化、配置化、低耦合化、自动化。

3. 没有银弹，算属于系统架构范畴，基本都是经验积累的。 别直接去学分布式，多在实际项目中去用，用多了就懂了。