SOA的理解:
可以把SOA架构看作成一个完整的企业架构,企业里有各种业务,每个业务都有自己的服务,业务通过企业服务总线串联起来,有个服务注册中心,业务把自己的服务注册到注册中心。消费者可以在注册中心找到自己的服务,完成自己的需求。达到一站式服务。
分布式的理解
简单的讲: 大任务划分为小任务。一个或多个人完成同一任务中的不同部分。
被分解后的小任务相互之间有独立性,节点之间只管接受和传递信息。
Dubbo:
什么是dubbo?
Dubbo是个服务治理中间件,是一款远程调用框架,就是资源调度和治理中心的管理工具。;
Dubbo的组成部分:
1、容器 (spring容器)
2、服务生产者
3、注册中心 (zookeeper 、redis (发布订阅 -频道))
4、服务消费者
5、监控中心(可以查看哪个方法的使用次数)
Dubbo的运行流程:
容器启动,服务生产者会把自己的服务的接口地址报告给注册中心。服务消费者订阅它需要的服务,他去查询注册中心,问问是否有地址吗?有就返回服务地址。消费者拿到地址就可以去调用服务。监控中心:监控生产者和消费者的健康状况。
【dubbo,zookeeper流程,从生产者到消费者】
生产者和消费者都要进行dubbo的配置 ,都需要注册zookeeper主机地址,
生产者要配置dubbo使用的协议(默认dubbo)和端口号用来暴露服务到注册中心,
生产者定义接口和实现类,并在配置文件中进行注册服务,
生产者启动时会自动把注册的接口的信息转化为一个url,
并通过hessian二进制序列化存储到zookeeper的节点中
消费者在配置文件中引入要使用的服务接口,
消费者启动时会从zookeeper中获取与引用的接口匹配的url,
并把自己的信息留在zookeeper中
服务者和消费者在zookeeper中的信息都会被监控中心monitor获取到,
可以通过monitor服务对zookeeper中的内容进行管理
【服务的配置】
服务者
<!-- 给服务起一个名称,唯一标识,用来监控服务器调用关系,调用次数 -->
<dubbo:application name="provider" />
<!-- 使用dubbo官方推荐注册中心模式注册对象 -->
<dubbo:registry address="zookeeper://192.168.17.129:2181" />
<!-- 用dubbo协议在20880端口暴露服务 -->
<dubbo:protocol name="dubbo" port="20880" />
<!-- 发布服务:itemService 注册对象,通过接口来注册对象 -->
<!-- 和本地bean一样实现服务 -->
<bean id="xxx.xxx.xxx.XxxImpl" class="xxx.xxx.xxx.XxxImpl" />
<dubbo:service interface="xxx.xxx.xxx.Ixxx"
ref="xxxImpl" />
消费者
<!-- 给服务起一个名称,唯一标识,用来监控服务器调用关系,调用次数 -->
<!-- 消费方应用名,用于计算依赖关系,不是匹配条件,不要与提供方一样 -->
<dubbo:application name="consumer" />
<!-- 使用multicast广播注册中心暴露发现服务地址 -->
<dubbo:registry address="zookeeper://192.168.17.129:2181" />
<!-- 生成远程服务代理,可以和本地bean一样使用itemService -->
<dubbo:reference id="xxx"
interface="xxx.xxx.xxx.Ixxx" timeout="1000000" retries="2"/>
注册中心挂了会产生什么影响?
答:对服务的调用没有任何影响,因为本地缓存了服务端的地址。
为什么使用Dubbo?答:1、Dubbo提供了丰富的协议选择:Dubbo协议(服务调用),注册服务:zookeeper协议,tcp协议,http协议等。协议越底层,传输效率越高。 2、io的选择:异步的nio。
Dubbo负载均衡策略:
random loadbalance :随机负载均衡
默认情况下,dubbo是random load balance随机调用实现负载均衡,可以对provider不同实例设置不同的权重,会按照权重来负载均衡,权重越大分配流量越高,一般就用这个默认的就可以了。
roundrobin loadbalance 均匀负载均衡
均匀地将流量打到各个机器上去,但是如果各个机器的性能不一样,容易导致性能差的机器负载过高。所以此时需要调整权重,让性能差的机器承载权重小一些,流量少一些。
leastactive loadbalance 不活跃的性能差的机器更少的请求**
这个就是自动感知一下,如果某个机器性能越差,那么接收的请求越少,越不活跃,此时就会给不活跃的性能差的机器更少的请求。
consistanthash loadbalance 一致性hash
一致性Hash算法,相同参数的请求一定分发到一个provider上去,provider挂掉的时候,会基于虚拟节点均匀分配剩余的流量,抖动不会太大。如果你需要的不是随机负载均衡,是要一类请求都到一个节点,那就走这个一致性hash策略
dubbo集群容错策略:
failover cluster模式 (默认)
失败自动切换,自动重试其他机器,默认就是这个,常见于读操作。
failfast cluster模式
一次调用失败就立即失败,常见于写操作。
failsafe cluster模式
出现异常时忽略掉,常用于不重要的接口调用,比如记录日志。
failback cluster模式
失败了后台自动记录请求,然后定时重发,比较适合于写消息队列这种。
forking cluster模式
并行调用多个provider,只要一个成功就立即返回。
broadcacst cluster模式
逐个调用所有的provider
dubbo动态代理策略:
默认使用javassist动态字节码生成,创建代理类
Dubbox支持的协议:
dubbo协议(默认),单一长连接,NIO异步通信,基于**hessian(默认)**作为序列化协议. 适用的场景就是:传输数据量很小(每次请求在100kb以内),但是并发量很高 . 注意Dubbo的默认配置是100个连接数
http协议 json序列化
rmi协议 java二进制序列化
webservice协议 SOAP文本序列化
hessian序列化,传输的数据格式为PB,谷歌出品的一种轻量级并且高效的结构化数据存储格式,性能比 xml,json要高很多,
相对于xml,json ,PB结构数据使用了proto编译器,自动进行序列化和反序列化,速度非常快,第二数据压缩效果好,体积比xml,json小,在网络传输上有优势,带宽和速度上有优势.
zookeeper的个人理解和怎么使用的
个人理解:Zookeeper是在分布式系统中帮助我们协调任务,能够在各个服务或节点之间进行协调的服务或中间人。
使用:在服务方的配置文件中配置zk的的地址和暴露接口,而消费方在配置文件中配置zk地址和扫描服务方的接口。