这几天自己在工作之余,再次在linux上搭建了dubbo+zookeeper架构,明显比第一次更加顺手,可是这次却栽在了版本问题上,浪费了一下午时间,最后发现是版本太高导致无法启动,相信是程序员都理解这是一种怎么样的心情!!!O(∩_∩)O~~~!!!
由来:
要说dubbo的兴起,咱们就不得不说架构的演变。从ORM到MVC到RPC到SOA再到现在的dubbo。下面就是常见的一张图:
每次架构的演变都是弥补上一次架构的缺点,让他更加符合我们现在的业务。那么dubbo的出现是为了啥呢?
我们知道RPC是解决了不同内存空间之间的请求调用,而SOA是解决了当RPC提供的服务越来越多,服务管理不善导致机器的非高效利用而出现。那么dubbo就是结合了两者的优点。
Dubbo是一种高性能和透明化的RPC远程服务调用方案,也是一种SOA服务治理方案,还是一个分布式服务框架。下面是从网上大神博客上搜到的一张图,感觉很可以说明问题:
从图上可以明显的看出,它利用了RPC的远程调用,也应用了SOA面向服务的思想(注册中心)。
介绍:
1、Dubbo架构有这么几个角色:
- Provider:暴露服务的服务提供方
- Consumer:调用远程服务的服务消费方
- Registry:服务注册于发现的注册中心
- Monitor:统计服务的调用次数和调用时间的监控中心
2、dubbo的注册中心
对于服务提供方和服务消费方,不仅需要关注服务的信息,还需要管理服务。根据单一职责原则,如何才能让提供方和消费方的负担减少一点呢?
于是,dubbo的注册中心就出来了,它可以通过特定协议来完成服务的对外统一,将服务统一管理起来,从而优化内部应用对发布/使用的流程和管理。
dubbo提供的注册中心有如下几种类型:
- Multicast注册中心
- Zookeeper注册中心
- Redis注册中心
- Simple注册中心
常用的是zookeeper注册中心,zookeeper在解决实际的分布式问题上面有很好的解决方法。
3、dubbo的核心
- 远程通信:
提供对多种基于长连接的NIO框架的抽象封装,包括多种线程模型、序列化,以及“请求--响应”模式的信息交换方式
- 集群容错
提供基于接口方法的远程过程透明调用,包括对多协议的支持,以及对软负载均衡、失败容错、地址路由和动态配置等集群特征的支持
- 自动发现:
提供基于注册中心的目录服务,使服务消费方能动态地查找服务提供方,使地址透明,使服务提供方可以平滑地增加或减少机器