Dubbo及注册中心原理
今天是猿灯塔“365天原创计划”第4天。
今天呢！灯塔君跟大家讲：
Dubbo及注册中心原理
Dubbo意义
网站应用的架构变化经历了一个从所有服务分布在一台服务器上（All in one ,单一应用架构）到 垂直应用架构（MVC模式，按照各模块的职能划分）到分布式应用架构（RPC,按照服务不同分布在不同的服务器上）再到面向服务的架构（SOA,增加调度中心,负责集群的调度和管理）的过程.Dubbo就是处在SOA架构阶段的一个远程服务调用框架.
Dubbo系统分为五个部分：
远程服务运行容器（Container）
远程服务提供方（Provider)注册中心（Register）
远程服务调用者（Consumer）监控中心（Monitor）
Dubbo服务调用过程：
服务提供方（Provider）所在的
应用在容器中启动并运行
（这个容器可以说是该应用部署的tomcat）服务提供方(Provider)将自己要发布的服务注册到注册中心（Registry）
服务调用(Consumer)方启动后向注册中心订阅它想要调用的服务
注册中心(registry)存储着Provider注册的远程服务,并将其所管理的服务列表通知给服务调用方（Consumer）并且注册中心和提供方和调用方之间均保持长连接,可以获取Provider发布的服务的变化情况并将最新的服务列表推送给Consumer
Consumer根据从注册中心获得的服务列表根据软负载均衡算法选择一个服务提供者（Provider）进行远程服务调用如果调用失败则选择另一台进行调用（Consumer会缓存服务列表，即使注册中心宕机也不妨碍进行远程服务调用）
监控中心（Monitor）对服务的发布和订阅进行监控和统计服务消费者和提供者,在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（Monitor）;Monitor可以选ZookeeperRedis或者Multiast
注册中心等后续介绍.
当提供者出现断电等异常停机时注册中心能自动删除提供者信息当注册中心重启时,能自动恢复注册数据以及订阅请求
-
当会话过期时,能自动恢复注册数据,以及订阅 请求 当设置<dubbo:registry check="false" />时 记录失败注册和订阅请求,后台定时重试 可通过设置<dubbo:registry username="admin" password="124" />设置zookeeper 登录信息 可通过<dubbo:registry group="dubbo" /> 设置 zookeeper 的根节点, 不设置将使用无根树
支持*号通配符<dubbo:redistry group="
" version="" />,可订阅服务的所有分组和
所有版本的提供者
Dubbo+Redis
Redis是一个基于内存的,以Key-Value形式
存储数据的高性能Nosql数据库可以用来存储
远程服务信息用作注册中心
使用 Redis 的 Key—Map
结构存储数据结构：
主键Key为服务名和服务类型:
比如./dubbo/com.foo.BarService
/providers或./dubbo/com.foo.
BarService/providers相当于
Zookeeper中的第三层目录Value为过期时间用于判断脏数据,
脏数据由监控中心删除
使用Redis的Publish/Subscribe事件通知
数据变更:
通过事件的值区分事件类型:register,
unregister,subscribe,unsubscribe
普通消费者直接订阅指定服务提供者的Key
只会收到指定服务的register,unregister事件监控中心通过psubscribe
功能订阅/dubbo/*会收到
所有服务的所有变更事件
调用过程：
BarService/providers发送 register 事件
服务消费方启动时:
从Channel:/dubbo/
com.foo.BarService/providers订阅register和unregister事件并向Key:/dubbo
服务消费方收到register和unregister
事件后从Key:/dubbo/com.foo.
BarService/providers
服务监控中心启动时:
从Channel:/dubbo/*订阅register和unregister,以及subscribe
和unsubsribe事件服务监控中心:
服务监控中心:
猿灯塔：做程序猿的引导者！
新浪微博：@猿灯塔