Dubbo的安装以及使用

一 单一应用架构

当一个网站流量很小的时候，只需一个应用即可。但随着流量的增加，维护成本将越来越大。

二 垂直应用架构

垂直结构将应用拆分成几个互不相干的小应用。使流量分部到各个子系统中。但缺点是逻辑相同的代码可能要在各个系统中不断复制。

三 分布式应用架构

分布式应用架构（RPC Remote Procedure Call 远程过程调用），是一种进程间的通信方式。允许像调用本地服务一样调用远程服务。RPC 框架负责屏蔽底层的传输方式(如 TCP)、序列化(如 XML/JSON)和通信细节。使用者只需要了解谁在什么位置提供了什么样的远程服务接口即可。
RPC 采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

RPC 框架一般包括三个部分：
a) 服务提供者
b) 服务调用者
c) 注册中心
我们需要将服务注册，然后让调用者来发现服务，这需要一个注册中心，来管理所有服务提供者的地址。随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体(SOA)。SOA 是一种粗粒度的、松耦合的以服务为核心的架构。
SOA 面向服务的一般原则：服务可复用、松耦合(尽量不要依赖其它独立功能的服务提供者)。服务是底层逻辑的抽象(只有暴露的服务对外可见，底层实现不可见)。服务可以组合编排。

四 Dubbo的简介

Dubbo 是阿里巴巴的一个开源分布式服务框架。它最大的特点是按照分层的
方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo 采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

dubbo 中主要角色：

• Provider 生产者，服务提供方
• Consumer 消费者，调用服务的一方
• Registry 注册服务和发现服务的地方
• Monitor 监控中心，统计服务的调用次数和调用时间

Dubbo的工作原理：

• 轻量级的 Java 容器通过 main 函数初始化 Spring 上下文，根据服务提供者配置的 XML 文件将服务按照指定的协议发布，完成服务的初始化工作。
• 服务提供者根据配置的服务注册中心地址连接服务注册中心，将服务提供者信息发布到注册中心。
• 消费者根据消费者 XML 配置文件的服务引用信息，连接注册中心，获取指定的服务地址。
• 服务注册中心根据服务订阅关系，动态地向指定的消费者推送服务地址信息。
• 消费者调用远程服务时，根据路由策略，从本地缓存的服务提供者地址列表中选择一个服务提供者，然后根据协议类型简历链路，跨进程调用服务提供者。

Dubbo 的调用关系：

• 服务器负责启动，加载，运行提供者（例如在 tomcat 容器中，启动 dubbo服务端）。
• 提供者在启动时，向注册中心注册自己提供的服务。
• 消费者启动时，向注册中心订阅自己所需的服务。
• 注册中心返回提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
• 消费者，从远程接口列表中，调用远程接口，dubbo 会基于负载均衡算法，选一台提供者进行调用，如果调用失败则选择另一台。
• 消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。（可以在 dubbo 管控中心的可视化界面看到）

Dubbo 原理：

ConfigServer：配置中心，和每个 Server/Client 之间会作一个实时的心跳检测（因为它们都是建立的 Socket 长连接），比如几秒钟检测一次。收集每个 Server 提供的服务的信息，每个 Client 的信息，整理出一个服务列表，如：

当某个 Server 不可用，那么就更新受影响的服务对应的 serverAddressList，即把这个 Server 从serverAddressList 中踢出去（从地址列表中删除），同时将推送serverAddressList 给这些受影响的服务的clientAddressList 里面的所有Client。如：192.168.0.3 挂了，那么 UserService 和 ProductService 的serverAddressList 都要把 192.168.0.3 删除掉，同时把新的列表告诉对应的Client 172.16.0.1，172.16.0.2，172.16.0.3；相应的，当某个 Client 挂了，那么更新受影响的服务对应的 clientAddressList
ConfigServer 根据服务列表，就能提供一个 web 管理界面，来查看管理服务的提供者和使用者。新加一 Server 时，由于它会主动与 ConfigServer 取得联系，而 ConfigServer又会将这个信息主动发送给Client，所以新加一个Server 时，只需要启动Server，然后几秒钟内，Client 就会使用上它提供的服务

Client：调用服务的机器，每个 Client 启动时，主动与 ConfigServer 建立Socket 长连接，并将自己的 IP 等相应信息发送给 ConfigServer。
Client 在使用服务的时候根据服务名称去 ConfigServer 中获取服务提供者信息（这样 ConfigServer 就知道某个服务是当前哪几个 Client 在使用），Client拿到这些服务提供者信息后，与它们都建立连接，后面就可以直接调用服务了，当有多个服务提供者的时候，Client 根据一定的规则来进行负载均衡，如轮询，随机，按权重等。一旦 Client 使用的服务它对应的服务提供者有变化（服务提供者有新增，删除的情况），ConfigServer 就会把最新的服务提供者列表推送给 Client，Client就会依据最新的服务提供者列表重新建立连接，新增的提供者建立连接，删除的提供者丢弃连接。

Server：真正提供服务的机器，每个 Server 启动时，主动与 ConfigServer建立 Scoket 长连接，并将自己的 IP，提供的服务名称，端口等信息直接发送给ConfigServer，ConfigServer 就会收集到每个Server 提供的服务的信息。

优点：

• 只要在 Client 和 Server 启动的时候，ConfigServer 是好的，服务就可调用了，如果后面 ConfigServer 挂了，那只影响 ConfigServer 挂了以后服务提供者有变化，而 Client 还无法感知这一变化。
• Client 每次调用服务是不经过 ConfigServer 的，Client 只是与它建立联系，从它那里获取提供服务者列表而已
• 调用服务-负载均衡：Client 调用服务时，可以根据规则在多个服务提供者之间轮流调用服务。
• 服务提供者-容灾：某一个 Server 挂了，Client 依然是可以正确的调用服务的，前提是这个服务有至少 2 个服务提供者，Client 能很快的感知到服务提供者的变化，并作出相应反应。
• 服务提供者-扩展：添加一个服务提供者很容易，而且 Client 会很快的感知到它的存在并使用它。

Dubbo 优缺点：

优点：
a) 透明化的远程方法调用，像调用本地方法一样调用远程方法
b) 拥有软件负载均衡和容错机制，可以代替 nginx lvs 等硬件负载均衡
c) 服务中心自动注册和配置管理，注册中心基于接口自动查询提供者 ip
d) 提供了完善的服务接口管理与监控

缺点：
只支持 java 语言

值得注意的是：dubbo 在 zookeeper 中服务信息是持久信息，接口信息是临时的。有关zookeeper的知识，可以参考我往期的文章

五 Dubbo工程的搭建

我的Demo上传到我的码云：Gitee地址