[000-01-008].第1节：SpringCloud中的一些概念-CSDN博客

本文链接：https://blog.csdn.net/weixin_43783284/article/details/120244691

我的后端学习大纲

SpringCloud学习大纲

1.介绍一些基本概念：

1.响应时间：
- 指的是执行一个请求开始，到最后收到响应所花费的总体时间
2.并发数：
- 指系统同时处理请求的数量
3.并发连接数：
- 指的客户端向服务器端发送的请求，并建立Tcp连接的总数量。
  - 请求数：也称之为QPS，指的每秒多少请求
  - 并发用户数：单位时间内有多少用户
4.吞吐量：
- 单位时间内系统处理请求的数量
5.TPS:
- 指的是每秒的事务。所谓的事务并不是数据库中所谓的增删改查啥的。和那个没关系。这里指的是客户端发啊送请求，到服务端做出响应，再到客户端收到响应。这算一个事务。这个事务里面可能会包含很多次请求和很多连接。

综上：QPS > 并发连接数 > TPS

2.大型互联网项目架构目标：

1.高性能：可以提供快速的访问体验
2.高可用：网站可以一直正常访问
3.可伸缩：就是通过硬件的增加或者减少，可以提高或降低处理能力
4.高扩展：系统间耦合性底，方便的通过新增或移除方式，增加或者减少新的功能模块
5.安全性：提供网站安全访问和数据加密，安全存储等策略
6.敏捷性：随需应变，快速响应。

3.系统的演变过程：

在这里插入图片描述

3.1.单体架构:

a.单体架构图：

单体架构就是将所有功能都集中在一个项目种进行开发，打成一个包部署

b.单体架构特点：

1.当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本
2.这种结构，用于简化增删改查工作量的数据访问框架(ORM)是关键
3.适用于小型网站，小型管理系统，大部分web工程（前端页面，web层代码，service层代码，dao层代码）是将所有功能模块，打包到一起并放在一个web容器中
4.当用户访问量增大的时候，可以通过扩展服务器来承载访问。但是每次扩展服务器都是连着整个应用一块扩展

c.单体架构优点：

1.所有的功能都集中在一个项目工程中,架构简单
2.项目结构简单，前期开发成本低，部署成本低，小型项目的首选

d.单体架构缺点：

1.全部功能集中在一个工程中，对于大型项目不易开发，扩展及其维护很难
2.系统性能的扩展只能通过扩展集群节点，成本高，有瓶颈

3.2.垂直架构:

a.垂直架构图：

在这里插入图片描述

b.垂直架构特点:

1.是指将单体架构中的多个模块拆分为多个独立的项目。形成多个独立的单体架构。
2.垂直架构存在的问题：重复功能太多。将来会有更多的模块aap1,app2,app3…appn。这种情况，各个模块都会有一些共同的部分 ，但是这种结构就造成了重复，存在大量重复模块。

c.垂直架构优点：

1.项目架构简单，前期开发成本低，周期短，小型项目的首选。
2.通过垂直拆分，原来的单体项目不至于无限扩大，不同的项目可采用不同的技术。

d.垂直架构缺点：

1.全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
2.系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。
3.各个模块都会有一些共同的部分，但是这种结构就造成了大量重复模块的开发

3.3.分布式架构：

a.分布式架构的图

1.根据业务规则对系统进行拆分，每个业务模块作为独立的项目开发，称为一个服务

b.分布式架构特点：

1.所谓的分布式架构就像人的神经元一样，彼此之间独立但又相互联系
2.分布式就是根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务
3.分布式是指在垂直架构的基础上，将公共业务模块抽取出来，作为独立的服务供其他调用者消费，以实现服务的共享和重用

c.分布式架构的优点：

1.增大系统容量：
- 我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构。
2.加强系统可用：
- 我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性；
3.因为模块化，所以系统模块重用度更高
4.因为软件服务模块被拆分，开发和发布速度可以并行而变得更快，降低服务的耦合性
5.降低服务的耦合性,系统扩展性更高,有利于服务升级拓展

d.分布式架构的缺点：

1.服务提供方一旦产生变更，所有消费方都需要变更。比如一旦当E的IP地址，或者端口变化，那aap1,app2,app3…appn模块都要改变。
2.各服务模块不可以实时调节
3.架构设计变得复杂
4.多个服务的部署，其流程变得复杂
5.系统吞吐量大了，但是响应时间会变长
6.多元化的技术、服务的变多使得运维变得复杂
7.架构复杂导致学习曲线变大
8.测试和查错的复杂度增大
9.管理分布式系统中的服务和调度变得困难和复杂

e.分布式中需要考虑的问题：

