SpringCloud 微服务学习

最新推荐文章于 2024-04-27 02:58:04 发布

Afraidlight

最新推荐文章于 2024-04-27 02:58:04 发布

阅读量191

点赞数

分类专栏： SpringCloud微服务学习文章标签：微服务 spring cloud 学习

本文链接：https://blog.csdn.net/weixin_50722482/article/details/131241004

版权

SpringCloud微服务学习专栏收录该内容

1 篇文章 0 订阅

订阅专栏

SpringCloud 微服务学习

文章目录

SpringCloud 微服务学习

一、对架构的认识

单体架构

平时在学校里或者大多数小项目都是用的单体架构，适合少数人开发。

如果项目太大了会很难维护，但是因为仅是一个包所以部署起来比较方便。

分布式架构

分布式架构可以适合团队开发，每个人负责一个模块，但是往往出现多个模块之间彼此调用的情况，反而使得性能下降，所以下文介绍的微服务架构就是一个良好的分布式架构。
在这里插入图片描述

微服务架构

微服务的架构特征：

单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
自治：团队独立、技术独立、数据独立，独立部署和交付
面向服务：服务提供统一标准的接口，与语言和技术无关
隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

二、设计模式

在学习的过程发现，在分布式微服务架构中用到了许多的设计模式，因此在这里也对常见的设计模式进行一下复习：创建模式，结构模式和行为模式

1.结构模式

这些设计模式是类和对象的组合，继承的概念被用来组合接口和定义组合对象获得新功能方式。

适配器模式（Adapter Pattern）

适配器模式是一种结构型设计模式，它的作用是将一个类的接口转换成客户端所期望的另一种接口。适配器模式通常用于解决两个已有接口之间不兼容的问题，它可以使得原本由于接口不匹配而无法工作的类可以协同工作。

适配器模式包括三个角色：目标接口、适配器和被适配者。其中，目标接口是客户端所期望的接口，适配器是将被适配者的接口转换成目标接口的类，被适配者是需要被适配的类。

适配器模式的优点是可以让两个不兼容的接口协同工作，提高代码的复用性和可维护性。但是，适配器模式也有一些缺点，例如可能会增加系统的复杂度、降低代码的可读性等。

在微服务架构中，适配器模式通常用于将不同的微服务接口进行适配，以便它们可以协同工作。例如，如果一个微服务的接口与另一个微服务的接口不兼容，可以使用适配器模式将它们进行适配，使它们可以协同工作。
装饰器模式（Decorator Pattern）

装饰器模式是一种结构型设计模式，它允许你在不修改对象自身的基础上，动态地添加功能。这种模式通过创建一个包装对象，也就是装饰器，来包裹真实的对象，并提供了额外的功能，比如说添加新的行为或者修改原有的行为。

在微服务架构中，装饰器模式可以用于动态地添加功能，比如在微服务调用的过程中，可以使用装饰器模式来添加日志记录、安全验证、性能监控等功能，而不需要修改原有的代码。

装饰器模式的优点是可以动态地添加功能，而且可以在不改变原有代码的情况下实现这些功能。缺点是可能会增加代码的复杂度，因为需要创建多个装饰器对象来实现不同的功能。

装饰器与适配器都有一个别名叫做包装模式，他们看似都是起到一个包装一个类和对象的作用，但是使用他们的目的很不一样。适配器模式的意义是要将一个接口转变为另一个接口，它的目的是通过改变接口来实现重复使用的目的。而装饰器模式不是要改变装饰对象的接口，而是恰恰要保持原有的接口，但是增强原有对象的功能，或者改变原有对象的处理方式而提升性能。所以这两个模式设计的目的是不同的。
桥接模式（Bridge Pattern）
代理模式（Proxy Pattern）
外观模式（Facade Pattern）
组合模式（Composite Pattern）
享元模式（Flyweight Pattern）

2.创建模式

工厂模式（Factory Pattern）

工厂模式是一种创建型设计模式，它提供了一种创建对象的最佳方式。在工厂模式中，我们不直接实例化对象，而是通过一个工厂类来创建对象。这个工厂类负责根据我们的需求创建不同的对象。

在微服务架构中，工厂模式可以用于创建不同类型的微服务实例。例如，我们可以使用工厂模式来创建不同类型的数据库访问对象，或者创建不同类型的消息队列实例。

