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时代，根据不一样服务对系统资源的要求不一样，咱们能够更合理的配置系统资源，使系统资源利用率最大化。

1. 单一应用架构 当网站流量很小时，只需一个应用，将全部功能都部署在一块儿，以减小部署节点和成本。 此时，用于简化增删改查工做量的 数据访问框架(ORM) 是关键。
2. 垂直应用架构 当访问量逐渐增大，单一应用增长机器带来的加速度愈来愈小，将应用拆成互不相干的几个应用，以提高效率。 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
3. 分布式服务架构 当垂直应用愈来愈多，应用之间交互不可避免，将核心业务抽取出来，做为独立的服务，逐渐造成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提升业务复用及整合的 分布式服务框架(RPC) 是关键。
4. 流动计算架构 当服务愈来愈多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增长一个调度中心基于访问压力实时管理集群容量，提升集群利用率。 此时，用于提升机器利用率的 资源调度和治理中心(SOA) 是关键。

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

2.2 服务带来的挑战

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

根据如今团队的业务系统状况，首先咱们要梳理出现存的问题是什么：

1. 多种调用传输方式：HTTP方式、WebService方式；
2. 服务调用依赖关系：人工记录，查看代码分析；
3. 服务调用性能监控：日志记录，人工查看时间；
4. 服务与应用紧耦合：服务挂掉，应用没法可用；
5. 服务集群负载配置：Nginx配置，存在单点问题；

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

1. 支持当前业务需求，这是最最基本的条件；
2. 服务避免单点问题，去中心化；
3. 服务高可用、高并发，解耦服务依赖；
4. 服务通用化，支持异构系统调用服务；
5. 服务依赖关系自维护，可视化；
6. 服务性能监控自统计，可视化；
7. 服务需自带注册、发现、健康检查、负载均衡等特性；
8. 开发人员关注度高，上手快，简单轻量，低侵入；

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

二.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 /usr
mv zookeeper-3.4.8 zookeeper

# 设置配置文件
cd /usr/zookeeper/conf
cp 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:application name="hello-demo"/>
    //使用广播注册中心暴露服务地址
    <dubbo:registry address="zookeeper://192.168.1.1:2181"/>
    //用dubbo协议在20880端口暴露服务
    <dubbo:protocol name="dubbo" port="20880"/>
    //声明须要暴露服务的服务接口
    <dubbo:service interface="com.light.dubbo.service.HelloService" ref="helloService"/>
    
    <bean id="helloService" class="com.light.dubbo.service.impl.HelloServiceImpl"/>
复制代码

# 3.3 服务消费者

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

pom.xml 配置：

web.xml 配置：

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

控制层：

@Controller
public class HelloController {

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

applicationContext-dubbo.xml 配置：

<dubbo:application name="hello-demo"/>
       
    <dubbo:registry address="zookeeper://192.168.2.14:2181"/>
    
    <dubbo:protocol name="dubbo" port="20880"/>
    
    <dubbo:reference interface="com.light.dubbo.service.HelloService"/>

复制代码

springmvc.xml 配置：

先启动服务提供者的项目（8080），再启动服务消费者的项目（8081）。打开浏览器访问http://localhost:8081/hello?name=jack,结果以下图：

三.dubbo其余点

Dubbo 有哪些注册中心？

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

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

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