1.远程调用：服务之间的互相调用
2.服务发现：A调用B，B上有好几台机器，那A调用哪台机器，分析这种问题
3.负载均衡：B中有好几个台机器，B上的机器有相同的功能，这就达到了负载均衡的目的
4.服务容错：
5.配置管理：把配置放在配置中心
6.服务监控：实时监控每个服务运行状态
7.链路追踪：
8.日志管理：整个项目的日志管理
9.任务调度：执行定时任务，定时任务怎一台机器执行还是所有机器都执行

f.基于这些问题的解决方案：

1.在系统的分布式架构中有很多需要注意的问题，针对这些问题就出现了ESB，Dubbo，微服务等一些解决方案；

3.4.SOA架构：

a.SOA架构设计图：

在这里插入图片描述

b.SOA架构特点

1.SOA：（Service-Oriented Architecture，面向服务的架构）
- SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。具有分布式，可重用，扩展灵活，松耦合的优点。
2.ESB：(Enterparise Servce Bus) 企业服务总线，服务中介。
- 主要是提供了一个服务于服务之间的交互。
- ESB包含的功能如：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。

c.SOA优点：

1.抽取公共的功能为服务,提高开发效率
2.对不同的服务进行集群化部署解决系统压力
3.基于ESB/DUBBO减少系统耦合

d.SOA缺点：

1.抽取服务的粒度较大
2.服务提供方与调用方接口耦合度较高

3.5.微服务架构：

a.微服务架构图：

在这里插入图片描述

b.微服务架构概念

1.微服务架构是一种架构模式，提倡的是将单一应用划分成一组小的服务，服务与服务之间互相协调，互相配合，从而为用户提供服务；
2.每个服务都运行在独立的进程中，服务与服务之间使用轻量级的通信方式进行通信机制（通常为基于HTTP协议的RESTfulAPI）
3.每个服务围绕着具体的业务进行构建，可以独立部署在生产环境中部署
4.微服务架构是在 SOA上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
5.微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

c.微服务的优点：

1.单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
2.面向服务：微服务对外暴露业务接口，服务之间使用轻量级HTTP交互
3.自治：团队独立、技术独立、数据独立、部署独立，服务去中心化，各服务自治，服务可以使用不同的语言，不同的存储技术进行开发
4.隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
5.通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降
6.微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。

d.微服务缺点：

1.架构非常复杂，运维、监控、部署难度提高
2.服务实现组件化：开发者可以自由选择开发技术。也不需要协调其他团队
3.服务之间交互一般使用REST API去中心化：
4.每个微服务有自己私有的数据库持久化业务数据
5.自动化部署：把应用拆分成为一个一个独立的单个服务，方便自动化部署、测试、运维

e.微服务技术对比：

1.微服务这种方案需要技术框架来落地，国内流行的就是有：Dubbo和SpringCloud以及SpringCloudAlibaba
2.三种技术的对比：

4.集群架构、分布式架构区别：

4.1.基本概念：

1.集群的概念:
- 集群就是很多人干一样的事情
2.分布式概念：
- 就是很多人干不一样的事情，事情合起来后就是一件完整的大事。
- 也就是说是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统；
- 分布式系统（distributed system）是建立在网络之上的软件系统。

6.服务的远程调用介绍：

6.1.什么是远程调用技术：

1.在微服务架构中，通常存在多个服务之间的远程调用的需求。
2.远程调用通常包含两个部分：序列化和通信协议
3.常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等
4.目前主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议

6.2.RPC相关介绍：

a.什么是RPC：

1.RPC【Remote Procedure Call】是指远程调用过程，是一种进程间通信方式，他是一种技术的思想，而不是规范
2.它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。.即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同
3.有非常多的协议和技术来都实现了RPC的过程。比如：HTTP REST风格，Java RMI规范，WebService SOAP协议、Hession等
4.比如：当 A调用了B里面的方法，但是这两个方法不在同一台服务器上。所以A-B之间的通讯是出现了以下的过程。而RPC指的就是这个小助手
5.综上来看：RPC两个核心模块应该是：怎么样建立更快的通讯，怎么样更快的序列化

6.3.RESTful相关介绍：

a.RESTful：

1.REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是：客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。
2.在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个唯一的地址。所有资源都共享统一的接口，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和DELETE。
3.在 REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEAD 和 OPTIONS。简单的理解就是，如果想要访问互联网上的资源，就必须向资源所在的服务器发出请求，请求体中必须包含资源的网络路径，以及对资源进行的操作(增删改查)。

b.

REST（Representational State Transfer），表现性状态转换,它是一种软件架构风格。

根据REST风格对资源进行访问称为RESTful。
按照REST风格访问资源时使用请求方式区分对资源进行了何种操作。
http://localhost/users 查询全部用户信息 GET（查询）
http://localhost/users/1 查询指定用户信息 GET（查询）
http://localhost/users 添加用户信息 POST（新增/保存）
http://localhost/users 修改用户信息 PUT（修改/更新）
http://localhost/users/1 删除用户信息 DELETE（删除）