dubbo-CSDN博客

本文链接：https://blog.csdn.net/weixin_43088394/article/details/112798923

本文深入探讨了从单体架构到微服务架构的转变，详细介绍了微服务的优缺点、核心概念和设计原则。重点讲解了Dubbo作为RPC框架在微服务中的应用，包括其长连接特性、服务拆分思路，以及与SpringCloud的区别。此外，还阐述了服务注册、发现、负载均衡策略，并提供了Dubbo与Zookeeper的整合实例。

摘要由CSDN通过智能技术生成

1 单体架构

1.1 单体架构

在这里插入图片描述

1.2 优缺点

在这里插入图片描述

修改后测试麻烦
迭代困难
修改工具类，其他的模块都受到影响

某个模块扩展扩容起来麻烦
部署和回滚不方便

2 微服务架构引入

2.1 概念

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有
上下文边界的服务。

2.2 架构图

在这里插入图片描述

2.3 微服务架构设计原则

拆分足够小
服务之间轻量级通信

2.4 微服务的优点

相对于单体架构，它的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：
一组小的服务服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。

独立部署运行和扩展
每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。

独立开发和演化
技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。

独立团队和自治
团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

2.5 微服务的缺点

服务拆分微服务架构可能带来过多的操作。
分布式系统可能复杂难以管理。
因为分布部署跟踪问题难。
分布式事务比较难处理
当服务数量增加，管理复杂性增加。
等

2.6 微服务拆分思路

2.6.1 横向拆分

根据业务来拆分
在这里插入图片描述

2.6.2 纵向拆分

根据层次来拆分

拆分成独立的模块，足够小
在这里插入图片描述

2.7 微服务的选择

2.7.1 Dubbo （RPC）（zookeeper）

2.7.1.1 Dubbo

长连接
Dubbo是阿里集团开源的一个极为出名的RPC（Remote process call）框架，在很多互联网公司和企业应用中广泛使用。协议和序列化框架都可以插拔是及其鲜明的特色。同样的远程接口是基于Java Interface，并且依托于spring框架（管理Bean生命周期）方便开发。可以方便的打包成单一文件，独立进程运行，和现在的微服务概念一致。所以目前Dubbo是一种广泛使用的微服务架构框架。

2.7.1.2 RPC

RPC= Remote Process Call 跨进程调用
RPC的本质是提供了一种轻量无感知的跨进程通信的方式，在分布式机器上调用其他方法与本地调用无异（远程调用的过程是透明的，你并不知道这个调用的方法是部署在哪里，通过PRC能够解耦服务）。RPC是根据语言的API来定义的，而不是基于网络的应用来定义的，调用更方便，协议私密更安全、内容更小效率更高。

在这里插入图片描述

客户端（Client），服务的调用方。
服务端（Server），真正的服务提供者。
客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。
基于TCP/IP协议。速度快。
在这里插入图片描述

2.7.2 Springcloud （HTTP）服务的治理框架

2.7.2.1 Springcloud （HTTP/REST）

Spring Cloud来源于Spring，利用Spring Boot进行快捷开发。 Spring Cloud基本上都是使用了现有的开源框架进行的集成，学习的难度和部署的门槛就比较低，对于中小型企业来说，更易于使用和落地。Spring Cloud 核心组件Eureka是Netflix开源的一款提供服务注册和发现的产品，它提供了完整的Service Registry和Service Discovery实现。也是Spring Cloud体系中最重要最核心的组件之一。

2.7.2.2 http
应用层协议，简单。
http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议进行传输。
使用Http协议的微服务，通常返回json数据，然后把json转换为对象。

2.7.3小结
RPC服务和HTTP服务还是存在很多的不同点的，一般来说，RPC服务主要是针对大型企业的，而HTTP服务主要是针对小企业的，因为RPC效率更高，而HTTP服务开发迭代会更快。总之，选用什么样的框架不是按照市场上流行什么而决定的，而是要对整个项目进行完整地评估。

2.8微服务的基本概念

2.8.1 服务提供者Provider

提供服务的具体实现。

2.8.2 服务调用者Consumer

通过一些框架来调用服务提供者提供的服务

注意：同一个微服务，既可以是provider，也可以是consumer。

2.9 拓展阿里架构演变之路

https://segmentfault.com/a/1190000018626163

3 Dubbo引入

3.1 Dubbo介绍

http://dubbo.apache.org/en-us/

3.2 Spring和Dubbo的结合

3.2.1 入门案例

参考文档：https://dubbo.gitbooks.io/dubbo-user-book/content/quick-start.html

3.2.1.1 导包
见资料。

3.2.1.2 服务提供者

3.2.1.2.1 代码
首先我们在服务端定义一个接口
在这里插入图片描述

然后我在服务端提供这个接口的实现
在这里插入图片描述

3.2.1.2.2配置
在这里插入图片描述

3.2.1.3 服务器使用者

3.2.1.3.1 代码
在这里插入图片描述

远程调用代码
在这里插入图片描述

3.2.1.3.2 配置

在这里插入图片描述

3.2.1.4 测试结果

在这里插入图片描述

3.2.2 入门案例分析

3.3 SpringBoot 和 Dubbo的结合

参考文档https://github.com/alibaba/dubbo-spring-boot-starter

3.3.1 导包

<dependency>
   <groupId>com.alibaba.spring.boot</groupId>
   <artifactId>dubbo-spring-boot-starter</artifactId>
   <version>2.0.0</version>
