week19_day03_Dubbo

服务端高并发分布式架构演进之路

---

项目经理（leader）
产品经理：制作产品的原型图，给定需求。
UI：画图
前端：前台的流程控制，跳转逻辑，页面效果。
后端：开发功能上实现的一些逻辑。
测试：测试你开发的功能。

---

什么是分布式？什么是集群？
广义上的分布式就包括昨天讲的Nginx，一个Nginx代理多个服务器。以及微服务。
狭义上的分布式指的就是微服务：每个服务都是由一个单独的应用来提供，服务与服务之间进行轻量级通信，这个通信的框架就叫Dubbo。

---

Dubbo支持这些协议：

大多使用的是Dubbo协议，Dubbo是一个传输层协议。

Dubbo解决了这些进程（服务）之间的跨进程调用问题。
而springcloud把一整套的微服务的解决方案都给你了。

Dubbo使用的是Dubbo协议（传输层协议）
SpringCloud使用的是http协议（应用层协议）

Dubbo协议调用起来要比http协议快的：

---

下面讲一下spring和Dubbo的整合：
代码见E:\WangDao\Code7\day1_dubbo\spring-dubbo

配置：
provider中的application-context.xml：
consumer中的application-context.xml：

consumer中需要有一个和provider一模一样的接口（DemoService），这样consumer才能访问到provider中的DemoService。

consumer并没有真正的写一个DemoServiceImp，而是调用provider的DemoServiceImp来供自己使用。
所以在启动consumer之前应当先启动provider。
否则会有这样的报错信息：failed to connect to server /127.0.0.1:20880, error message is:Connection refused

我们写代码的时候可能会遇到这种报错信息：No such any registry to export service in provider 192.168.45.1 use dubbo version 2.5.3, Please add to your spring config.If you want unregister, please set

这幅图是从Dubbo官网下载下来的：provider向外暴露接口的时候，可以将接口暴露到Registry中，也可以暴露给consumer，直接暴露给consumer需要增加一个配置：。

这个实例对象，其实不是真正的DemoServiceImpl对象，而是一个代理对象。
代理对象是一个DemoService 的实例，这个代理对象里面有什么东西呢？
这个代理对象里面放的是 真正提供服务的对象的url地址

package com.cskaoyan.demo;

import org.springframework.context.support.ClassPathXmlApplicationContext;

/**
 * @author: jia.xue
 * @Email: [email protected]
 * @Description
 **/
public class Consumer {
     

    public static void main(String[] args) {
     

        // 初始化consumer容器
        ClassPathXmlApplicationContext applicationContext = new ClassPathXmlApplicationContext("application-context.xml");

        //启动
        applicationContext.start();

        // 从容器里面去取一个bean——"demoService"

        //failed to connect to server /127.0.0.1:20880, error message is:Connection refused


        //这个实例对象，其实不是真正的DemoServiceImpl对象，而是一个代理对象

        // 代理对象是一个DemoService 的实例，这个代理对象里面有什么东西呢？
        // 这个代理对象里面放的是 真正提供服务的对象的url地址
        DemoService demoService = (DemoService) applicationContext.getBean("demoService");


        // 一旦我们去使用代理对象调用方法，那么他就会调用这个代理对象里面封装的url地址的对象的方法
        String response = demoService.getDetail("松哥冲冲冲！");

        // 代理对象(dubbo://127.0.0.1:20880).getDetail ---网络-->   访问 服务提供者的真正的对象实例
        System.out.println(response);
    }
}

---

下面讲一下springboot和Dubbo的整合：

1. 导包
   provider2：
   
   和spring整合的dubbo相比，主要区别在于配置
   配置：
   provider2中的application.properties：
   
   DemoServiceImpl：
   
   红框一表示注册到容器中，相当于下面的bean标签
   红框二表示下面的配置接口及其具体实现。

对比provider中的application-context.xml：

---

consumer2中的application.properties：

在ThirdService中调用DemoService，在成员变量demoService上写注解

对比consumer中的application-context.xml：

---

注意：在springboot项目中，如果想启动dubbo，不管provider还是consumer，必须在启动类上加注解：@EnableDubboConfiguration

---

注意：url我们都是写死的，一旦provider暴露的端口号变了，consumer就无法从provider中获取信息了。

还记得registry（注册中心）么？
注册中心就是用来做两个服务之间的协调工作的。我们现在使用的注册中心叫zookeeper。

1. 导包
   
2. 将provider2中的application.properties文件稍作修改
   
   同时将consumer2中的application.properties修改：
   
3. 这句代码也不需要了
   

---

以上都是基于dubbo2.6版本的，接下来我们写基于dubbo2.7版本的。

在dubbo-demo2这个Module下新建3个Module：provider3、consumer3、common。
其中common下存放provider3和consumer3中共同的部分。

1. common
   common的pom文件中导入依赖，同时将其打包为jar包，让common作为jar包让provider3和consumer3去依赖。

2. 在provider3和consumer3中将common这个jar包引入，common里面的依赖provider3和consumer3都能依赖，这就是依赖传递。
   同时provider3和consumer3中都有了common中写的代码。
   
   同时启动类中的这个注解不用写了
   
   配置包扫描路径：