01｜温故知新：Dubbo基础知识你掌握得如何？

作者回复: 你好，熊猫：顺着你的意思，在客户端就知道有哪几种实现，是不是可以再继续抽象一层，通过 “路由标识” 到不同的实现（甚至都可以不用关心是哪个实现，只要路由标识能找到就行）。至于这个 “路由标识” 可以通过查找存储媒介形式（比如：数据库、配置中心等）来寻找对应的 “接口中具体的方法”，这样应该就可以做成一套通用的分发调用框架了（比如：智能网关）。详细的话可以去看看 “泛化调用”、“点点直连” 章节。

作者回复: 你好，Geek_895efd：可以参考我之前对etcd的一些理解，没有更好，只有适合自己当前项目的才是最好的。 比如etcd是一个年轻的go项目，同样是解决分布式协调问题，并且吸收zookeeper实现上的经验，在api的使用、实例的动态增减、数据体量的存储，且对外部语言的支持也更加友好。但是他的年轻和高速的迭代开发不免在稳定性上会使得一些大项目望而却步的考量因素。 其次还得看公司的运维能力，如果运维擅长zookeeper的话那大概率就使用zookeeper了，如果运维擅长etcd的话那正好可以借此机会狠狠与真实业务实战一把。两者都擅长的话，项目求稳还是可以考虑使用传统的zookeeper的，激进的话可以考虑etcd。不过大多数项目对于好多新特性都用不着，基本的增删改查和灵活的通知机制就非常够用了。

作者回复: 你好，Geek_244b79： 1.监控中心，是一个模块，可以是和应用运行在同一个进程的模块，也可以是和应用隔离开的另外一个进程(或另外一台服务器)。而监控中心，是针对数据监控的，那就势必有数据上报，既然需要上报数据，那就得分为监控中心客户端模块(负责收集监控数据上报至监控中心服务端)，监控中心服务端模块(负责分析处理监控中心客户端上报的数据)。 2.注册中心的消息推送是zk服务端主动推送至zk客户端，主要是基于zk客户端与zk服务端建立了长连接机制。

作者回复: 你好，java小霸王：你的眼睛很犀利，看出了两个具有代表性的特征，非常好，为你的认真仔细点赞。 异常信息中，还有蛮多的，详细可以见“02 异步化实践”章节的解答，熟悉这个异常是基本，灵活根据异常分析出问题是关键，可以多多体会一下～

作者回复: 你好，特别的 null 标识朋友：etcd是一个年轻的go项目，同样是解决分布式协调问题，并且吸收zookeeper实现上的经验，在api的使用、实例的动态增减、数据体量的存储，且对外部语言的支持也更加友好。但是他的年轻和高速的迭代开发不免在稳定性上会使得一些大项目望而却步的考量因素。 其次还得看公司的运维能力，如果运维擅长zookeeper的话那大概率就使用zookeeper了，如果运维擅长etcd的话那正好可以借此机会狠狠与真实业务实战一把。两者都擅长的话，项目求稳还是可以考虑使用传统的zookeeper的，激进的话可以考虑etcd。不过大多数项目对于好多新特性都用不着，基本的增删改查和灵活的通知机制就非常够用了。

作者回复: 慎独明强，你好：补充的非常棒，补充了我遗漏的一个，为你的细心点赞，细心是好事，可以抠出很多自己未知的细节因素，很好很棒。 异常信息中，还有蛮多的，详细可以见“02 异步化实践”章节的解答，熟悉这个异常是基本，灵活根据异常分析出问题是关键，可以多多体会一下～

作者回复: 你好，Geek_327f7f：侧重在提供方，主要是消费方也可以不是 dubbo 服务，比如消费方直接用 Socket 请求模拟 dubbo 协议发送请求，同样可以拿到数据的。

作者回复: 你好，simoso：能描述再具体点么？是遇到墙不通的问题呢？还是需要做下域名啥的还是啥啥啥呀？

作者回复: 你好，天天学习：我用的不是社区版，所以可以点进去看的～

作者回复: 你好，Geek_forMySelf：很 nice 的一个经典场景回答，不过也得看具体业务，如果是那种查询请求的话，幂等性与否意义不是很大；但是对于写请求的话，如果业务逻辑容忍重复数据，也做幂等性处理也无关痛痒；反而对于那种不允许重复请求导致生成重复数据的功能业务，幂等性就显得至关重要了。