Dubbo+Zookeeper分布式架构Demo

Dubbo背景和简介

1.单一应用框架(ORM) 

                当网站流量很小时，只需一个应用，将所有功能如下单支付等都部署在一起，以减少部署节点和成本。 

        缺点：单一的系统架构，使得在开发过程中，占用的资源越来越多，而且随着流量的增加越来越难以维护 

2.垂直应用框架(MVC) 

            垂直应用架构解决了单一应用架构所面临的扩容问题，流量能够分散到各个子系统当中，且系统的体积可控，一定程度上降低了开发人员   之间协同以及维护的成本，提升了开发效率。 

        缺点：但是在垂直架构中相同逻辑代码需要不断的复制，不能复用

3.分布式应用架构(RPC) 

        当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心 

        缺点：通讯问题，寻找服务器地址问题，参数的传输和解析，这些过程都需要大量的工作去完成。

4.流动计算架构(SOA) 

        随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架

从以上可以看成现在的架构演变过程：

详细的RPC和SOA大家可以百度去更详细的了解。。。

Dubbo是什么？

Dubbo是：

一款分布式服务框架

高性能和透明化的RPC远程服务调用方案

SOA服务治理方案

每天为2千多个服务提供大于30亿次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点以及别的公司的业务中。

Provider: 暴露服务的服务提供方。 

Consumer: 调用远程服务的服务消费方。 

Registry: 服务注册与发现的注册中心。 

Monitor: 统计服务的调用次数和调用时间的监控中心。

简单的流程：

        1.服务器启动运行服务提供者

        2.生成者启动在服务中心注册服务注册自己提供的服务

        3.消费者启动在注册中心订阅自己的服务。

            4.注册中心服务有变更，会再次以长链接推送变更数据给消费者。

            5.服务者消费者获取生产者，是基于软负载均衡的算法去选择，失败了会再次去选择另外   一台。。（详情调用次数和时间可以去统计数据中心去监测）

Dubbo祖册中心：

Redis、Zookeeper（目前使用最多）、Simple、Multicast

Dubbo  入门demo（window系统）

1.Zookeeper介绍和安装

简单的说Zookeeper做服务中心，搭建软集群部署项目，当提供者出现断电等异常停机时，Zookeeper注册中心能自动删除提供者信息，当提供者重启时，能自动恢复注册数据，以及订阅请求

官网下载

安装完成之后找到bin里面的conf里面的zoo_sample.cfg  把它修改为zoo.cfg

进入bin目录 按shift+鼠标右键  选择命令行  输入zkServer.cmd启动

现在就把服务器中心搭建完毕了。。。。

项目jar包（注意还需要spring的包）

dubbo-api : 存放公共接口； 

dubbo-consumer :　调用远程服务； 

dubbo-provider : 提供远程服务。

1.创建dubbo-api项目，用来打包供提供者和消费者使用，在项目中定义服务接口：该接口需单独打包，在服务提供方和消费方共享。 

2.创建dubbo-provider的项目（需要添加dubbo-api项目src依赖）

用spring配置声明暴露服务

启动远程服务：（注意System.in.read()  个人理解为这样才能保证线程一直运行）

3.创建消费者项目dubbo-comsumer

spring配置

启动消费者（注意消费可以有多个的）

注意事项，先启动生产者成功后再启动消费者，不然消费者找不到生产者服务

dubbo-admin是管理中心，里面可以看见注册的消费者，生产者，调度之类的，可以自行去了解

直接放进tomcat运行就可以了，把文件放进Root里面 ，运行dubbo_admin

链接：https://pan.baidu.com/s/1yFKyNAacKmrn018D3YOx1w 密码：3y1v