dubbo

Posted 2021-04-06 难民集中营

        我发现自己身上有一个非常严重的错误！那就是我什么都学，什么都看，但是在实际的过程中，总是只看了一半，比如一些视频，或者书刊什么的，都是这样，这样的结果就成了，貌似什么都会，其实真是的什么都不会，最重要的是好记性不如烂笔头，还是要动手去敲，去写，这样的话才不会出现这样那样的问题，而我就是缺乏持之以恒！所以我要承认自己的缺点，并把它改过来，要不然，接下来我自己都不能原谅自己了！

       言归正传，因为我在之前的项目当中遇到过分布式(dubbo)，但是我却没有深入的了解它里面的原理，以及与各个框架之间的整合的配置该怎么去做，最后导致我，在项目报错的时候，自己百度也百度不到，只能去找技术大佬，但是大佬都会比较忙，与其等着别人，这次不如就自己动手，好好的去了解这个项目的全部吧！

       之前做的报表项目，是分别把dao ,service,分别放在不同的dubbo,如果你想调用别的dao,也学要人家把dao的接口给你暴露才可以！而我现在要做的这个是，只将service层接口暴露，service直接可以调用dao,所以配置什么的也比以前的那个少，感觉还是可以的，目前的项目不大，分两块的，两个业务模块，一个web,当然还有一些公共的模块，maven添加依赖进去就可以了！了解完项目的结构，那么接下来我们就可以开始dubbo之旅了！

        dubbo 是什么？

Dubbo是一个分布式服务框架，提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东西，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）

       核心：

Remoting：网络通信框架，实现了sync-over-async和request-response消息机制。

RPC：一个远程过程调用的抽象，支持负载均衡、容灾和集群功能。

Registry：服务目录框架用于服务的注册和服务事件发布和订阅。

dubbo的架构：

Provider： 暴露服务的提供方

Consumer：调用远程服务的服务消费方

Registry： 服务注册中心和发现中心

Monitor： 统计服务和调用次数，调用时间监控中心。（dubbo的控制台页面中可以显示）

Container：服务运行的容器

       相互的调用关系

0、服务器负责启动，加载，运行提供者（例如在tomcat容器中，启动dubbo服务端）（）

 1、提供者在启动时，向注册中心注册自己提供的服务。

2、消费者启动时，向注册中心订阅自己所需的服务。

4、消费者，从远程接口列表中，调用远程接口，dubbo会基于负载均衡算法，选一台提供者进行调用，如果调用失败则选择另一台。

5、消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。（可以在dubbo的可视化界面看到）

     dubbo的容错方案(此处我还没有明白，所以暂时先记录了)

        dubbo 的用法：

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。如果不想使用Spring配置，而希望通过API的方式进行调用（不推荐）

1.    服务的提供者

1.2定义服务接口: (该接口需单独打包，在服务提供方和消费方共享)

1.3接口的实现

spring对dubbo的管理配置文件

注册中心的配置

服务的暴露得方式

消费者的配置：(web层的的配置文件通过，引入资源文件的方式进行的)

dubbo的配置文件

这个是消费者的配置文件的配置，因为，全部交给给Spring管理，所以Spring配置文件都是经过资源文件导入的形式的进行的！

好了，今天先到这里，今天主要分享的是一些大概，以后会慢慢的深入！！