工厂模式的优点是可以将对象的创建过程与使用过程分离开来，从而降低了代码的耦合度。缺点是需要额外的代码来实现工厂类，可能会增加代码的复杂度。

跟简单工厂模式中工厂负责生产所有产品相比，工厂方法模式将生成具体产品的任务分发给具体的产品工厂。
抽象工厂模式（Abstract Factory Pattern）
单例模式（Singleton Pattern）
建造者模式（Builder Pattern）
原型模式（Prototype Pattern

3.行为模式

策略模式（Strategy Pattern）

策略模式是一种行为型设计模式，它允许你在运行时动态地改变一个对象的行为。在策略模式中，我们定义一系列算法，将每个算法封装到一个独立的类中，并让这些类可以互换，从而使得算法可以独立于使用它的客户端而变化。

在微服务架构中，策略模式可以用于实现不同的业务逻辑。例如，我们可以使用策略模式来实现不同的支付方式，或者不同的消息传递方式。

策略模式的优点是可以动态地改变对象的行为，而且可以将算法的实现与使用算法的客户端分离开来，从而降低了代码的耦合度。缺点是需要额外的代码来实现策略类，可能会增加代码的复杂度。

模版模式（Template Pattern）

观察者模式（Observer Pattern）

观察者模式是一种行为型设计模式，它定义了一种一对多的依赖关系，使得当一个对象的状态发生改变时，所有依赖它的对象都会得到通知并自动更新。在观察者模式中，被观察的对象称为主题（Subject），而观察者对象称为观察者（Observer）。

在微服务架构中，观察者模式可以用于实现消息队列。例如，我们可以将消息队列实现为一个主题对象，而将不同的消息处理器实现为观察者对象。当有新的消息到达时，主题对象会通知所有观察者对象，并让它们处理消息。

观察者模式的优点是可以让对象之间的依赖关系变得松耦合，从而提高代码的可维护性和可扩展性。缺点是需要额外的代码来实现观察者和主题对象，可能会增加代码的复杂度。
迭代器模式（Iterator Pattern）
中介者模式（Mediator Pattern）
状态模式（State Pattern）
职责链模式（Chain of Responsibility Pattern）
命令模式（Command Pattern）
备忘录模式（Memento Pattern）
解释器模式（Interpreter Pattern）
访问者模式（Visitor Pattern）
目前对这些模式也只是很模糊的认识，希望后面和大家共勉，一起熟悉这些模式，后面遇到了我也会和大家分享。

三、一些遇到的概念性问题

1.Dubbo和SpringCloud的通信方式

微服务的核心是远程通信和服务治理，远程通信提供了服务之间通信的桥梁，服务治理则提供了服务的后勤保障，所以，我们在做技术选型时，需要考虑的是这两个核心的需求。目前，很多微服务框架中的服务通信都是基于RPC通信实现的，在没有进行组件扩展的前提下，SpringCloud是基于Feign组件实现的RPC通信（基于Http+Json序列化实现），DUbbo是基于SPI扩展了很多的RPC通信框架，包括RMI,Dubbo,Hessian等RPC通信框架（默认是Dubbo+Hessian序列化）

RPC是为了实现远程服务调用而诞生的，其实现远程服务的工作过程如下：

服务消费方调用本地调用方式调用服务
client stub接受到调用后负责将方法，参数等组装成能够进行网络传输的消息体；这就是所谓的marshalling.
client stub 找到服务地址，并将消息发送到服务端；这个过程可能是面向连接或无连接的
server stub接收到消息后进行解码，也叫unmarshalling.
server stub 根据解码结果调用本地的服务
本地服务执行并将结果返回给server stub
server stub将返回结果打包成消息并发送至消费方
client stub接收到消息，并进行解码；
服务消费方得到最终结果。并且返回值被设置在本地进行的堆栈中。

2.RPC 与 REST 的区别

RPC 与 REST 最大的区别就在于 RPC 提供了更好的抽象，RPC 甚至将网络传输细节彻底隐藏了，而 REST 没有。具体来说，REST 至少要求用于提供 URL 以及请求参数，而 RPC 隐藏了与网络传输的相关实现细节。另一方面，RPC 可以基于任何网络通信协议，而 REST 通常基于 HTTP（或者 HTTPS）协议。RPC 调用者并不会关心具体的协议是：HTTP、TCP 还是其他任何自定义协议。