Dubbo框架学习
（2）注册中心自动处理FailOver，当服务节点挂掉之后，自动为消费者筛选可用节点，并尝试与挂掉节点进行可用性探测
（3）注册中心自动处理负载均衡，自动为消费者选择负载较低的服务节点
（4）引入监控中心提供服务调用统计功能，为容量规划和扩容提供数据支撑
需要注意的几点：
（1）注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
（2）注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
（3）注册中心，服务提供者，服务消费者三者之间均为长连接，服务提供者宕机，注册中心将立即推送事件通知消费者
（2）Dubbo基本三要素：Consumer，Provider，Registry
（3）Registry支持Redis，Zookeeper，Multicast，Simple四种注册中心，一般使用Zookeeper，
通过Dubbo Admin可以将在注册中心（Zookeeper）的服务可视化，如Consumer，Provider列表
也可以通过ZKUI预览Zookeeper内部的服务节点
（4）可选要素Monitor：
- 统计各服务调用次数，调用时间等，统计先在内存汇总后，每分钟一次发送到监控中心服务器，并以报表展示,为服务的运维采集数据。
- 监控中心也是一个标准的Dubbo服务,内置jetty容器，使用jetty运行，默认8080
- Monitor挂掉不会影响到Consumer和Provier之间的调用，只是丢失部分采样数据
- 通过dubbo-monitor-simple应用监控服务使用情况，并生成图表展示
5、Dubbo默认使用基于NIO的长连接
（1）注册中心，服务提供者，服务消费者三者之间均为长连接
（2）什么是短连接、长连接？
短连接：建立连接——数据传输——断开连接
长连接：建立连接——数据传输——保持连接（发送心跳）——数据传输——保持连接（发送心跳）——.......——关闭连接
长连接缺点：长连接指建立SOCKET连接后不管是否使用都保持连接，安全性较差
什么时候用长连接：交互比较频繁，点对点的场景，如QQ好友聊天、Dubbo注册中心与消费者或提供者之间、数据库连接池....
什么时候用短连接：Web网站一次性服务服务场景，比如银行的服务。网站通常服务于大量用户，长连接对于服务端来说会耗费一定的资源
Http长连接：使用Connection:keep-alive，HTTP 1.1默认进行持久连接
6、关于Dubbo超时
（1）Dubbo默认超时时间？
（2）如果消费者和提供者都配置了超时时间，那么Dubbo超时取决于消费者
（3）Dubbo超时后是否Retry？Retry次数？
如果配置了dubbo.reference.retries>1就会进行相应次数Retry
超时后Retry需要注意：查询可以重试，提交数据则不能重试（超时并不代表服务提供端完全执行失败），如果只是简单重试容易导致数据重复
（4）超时由哪一方设置比较好？
服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚
（5）超时之后进行重试仍然失败，则给消费者抛出异常
7、注册中心之Zookeeper
在微服务架构中，每个服务都是一个单独的应用，并且部署在不同的机器上，对于一个给定的用户服务往往需要不同的服务之间相互调用才能完成，这就是所谓的分布式系统。在分布式系统架构下可能存在如下问题：
（1）服务A如何感知服务B的存在？或者服务B发生变化之后，如何通知服务A
（2）服务A和服务B需要竞争服务C中的某个资源，发生冲突怎么办
（3）如何保证服务节点的高可用性？
Zookeepe作为一个高性能的分布式服务协调框架，可以有效解决上述问题：
当提供者出现断电等异常停机时，Zookeeper注册中心能自动删除提供者信息，当提供者重启时，能自动恢复注册数据