dubbo 分布式的理解

忘是亡心i 2021-06-10 10:31 557阅读 0赞

## 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:registry address="zookeeper://192.168.17.129:2181" />
    	
    	<dubbo:protocol name="dubbo" port="20880" />
    	
    	
    	<bean id="xxx.xxx.xxx.XxxImpl" class="xxx.xxx.xxx.XxxImpl" />
    	<dubbo:service interface="xxx.xxx.xxx.Ixxx" ref="xxxImpl" />
    
        消费者
    	
    	
    	<dubbo:application name="consumer" />
    	
    	<dubbo:registry address="zookeeper://192.168.17.129:2181" />
    	
    	<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策略