Dubbo-简单入门及使用-白红宇

这是一张dubbo的调用图

调用关系说明如下:

1) 服务容器启动、加载和运行服务提供者；2) 服务提供者在启动时，向注册中心注册自己提供的服务；3) 服务消费者在启动时，向注册中心订阅自己所需的服务；4) 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更给消费者；5) 服务消费者从地址列表中，基于软负载均衡算法选一台服务提供者进行调用，如果调用失败再选另一台；6) 服务消费者和服务提供者在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。复制代码

节点角色说明

节点	角色说明
Container	服务运行容器
Provider	暴露服务的服务提供者
Consumer	调用远程服务的服务消费者
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用此处和调用时间的监控中心

Dubbo 服务器注册与发现的流程？

Provider（提供者）绑定指定端口并启动服务。

提供者连接注册中心，并发本机 IP、端口、应用信息和提供服务信息发送至注册中心存储。

Consumer（消费者），连接注册中心，并发送应用信息、所求服务信息至注册中心。

注册中心根据消费者所求服务信息匹配对应的提供者列表发送至 Consumer 应用缓存。

Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。

Provider 状态变更会实时通知注册中心、在由注册中心实时推送至 Consumer。

一.那么,为什么要用dubbo呢?

2.1 为什么要做服务

技术为业务而生，架构也为业务而出现。随着业务的发展、用户量的增长，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。

单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

流动计算架构 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

平台随着业务的发展 从 All in One 环境 就可以满足业务需求（以Java来说，可能只是一两个war包就解决了）；发展到需 要拆分多个应用，并且采用MVC的方式 分离前后端，加快开发效率；在发展到服务越来越多，不得不将 一些核心或共用的服务拆分出来，提供实时流动监控计算等，其实发展到此阶段，如果服务拆分的足够精细，并且独立运行，这个时候至少可以 理解为SOA架构 了。

2.2 服务带来的挑战

当迎来服务SOA时代，我们面临要解决的问题会很多，比如：系统的复杂度上升、服务依赖关系、服务性能监控、全链路日志、容灾、断路器、限流等。那么面对这些问题为什么还要做分布式服务呢？因为在未来只有砥砺前行，才能走的更高更远。不过看到这些问题不要气馁，先不管这些问题，让我们一步步来梳理下现存有什么问题，我们要完成什么目标，问题自然会迎刃而解。

根据现在团队的业务系统情况，首先我们要梳理出现存的问题是什么：

多种调用传输方式：HTTP方式、WebService方式；

服务调用依赖关系：人工记录，查看代码分析；

服务调用性能监控：日志记录，人工查看时间；

服务与应用紧耦合：服务挂掉，应用无法可用；

服务集群负载配置：Nginx配置，存在单点问题；

在去选择技术框架时，技术框架最基本要解决上面现存问题，同时我们也要确认出我们的期望，要达到的目标是什么：

支持当前业务需求，这是最最基本的条件；

服务避免单点问题，去中心化；

服务高可用、高并发，解耦服务依赖；

服务通用化，支持异构系统调用服务；

服务依赖关系自维护，可视化；

服务性能监控自统计，可视化；

服务需自带注册、发现、健康检查、负载均衡等特性；

开发人员关注度高，上手快，简单轻量，低侵入；

还有最重要一点，这也是往往很多技术人员进入的误区，“对于技术，不要为了使用而使用，用最简单合适的技术实现解决问题才是正道”。架构是服务于业务的，能快速方便的满足业务需求的架构才是好的架构。

二.dubbo怎么使用?

Dubbo 采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 入侵，只需用 Spring 加载 Dubbo 配置即可。

# 3.1 安装注册中心

官方推荐使用 Zookeeper 作为注册中心，因此本次测试使用 Zookeeper，将其放置在 ip 为 192.168.1.1 的虚拟机上。

# 解压和转移目录tar -zxvf zookeeper-3.4.8.tar.gz -C /usr/cd /usrmv zookeeper-3.4.8 zookeeper# 设置配置文件cd /usr/zookeeper/confcp zoo_sample.cfg zoo.cfg# 启动 zookeeper/usr/zookeeper/bin/zkServer.sh start# 查看 zookeeper 运行状态，如果出现 Mode: standalone 说明运行成功/usr/zookeeper/bin/zkServer.sh status复制代码

# 3.2 服务提供者

创建一个 Maven 项目（名为 dubbo-service 的 web 项目）。

pom.xml 配置：

web.xml 配置：

接口：

实现类：

applicationContext-dubbo.xml 配置：

//提供方应用信息,计算依赖关系    
        //使用广播注册中心暴露服务地址    
        //用dubbo协议在20880端口暴露服务    
        //声明需要暴露服务的服务接口    
            
    复制代码

# 3.3 服务消费者

创建一个 Maven 项目（名为 dubbo-consumer 的 web 项目）。

pom.xml 配置：

web.xml 配置：

将 dubbo-service 项目中的 HelloService 接口复制到该项目（dubbo-consumer）中。

控制层：

@Controllerpublic class HelloController {    @Autowired    private HelloService helloService;        @RequestMapping("hello")    @ResponseBody    public String hello(String name) {        return this.helloService.sayHello(name);    }}复制代码

applicationContext-dubbo.xml 配置：

springmvc.xml 配置：

先启动服务提供者的项目（8080），再启动服务消费者的项目（8081）。打开浏览器访问,结果如下图：

三.dubbo其他点

Dubbo 有哪些注册中心？

Zookeeper 注册中心：基于分布式协调系统 Zookeeper 实现，采用 Zookeeper 的 watch 机制实现数据变更。

Dubbo 的注册中心集群挂掉，发布者和订阅者之间还能通信么？

可以通讯。启动 Dubbo 时，消费者会从 Zookeeper 拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用。