</dependency>

3.3.2 提供者

在这里插入图片描述

配置：

spring.application.name=dubbo-spring-boot-starter
spring.dubbo.server=true
spring.dubbo.registry=N/A

3.3.3 使用者
也要实现一模一样的接口！
在这里插入图片描述

然后在main方法里测试！
在这里插入图片描述

3.3.4测试
先启动服务提供者：

在这里插入图片描述

在启动使用者：
这行log出现在下面的空行位置
在这里插入图片描述

3.4 直连提供者

3.4.1 介绍

我们刚才使用的微服务的用法，实际上是一种最简单的点对点调用方式。这种方式通常用于测试环境。
在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直联方式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表。
在这里插入图片描述

注意为了避免复杂化线上环境，不要在线上使用这个功能，只应在测试阶段使用。

3.4.2 弊端

不利于分布式的扩展

3.5 服务注册和服务发现

3.5.1 架构图
在这里插入图片描述

服务提供者去注册中心注册的时候告诉注册中心哪些内容？
1，服务提供者的IP地址
2，服务暴露的端口号
3，服务暴露的协议
4，服务暴露的接口名字（全类名）
5，服务提供者的服务的名字
dubbo://192.168.2.45:20880?applicationName=dubbo-provider&className=com.ciggar.common.DemoService&registerTime=……

服务发现和服务注册的过程

名词解释：
在这里插入图片描述

3.5.2 ZooKeeper

是一个中间件，负责为分布式系统提供协调服务。服务注册和服务发现。
https://www.apache.org/dyn/closer.cgi/zookeeper/
下载路径

下载解压之后
修改一个文件名
zoo_sample.cfg修改为在这里插入图片描述
启动：

3.6 Spring +dubbo项目如何整合zookeeper

3.6.1 导入依赖

<dependency>
    <groupId>com.101tec</groupId>
    <artifactId>zkclient</artifactId>
    <version>0.9</version>
</dependency>
<dependency>
    <groupId>org.apache.zookeeper</groupId>
    <artifactId>zookeeper</artifactId>
    <version>3.4.9</version>
    <type>pom</type>
</dependency>

3.6.2 修改服务端
在这里插入图片描述

启动：
没有报错，
Zookeeper那边的命令行会出现一些log

在这里插入图片描述

3.6.3 修改客户端
在这里插入图片描述

3.6.4 测试

在这里插入图片描述

3.7 Springboot 和 dubbo项目整合zookeeper

3.7.1 服务端

增加了依赖
在这里插入图片描述

修改地址：

spring.application.name=dubbo-spring-boot-starter
spring.dubbo.server=true
spring.dubbo.registry=zookeeper://localhost:2181

启动

3.7.2 使用端

<dependency>
   <groupId>com.101tec</groupId>
   <artifactId>zkclient</artifactId>
   <version>0.10</version>
</dependency>

配置文件：
增加如下：

spring.dubbo.registry=zookeeper://localhost:2181

代码里：

3.7.3测试
在这里插入图片描述

4 Dubbo负载均衡

4.1 概念

LoadBalance 中文意思为负载均衡，它的职责是将网络请求，或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况。通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时，还可以避免资源浪费，一举两得。

4.2 负载均衡策略

在这里插入图片描述

4.2.1 Random

随机加权

RandomLoadBalance 是加权随机算法的具体实现，它的算法思想很简单。假设我们有一组服务器 servers = [A, B, C]，他们对应的权重为 weights = [5, 3, 2]，权重总和为10。现在把这些权重值平铺在一维坐标值上，[0, 5) 区间属于服务器 A，[5, 8) 区间属于服务器 B，[8, 10) 区间属于服务器 C。接下来通过随机数生成器生成一个范围在 [0, 10) 之间的随机数，然后计算这个随机数会落到哪个区间上。权重越大的机器，在坐标轴上对应的区间范围就越大，因此随机数生成器生成的数字就会有更大的概率落到此区间内。

4.2.2 RoundRobin

我们有三台服务器 A、B、C。我们将第一个请求分配给服务器 A，第二个请求分配给服务器 B，第三个请求分配给服务器 C，第四个请求再次分配给服务器 A。这个过程就叫做轮询。轮询是一种无状态负载均衡算法，实现简单，适用于每台服务器性能相近的场景下。
通常我们可以给轮询的机器设置不同的权重，经过加权后，每台服务器能够得到的请求数比例，接近或等于他们的权重比。比如服务器 A、B、C 权重比为 5:2:1。那么在8次请求中，服务器 A 将收到其中的5次请求，服务器 B 会收到其中的2次请求，服务器 C 则收到其中的1次请求。

4.2.3 LeastActive
LeastActiveLoadBalance 翻译过来是最小活跃数负载均衡。活跃调用数越小，表明该服务提供者效率越高，单位时间内可处理更多的请求。此时应优先将请求分配给该服务提供者。在具体实现中，每个服务提供者对应一个活跃数 active。初始情况下，所有服务提供者活跃数均为0。每收到一个请求，活跃数加1，完成请求后则将活跃数减1。在服务运行一段时间后，性能好的服务提供者处理请求的速度更快，因此活跃数下降的也越快，此时这样的服务提供者能够优先获取到新的服务请求、这就是最小活跃数负载均衡算法的基本思想。

4.2.4 ConsistentHash

在这里插入图片描述